martedì 21 settembre 2010

Da Windows Mobile ad Android

Android droid Questo è il primo articolo di una serie dedicata agli sviluppatori Windows Mobile che hanno intenzione di capire come effettuare il porting di una applicazione esistente o di creare una nuova applicazione per la piattaforma Android. Sto studiando queste cose per puro interesse personale e nel tempo libero: ho pensato che sarebbe stato interessante condividere le cose e i problemi che ho affrontato (e che affronterò), dal punto di vista di uno sviluppatore Windows Mobile. Così ho deciso di pianificare questa serie, che si svilupperà in futuro come tutorial focalizzati sulle minime cose da sapere per poter sviluppare con Android.

Iniziamo con un articolo introduttivo alla piattaforma, alle sue caratteristiche e alle cose che sono richieste per poter iniziare a sviluppare.

 

Requisiti Hardware e Software


Hardware

Per tutte le questioni pratiche, l’unica scelta da fare è quella di decidere se utilizzare un PC (Windows/Linux) oppure un Mac, con almeno 3GB di spazio libero su disco e 2GB di RAM. Opzionalmente, un dispositivo Android può tornare utile per testing/debug (ma tutto può essere fatto utilizzando il solo emulatore software).

 

Software

 

Android Market

Per pubblicare le proprie applicazioni sull’Android Market, è sufficiente registrarsi e pagare una sola volta una piccola quota di iscrizione all’indirizzo http://www.android.com/market/. A differenza degli store Microsoft e Apple, non c’è alcun processo di revisione da parte di Google e la distribuzione delle applicazioni tramite il Market non è esclusiva: è quindi possibile decidere di pubblicare le proprie applicazioni anche tramite altri canali. Inoltre, l’Android Market rende disponibile un meccanismo di licenza integrato e personalizzabile che permette di gestire in modo centralizzato e uniforme le proprie politiche di licenza: tramite questo servizio, le applicazioni possono interrogare l’Android Market a run-time e ottenere lo stato di licenza per l’utente corrente, modificando di conseguenza le opzioni/caratteristiche disponibili a seconda dei casi.

 

Spunti interessanti

 

Sviluppo nativo, .NET e Java

Le applicazioni per Windows Mobile possono essere scritte in C/C++ oppure, con .NET Compact Framework, in VB.NET/C#. Per scrivere applicazioni per Android, oltre ad imparare i suoi framework e diventare abili con Eclipse, bisogna conoscere Java. Se siete dei programmatori C#, a parte qualche piccola differenza sintattica e alcuni costrutti differenti, siete già in grado di leggere e scrivere programmi in Java proficuamente; se conoscete C/C++ o altri linguaggi, imparare Java non dovrebbe essere troppo difficile. Per quelli che non lo conoscono:

  • è un linguaggio orientato agli oggetti (a parte i tipi di dati primitivi, tutte le altre cose in Java sono oggetti);
  • è fortemente tipizzato (i tipi di tutti gli elementi devono essere pre-definiti e le conversioni di tipo seguono delle regole precise e limitate);
  • ha un meccanismo di gestione automatica della memoria: Java gestisce l’allocazione/de-allocazione della memoria ogni qualvolta si creano oggetti. I programmi non hanno accesso diretto alla memoria. Il garbage collector cancella automaticamente gli oggetti per i quali non esistono più puntatori/riferimenti validi e attivi. Tuttavia questo non significa che lo sviluppatore non debba interessarsi alle problematiche della memoria: memory leaks e risorse limitate sono sempre da tenere in conto;
  • è una piattaforma indipendente: un programma Java, in genere, non accede direttamente alle risorse di un sistema ma utilizza una Java Virtual Machine (JVM) come astrazione sull’hardware;
  • è un linguaggio interpretato e compilato: i sorgenti Java vengono convertiti in byte-code, il quale non dipende dalla specifica piattaforma hardware. Il byte-code sarà quindi interpretato (e/o compilato usando tecniche JIT) dalla Java Virtual machine (JVM). Nello specifico, Android utilizza una implementazione realizzata da Google della JVM: la Dalvik VM.

E’ anche possibile (a partire da Android 1.5) sviluppare applicazioni native C/C++ utilizzando l’ Android Native Development Kit (NDK).

 

Memoria ottimizzata, gestione dei processi e servizi

Come Java e .NET, Android utilizza il suo motore run-time e la virtual machine (Dalvik VM) per gestire la memoria delle applicazioni. Differentemente dagli altri, però, il run-time Android gestisce anche il ciclo di vita dei processi: assicura la reattività delle applicazioni bloccando e terminando altri processi attivi ogniqualvolta lo ritenga necessario, al fine di liberare risorse per le applicazioni a priorità più elevata in un certo momento.

