Introduzione alle tipologie di applicazioni
Nel panorama delle app mobile esistono diverse possibilità di sviluppo e ognuno deve scegliere a seconda delle proprie necessità.
Le prime app sono state native su ogni piattaforma. Con il termine “nativa” ci si riferisce al fatto che l’app utilizza il linguaggio nativo della piattaforma per il suo sviluppo. Nel panorama attuale le principali piattaforme sono:
Piattaforma |
Linguaggio |
Apple IOS |
Objective C |
Android |
Java |
Windows phone |
C# |
Per realizzare la stessa app e distribuirla sui tre ambienti bisognava scriverla apposta per ogni piattaforma, secondo il suo specifico linguaggio.
Nasce così l’idea di un unico linguaggio che permetta di distribuire la stessa app su piattaforme diverse.
Arrivano così le app ibride e le web app.
Le web app sfruttano la possibilità di salvare sul desktop del telefono un link ad una pagina web. Questa funzionalità è arrivata su Android solo con le versioni più recenti, mentre su IOS è già presente da tempo. In questo caso l’app non è altro che un vero e proprio sito mobile, con tutte le limitazioni legate all’accesso alle risorse del dispositivo per questioni di sicurezza.
Le app ibride invece sono una via di mezzo tra le precedenti tipologie: l’app viene visualizzata all’interno di una finestra del browser del dispositivo (chiamata WebView). Questo significa che come per le web app l’interfaccia può essere scritta usando Html5, Javascript e CSS. La differenza rispetto alla web app è che esistono dei moduli scritti in codice nativo e che si possono interfacciare con la WebView, avendo così a disposizione tutte le funzionalità del dispositivo. I moduli di codice nativo saranno diversi per ogni piattaforma.
Esistono vari framework che permettono di sviluppare app ibride e usano forme diverse, ma comunque tutti usano questa architettura.
Durante il processo di sviluppo si utilizza un ambiente di debug per verificare il funzionamento del comportamento del codice scritto. Come ci si comporta quindi con le varie tipologie di app?
Vediamo come poter affrontare il problema e poi ci concentreremo sulle app ibride.
Debug delle app native
Lo sviluppo delle app native avviene utilizzando degli IDE che vengono forniti dai vendor delle singole piattaforme. Negli IDE si possono mettere dei breakpoint in ogni punto del codice, attivi sia sui simulatori che sui dispositivi reali collegati via cavo al computer dove risiede l’IDE. I debugger degli IDE sono sistemi complessi e con numerose configurazioni possibili (non approfondiremo ulteriormente in questa sede ;)).
Debug di app ibride e web app
In questo tipo di applicazioni il browser diventa lo strumento per il debug. Esistono però comportamenti e limitazioni per i diversi ambienti. Esaminiamo nello specifico le piattaforme IOS e Android. Ogni sviluppatore di siti web (non necessariamente mobile) sa che esistono dei debugger nei browser per poter verificare e modificare sia i fogli di stile che il codice javascript nelle pagine visualizzate dal browser (famoso è Firebug per Firefox). I browser Chrome e Safari sono basati sullo stesso motore di rendering che è WebKit e offrono un ambiente di debug che si chiama WebInspector per Safari e Developer Tools per Chrome.
Per ogni pagina visualizzata nel browser si può avere una sessione diversa del debugger. Quindi sul computer desktop di sviluppo si possono verificare i comportamenti del codice e cambiare gli stili della pagina. Queste modifiche saranno applicate in tempo reale sulla pagina visualizzata localmente. Se la pagina verrà ricaricata dal server i cambiamenti fatti andranno naturalmente persi.
Come fare sui dispositivi mobile? Entrambi i browser citati permettono di effettuare il debug remoto sulle finestre della versione mobile dell’omologo browser come se queste fossero visualizzate sul desktop stesso. Allora significa che abbiamo a disposizione un tool che ci permette di fare il debug delle nostre applicazioni direttamente sul dispositivo mobile. Fantastico!
Purtroppo in realtà questo è vero in parte. Quali sono le limitazioni allora? Se parliamo di web app il supporto è completo, ma non è lo stesso per le app ibride. Ricordate come funzionano? Vengono caricate in una finestra del browser particolare che si chiama WebView, che comporta dei distinguo rispetto alle finestre del browser vero e proprio. In ambiente IOS Safari permette di lanciare il debug indifferentemente sia su una finestra del browser che una WebView, quindi potremmo gestire tranquillamente la situazione.
Questo è vero anche in Android solo dalla versione 4.4 (Kitkat) e con la versione 30 o superiore di Chrome. C’è da notare anche che la WebView sulle versioni precedenti di Android non usa il motore di Chrome ma bensì di un altro browser integrato nelle distribuzioni del sistema.
Il debug può quindi essere fatto agevolmente solo con l’ultima versione di Android installata sul dispositivo, che però i vendor distribuiscono solo sugli ultimi dispositivi e gli aggiornamenti sui vecchi sono programmati per i prossimi mesi.
Utilizzando gli emulatori basta usare gli SDK aggiornati così da riprodurre i requisiti minimi. Ma se si vuole effettuare il debug sui dispositivi reali e questi non dispongono dell’ultima versione di Android perchè il proprio vendor non l’ha ancora distribuita?
In questo caso ci sono tre possibili soluzioni:
-
sostituire la distro sul dispositivo con una di terze parti (come Cyanogenmod) con tutte le conseguenze del caso;
-
utilizzare delle librerie di terze parti che permettano di effettuare il debug remoto sulle specifiche piattaforme (ad esempio un plugin per Cordova/Phonegap come jsHybugger);
-
configurare un server di debug remoto chiamato Weinre che permette di effettuare il debug solo della parte html e CSS.
Vediamo come effettuare questa configurazione e come funziona.
Debug con Weinre
Weinre è l’acronimo di WEb INspector Remote. L’architettura su cui si basa è semplice da capire:
- il dispositivo su cui effettuare il debug e il computer desktop su cui lavorare devono stare nella stessa rete
- sulla macchina desktop si fa partire un servizio che può essere interrogato mediante una finestra del browser
- il server permette di scaricare un file javascript che farà da proxy alla pagina che lo invocherà
- il dispositivo nelle pagine che si vogliono verificare debbono invocare il javascript messo a disposizione dal server
Con questa configurazione si può lavorare come nei casi precedentemente citati. Questa architettura non è limitata e pensata per i dispositivi mobile ma per il debug remoto in generale, quindi basta vengano rispettati questi vincoli e si può agire all’interno di qualsiasi rete, anche Internet. Vediamo ad esempio che il sistema di build messo a disposizione da Adobe per la sua piattaforma Phonegap usa proprio Weinre per permettere il debug remoto.
Vediamo i passi dettagliati per effettuare un test di debug in modo da avere un tutorial passo passo.
Come primo step sulla macchina desktop bisogna installare Weinre. Questo è un server scritto in javascript distribuito attraverso npm, il sistema di distribuzione inventanto da Node.js. Partiamo dal presupposto che sulla macchina sia già installato npm.
Per procedere all’installazione quindi si può digitare: sudo npm -g install weinre.
Il comando sudo sui sistemi unix permette di avere i diritti di amministrazione sul comando successivo invocato (in questo caso npm); il parametro -g serve per installarlo come pacchetto globale a disposizione dei vari utenti e inserito correttamente nel path di sistema.
Una volta finita l’installazione aprendo una finestra di terminale e digitando: weinre –help si avranno a disposizione le varie opzioni di lancio e a cui si rimanda per degli approfondimenti.
Quella che permette di accettare le connessioni da qualsiasi macchina in rete è (attenzione a non usare questa configurazione se si necessita di avere una sicurezza maggiore sulle connessioni del server):
weinre –boundHost -all-
Questo comando fa partire il server sulla porta 8080. Naturalmente questa porta deve essere libera se non si vogliono avere problemi di conflitti. Si può usare il parametro –httpPort per cambiarla in fase di lancio se necessario.
Aprendo il browser sulla macchina desktop si può digitare localhost:8080 sulla barra degli indirizzi e si avrà la pagina di benvenuto con la descrizione delle operazioni da effettuare sulla macchina client.
Nello specifico sul client basta inserire un tag script come il seguente:
<script src="http://xxx.xxx.xxx.xxx:8080/target/target-script-min.js#anonymous">
dove xxx.xxx.xxx.xxx è l’indirizzo ip della macchina server.
A seguito di questa modifica si può installare l’applicazione sul dispositivo client e invocando l’url
http://localhost:8080/client/#anonymous
sul browser del server si vedranno le sessioni attive e collegate con il server.
A questo punto cliccando su una delle possibili sessioni elencate nella sezione target questa sarà evidenziata in verde e sarà quella attiva. Passando quindi nella sezione Elements (nel menù in alto) si avrà a disposizione l’html della pagina ed i suoi elementi css modificabili. Chi ha usato WebInspector riconoscerà la similitudine dell’interfaccia nell’immagine a corredo, che si basa proprio sullo stesso engine (WebKit che è un progetto open).
Per ora può bastare, direi avete gli elementi per poter cominciare a fare i vostri debug html anche sui sistemi remoti.
Per approfondimenti su Weinre usate al bibliografia sotto e buon lavoro!
Alla prossima
Glauco
Bibliografia
Weinre
http://people.apache.org/~pmuellr/weinre/docs/latest/Home.html
Phonegap builder