Il nuovissimo sistema operativo opensource Android di Google ha portato una grande ventata di novità e di entusiasmo, esattamente come quella relativa all'uscita delle prime distribuzioni Linux.La possibilità di poter sviluppare in modo aperto applicazioni direttamente in linguaggio Java e la possibilità di poter deliverare direttamente all'interno di un dispositivo mobile, ha scatenato una specie di felicità mediatica nel mondo degli sviluppatori e delle aziende, tale da prendere in seria considerazione lo sviluppo proprio sulle future generazioni di dispositivi e proprio su questa nuova piattaforma.
Il pacchetto della SDK di Android che viene distribuito è associabile ad un plugin per l'IDE Eclipse: selezionando quindi l'opportuna perspective di Eclipse, permette non solo di eseguire il deployment delle applicazioni direttamente sul dispositivo mobile, o sul relativo emulatore (anch'esso incluso nella SDK), ma permette anche di eseguire il debug delle applicazioni esattamente come in un normale ambiente di sviluppo Java.
Più precisamente è possibile impostare breakpoints per bloccare l'esecuzione dell'applicazione (a runtime) mostrando un opportuno alert sul dispositivo mobile (oltretutto formattato anche molto bene e di gradevole lettura), in questo modo chi sviluppa l'applicazione può andare a visionare lo stato interno delle risorse e fare analisi sul codice.
Sempre attraverso il plugin è inoltre possibile debuggare più applicazioni contemporaneamente sullo stesso dispositivo mobile.
Attualmente Android non è esente da bachi, anzi ne sono presenti diversi, ma proprio in questo periodo Google fa sapere che a breve rilascerà un upgrade importante della SDK con i relativi bugfix delle anomalie più scomode e attese dalla community.
Dopo aver terminato un'accurata sessione di lavoro, protratta anche in seguito allo studio dei tutorial, mi sono reso conto che il mio entusiasmo iniziale, nato dalla sensazione di scoprire un bel giocattolone nuovo, invece che diminuire, è aumentato drasticamente.
Nel momento in cui si inizia a customizzare una qualsiasi applicazione si entra in un tipico loop del tipo: adesso provo quest'ultima modifica e smetto.... ed invece si perpetua nella sperimentazione per notti intere...
La caratteristica più importante, a mio avviso, è la possibilità di gestire direttamente le periferiche del cellulare e le connessioni GSM, UMTS, Wi-Fi e Bluetooth.
La possibilità di interagire direttamente con i driver del dispositivo attraverso lo strato di interfacciamento Linux, credo sia un'opportunità molto importante per lo sviluppo futuro di Android.
Giusto per stuzzicare l'appetito a chi ancora non si è cimentato nello sviluppo di applicazioni su Android eccovi lo schema degli strati applicativi e delle librerie che si possono utilizzare:
Come si può vedere dall'immagine, tutto l'ambiente è basato su un kernel Linux su cui si appoggiano tutte le librerie di sviluppo denotate dal colore verde. Tra queste librerie, è importante sottolineare la presenza di due librerie opensource molto importanti: SQLite è il DBMS per la creazione e la gestione del database delle applicazioni; e WebKit la libreria utilizzata per renderizzare le pagine HTML, utilizzata anche nel browser Safari dell'iPhone.
Al di sopra delle librerie troviamo il framework da utilizzare per creare effettivamente il comportamento delle applicazioni, denotato dal colore blu, ed è essenzialmente basato sul concetto di Activity.
La runtime di Android è una vera e propria macchina virtuale chiamata Dalvik, denotata dal colore giallo, che permette l'esecuzione delle applicazioni, esattamente come avviene per la macchina virtuale Java per il bytecode.
Proprio su Dalvik ci sono state e ci sono ancora molte discussioni in ambito di licenze Java, in quanto in questo modo Google non sarebbe costretta a sottostare ad alcuna licenza Sun, in quanto Dalvik è svincolato da Java e Java MicroEdition, e non necessita di alcuna libreria runtime Java di Sun, infatti le applicazioni compilate per Android non sono compatibili con codice compilato in bytecode Java (anche perché vi è un framework associato che non è possibile separare).
A breve spero di riuscire a fare alcuni post su come si sviluppa un'applicazione in Android andando nello specifico sull'utilizzo delle singole librerie.
Il pacchetto della SDK di Android che viene distribuito è associabile ad un plugin per l'IDE Eclipse: selezionando quindi l'opportuna perspective di Eclipse, permette non solo di eseguire il deployment delle applicazioni direttamente sul dispositivo mobile, o sul relativo emulatore (anch'esso incluso nella SDK), ma permette anche di eseguire il debug delle applicazioni esattamente come in un normale ambiente di sviluppo Java.
Più precisamente è possibile impostare breakpoints per bloccare l'esecuzione dell'applicazione (a runtime) mostrando un opportuno alert sul dispositivo mobile (oltretutto formattato anche molto bene e di gradevole lettura), in questo modo chi sviluppa l'applicazione può andare a visionare lo stato interno delle risorse e fare analisi sul codice.
Sempre attraverso il plugin è inoltre possibile debuggare più applicazioni contemporaneamente sullo stesso dispositivo mobile.
Attualmente Android non è esente da bachi, anzi ne sono presenti diversi, ma proprio in questo periodo Google fa sapere che a breve rilascerà un upgrade importante della SDK con i relativi bugfix delle anomalie più scomode e attese dalla community.
Dopo aver terminato un'accurata sessione di lavoro, protratta anche in seguito allo studio dei tutorial, mi sono reso conto che il mio entusiasmo iniziale, nato dalla sensazione di scoprire un bel giocattolone nuovo, invece che diminuire, è aumentato drasticamente.
Nel momento in cui si inizia a customizzare una qualsiasi applicazione si entra in un tipico loop del tipo: adesso provo quest'ultima modifica e smetto
La caratteristica più importante, a mio avviso, è la possibilità di gestire direttamente le periferiche del cellulare e le connessioni GSM, UMTS, Wi-Fi e Bluetooth.
La possibilità di interagire direttamente con i driver del dispositivo attraverso lo strato di interfacciamento Linux, credo sia un'opportunità molto importante per lo sviluppo futuro di Android.
Giusto per stuzzicare l'appetito a chi ancora non si è cimentato nello sviluppo di applicazioni su Android eccovi lo schema degli strati applicativi e delle librerie che si possono utilizzare:
Come si può vedere dall'immagine, tutto l'ambiente è basato su un kernel Linux su cui si appoggiano tutte le librerie di sviluppo denotate dal colore verde. Tra queste librerie, è importante sottolineare la presenza di due librerie opensource molto importanti: SQLite è il DBMS per la creazione e la gestione del database delle applicazioni; e WebKit la libreria utilizzata per renderizzare le pagine HTML, utilizzata anche nel browser Safari dell'iPhone.
Al di sopra delle librerie troviamo il framework da utilizzare per creare effettivamente il comportamento delle applicazioni, denotato dal colore blu, ed è essenzialmente basato sul concetto di Activity.
La runtime di Android è una vera e propria macchina virtuale chiamata Dalvik, denotata dal colore giallo, che permette l'esecuzione delle applicazioni, esattamente come avviene per la macchina virtuale Java per il bytecode.
Proprio su Dalvik ci sono state e ci sono ancora molte discussioni in ambito di licenze Java, in quanto in questo modo Google non sarebbe costretta a sottostare ad alcuna licenza Sun, in quanto Dalvik è svincolato da Java e Java MicroEdition, e non necessita di alcuna libreria runtime Java di Sun, infatti le applicazioni compilate per Android non sono compatibili con codice compilato in bytecode Java (anche perché vi è un framework associato che non è possibile separare).
A breve spero di riuscire a fare alcuni post su come si sviluppa un'applicazione in Android andando nello specifico sull'utilizzo delle singole librerie.