In aggiunta, Android supporta applicazioni e servizi progettati per essere eseguiti in maniera invisibile e in background: i servizi permettono di realizzare componenti applicativi che monitorano ed eseguono azioni in maniera automatica e non supervisionata dagli utenti. L’esecuzione in background permette alle applicazioni di diventare event-driven e di supportare, ad esempio, aggiornamenti automatici, prioritizzare/filtrare chiamate e messaggi, etc.

 

Ambiente di sviluppo

Programmare in Java con Eclipse è molto intuitivo; Eclipse fornisce un ricco e completo ambiente di sviluppo, praticamente equivalente a Visual Studio, che include opzioni di debug avanzate (nell’emulatore o direttamente su un dispositivo fisico), aiuti/suggerimenti contestuali, auto-completamento del codice (in modo simile all’IntelliSense di Visual Studio) e molto altro. Quando il codice Java compila senza errori, il plug-in Android Developer Tools svolge in automatico tutte le procedure per creare il package applicativo, pronto e conforme per essere installato su un dispositivo, incluso il fondamentale file AndroidManifest.xml.

E’ comunque possibile sviluppare applicazioni Android senza Eclipse e il plug-in Android Developer Tools, ma in questo caso si richiede una conoscenza approfondita dell’SDK Android e dei suoi strumenti a linea di comando.

 

Interfacce grafiche (GUI)

L’interfaccia utente per un’applicazione Android può essere creata in due modi:

  • in via programmatica: usando codice Java per creare e posizionare ogni elemento dell’interfaccia (in maniera simile a come sono realizzare le interfacce utente per Windows Mobile)
  • in maniera dichiarativa: creando file XML che definiscono l’interfaccia (in maniera simile ai file XAML di WPF/Silverlight)

L’approccio dichiarativo è sempre da preferire. Un primo ovvio vantaggio è la relativa semplicità nell’apportare modifiche all’interfaccia, senza dover modificare il codice sorgente. Consiste in un insieme di tag XML specifici per le interfacce Android che possono essere utilizzati per parametrizzare e collegare insieme i numerosi componenti grafici (widget). Ogni widget nell’interfaccia utente è una View e, tipicamente, le schermate delle applicazioni sono realizzate come alberi e sotto-alberi di View.

Eclipse aiuta a creare le interface utente tramite un editor grafico drag-and-drop integrato, simile alla vista Form Design/XAML di Visual Studio. Ci sono anche altri strumenti di sviluppo che permettono di analizzare/modificare a run-time, direttamente nell’emulatore o su un dispositivo fisico, le interfacce utente ed esiste, inoltre, uno strumento open-source che può aiutare a progettarle graficamente: DroidDraw.

 

Android, grafica e giochi

Anche se Java è il linguaggio principale per lo sviluppo su Android, Google si è resa conto della necessità di avere un sistema combinato Java/C per poter permettere alla sua piattaforma di aver successo anche nel campo dei videogiochi: così hanno rilasciato il Native Development Kit (NDK) a partire da Android 1.5. Google ha capito la necessità di supportare lo sviluppo in C per assicurarsi il porting su Android del grande numero di giochi sviluppati nativamente per altre piattaforme, come iPhone. Lo stesso vale anche per i giochi per PC o console (che esistono da qualche decennio e sono spesso scritti in C/C++): potenzialmente, usando un “semplice” compilatore C per ARM, è ora possibile portare migliaia di giochi esistenti su Android con relativo poco sforzo. In più, Android fornisce ricche librerie grafiche 2D e 3D (con OpenGL), per aiutare gli sviluppatori a sfruttare al massimo, e in modo semplice, il potente hardware che equipaggia i dispositivi mobili oggigiorno. Android offre anche estese librerie per gestire immagini, video e audio, inclusi i formati JPG, PNG, MPEG4, H.264, MP3, AAC.

 

Accesso facilitato all’hardware

In Windows Mobile l’hardware è accessibile tramite applicazioni native C/C++ oppure con wrapper che sfruttano la modalità P/Invoke per chiamare funzioni native da applicazioni .NET Compact Framework. Android, invece, include librerie ed API per semplificare le interazioni con l’hardware: questo permette di evitare la realizzazione di applicazioni differenti a seconda dei dispositivi su cui devono essere eseguite, garantendo che il software funzionerà in maniera pressoché identica su ogni dispositivo che supporta la medesima versione di Android.

L’SDK di Android include, tra le altre cose, anche API per l’hardware di localizzazione (come il GPS e la tecnologia di Google per la localizzazione tramite rete cellulare), la fotocamera, l’audio, la rete, il Wi-Fi, il Bluetooth, gli accelerometri, il touch-screen e il power management.

 

Personalizzazione: tutte le applicazioni sono create uguali!

