Instant Developer Cloud mette a disposizione uno strumento di debug molto potente per quanto riguarda l’analisi del comportamento applicativo ma, per non avere sorprese dell’ultimo minuto, ci sono altri aspetti che è opportuno tenere in considerazione quando si prova un’app da pubblicare sullo store.
Infatti, tra quando avviamo l’app nell’IDE a quando la lanciamo sul device, ci sono alcune differenze. È sufficiente conoscerle e sapere come comportarsi:
- L’app installata su un Launcher gira sempre offline;
- L’app installata su un Launcher può usare i plugin nativi di Cordova, mentre non può se è lanciata dall’IDE nel browser;
- I device, specialmente quelli Android, sono solitamente più lenti dei computer.
L’app installata su un Launcher gira sempre offline
Per quanto riguarda la differenza tra online e offline, ritengo opportuno aprire una breve parentesi. Questa differenza si riferisce a dove è in esecuzione il codice applicativo: se online, il codice sta girando all’interno di node.js sul server; se offline, l’applicazione sta girando all’interno del Launcher (quindi Cordova) nel device, oppure all’interno del browser. Il termine offline può essere frainteso e mi sembra dunque importante chiarire che non significa che l’applicazione non ha accesso alla rete, ma semplicemente che può essere avviata anche in assenza di connettività. Tutte le chiamate verso servizi esterni saranno disponibili quando l’accesso a Internet è disponibile.
Utilizzando il toggle presente nel menu di avvio dell’app nell’IDE è possibile scegliere tra le due opzioni. Per simulare il device è necessario quindi usare offline.
L’app installata su un Launcher può usare i plugin nativi di Cordova, mentre non può se è lanciata dall’IDE nel browser
Per quanto riguarda la seconda delle differenze citate, quella riguardante i plugin nativi, l’accortezza da seguire è una diretta conseguenza dell’uso dell’opzione appena citata. All’interno dell’IDE, infatti, l’applicazione non può avere a disposizione i plugin nativi e, quindi, alcune operazioni devono necessariamente essere svolte dal codice JavaScript. Non preoccupatevi: non c’è quasi nulla da fare, perché ci pensa Instant Developer Cloud. Ad esempio, se usate app.fs.url.get(), è il framework della piattaforma ad eseguire la chiamata via JavaScript o via plugin Cordova (se disponibile).
Non c’è da fare quasi nulla, ma qualcosina potrebbe esserci. Infatti, per motivi di sicurezza, le chiamate http eseguite da JavaScript su server diversi da quello del sito corrente potrebbero dare errore di CORS (Cross Origin Resource Sharing).
In pratica, effettuando una chiamata http ad un vostro web service potreste avere un comportamento diverso tra online e offline e tra offline su browser e offline su Launcher:
- online funziona, perché la chiamata è effettuata da node.js e non dal browser;
- offline su Cordova funziona, perché la chiamata è effettuata dal plugin nativo;
- offline su IDE darà errore, se il vostro server IDE non è stato impostato tra le origini attendibili per il cross scripting.
Qualora quindi vedeste l’errore nell’IDE, non preoccupatevi: basterà configurare il vostro server.
I device, specialmente quelli Android, sono solitamente più lenti dei computer
L’ultima differenza, infine, è legata alle performance del device ed è stata una delle piccole scoperte più interessanti dell’ultimo periodo: il resource throttling di Chrome.
I device mobile, specialmente in ambito Android, sono sensibilmente più lenti del computer su cui viene effettuato lo sviluppo. Questo potrebbe portare a vedere un risultato più lento e meno gradevole all’utente, una volta compilata l’app su device.
Quando è necessario risolvere un problema, l’approccio migliore è mettersi in condizione di poter replicare il comportamento nel proprio ambiente di sviluppo. Anche in questo caso, per fortuna, abbiamo un metodo.
Avviando l’applicazione e aprendo gli strumenti di sviluppo di Chrome è possibile, nelle impostazioni di Performance, attivare il CPU throttling per rallentare la CPU di 4 o 6 volte. Fatelo e vedrete l’app funzionare anche più lentamente che sul telefono, avendo così la possibilità di individuare la soluzione più adeguata al vostro caso.
E voi, come fate a mettervi in condizione di replicare i problemi da risolvere? Ci sono tecniche di cui vi piacerebbe discutere in un prossimo Trick?