Quante volte, come sviluppatore Windows Mobile, avete desiderato di cambiare l’aspetto della schermata principale, creare una versione alternativa del gestore della rubrica o dei messaggi, o interagire a basso livello con i contatti, le chiamate, i messaggi? Quanto tempo e codice ci avete messo per ottenere un risultato soddisfacente? Con Android, dimenticate la fatica. Il sistema è stato progettato in modo tale da non differenziare tra le applicazioni native e quelle sviluppate da terze parti. Questo permette agli utenti e agli sviluppatori di poter cambiare l’aspetto e le funzionalità dei propri dispositivi sostituendo qualunque applicazione nativa con un’altra di prodotta da terzi, la quale ha accesso completo alle medesime funzionalità hardware e gli stessi dati.

 

Comunicazione tra applicazioni e database SQLite

Non c’è praticamente equivalente in Windows Mobile (anche se è possibile realizzare la cosa, ma per raggiungere gli stessi risultati ci sono molte difficoltà). Android include tre tecniche per trasferire dati e informazioni tra applicazioni e utilizzarli ovunque: intenzioni (Intents), notifiche (Notifications) e fornitori di contenuti (Content Providers).

· Gli Intents forniscono un meccanismo per scambiare messaggi internamente ad un’applicazione o tra applicazioni differenti. Usando le intenzioni, è possibile trasmettere a tutto il sistema la richiesta di effettuare un’operazione (es. comporre un numero, mandare un SMS, modificare un contatto della rubrica) e, se ci sono applicazioni registrate per gestire tale richiesta, queste saranno automaticamente avviate per soddisfarla.

· Le Notifications sono il mezzo standard attraverso il quale è possibile avvisare gli utenti: usando le API, ad esempio, si possono attivare la vibrazione, emettere suoni, controllare le icone della barra di stato, far lampeggiare il LED del telefono.

· Infine si possono usare i Content Providers per permettere ad altre applicazioni di accedere ai dati interni di una applicazione. Ad esempio, Android memorizza tutti i dati delle applicazioni native (messaggi, rubrica, lista chiamate, etc.) in database interni che vengono resi disponibili alle altre applicazioni tramite appositi Content Providers, in maniera tale da permettere ad altri di leggere e modificare i dati.

Per ogni applicazione, poi, Android fornisce un database relazionale, leggero ed integrato: SQLite. Come utenti Windows Mobile, probabilmente sarete abituati ai database SQL CE. Sono potenti, ma nulla in confronto a SQLite per prestazioni e occupazione delle risorse. Le vostre applicazioni possono avvantaggiarsi di questo database relazionale per memorizzare dati in maniera sicura ed efficiente. Per default, ogni database di ogni applicazione è isolato dagli altri (Sandbox): questo significa che il suo contenuto è accessibile solo all’applicazione che l’ha creato. Tuttavia, tramite il meccanismo dei Content Providers, è possibile decidere di renderlo disponibile a terzi in maniera semplice e controllata.

 

Prossimamente

Sto attualmente lavorando, nel tempo libero, su due progetti in ambito Windows Mobile. Ho iniziato a pianificare e ad analizzare le cose per effettuare il porting di uno dei due applicativi su Android e la mia idea è quella di utilizzare l’applicativo come oggetto dei prossimi futuri articoli. Ecco alcuni degli argomenti:

  • Uno sguardo ad Eclipse
  • Come create/debuggare/eseguire un progetto Android
  • Creare l’interfaccia utente
  • Accedere e controllare l’hardware
  • Localizzazione
  • Package e distribuzione

Se siete interessati a qualcosa in particolare o se avete commenti/domande, fatemi sapere!

sabato 11 settembre 2010

Aggiornamento su Embedded Sparks Summer 2010

Anche per questa edizione del concorso non ho avuto abbastanza tempo libero durante l’estate per sviluppare il dispositivo. Ho solamente iniziato a provare e implementare alcuni moduli software a livello prototipale, in modo da poter convalidare l’architettura progettata e per verificare se le prestazioni dello Spark Kit fossero sufficienti a supportare la mia idea. Sfortunatamente l’hardware non mi è parso abbastanza potente per gestire contemporaneamente la decodifica DVB-T (tramite un ricevitore esterno USB della Avermedia) e grafica WPF avanzata, così ho deciso di interrompere lo sviluppo.

Qui ci sono alcune foto che ho scattato durante l’assemblaggio del dispositivo:

Ora il concorso è entrato nella sua fase finale e i tre finalisti sono stati annunciati questa settimana. Buona fortuna a tutti!

Nuove certificazioni Microsoft

A marzo avevo annunciato il mio obiettivo di studiare in primavera per ottenere nuove certificazioni Microsoft. A fine aprile ho avuto l’opportunità di sostenere la versione beta dell’esame .NET Framework 4, Windows Applications development. Nell’ultima settimana di giugno, mi è stato comunicato il fatto di averlo passato! E, nella stessa settimana, ho passato anche l’esame Microsoft Windows Embedded Standard 7 for Developers. Ora, insieme alle certificazioni Windows CE 6.0 e Windows Mobile 6.5, sono un “completo” Microsoft Certified Technology Specialist nel campo embedded.