Fleux .NETCF UI Library – Contributi KitchenPal

E’ ora possibile scaricare la versione modificata del fantastico progetto Fleux di José Gallardo Salazar, che ho usato per realizzare l’interfaccia Metro-style di KitchenPal. Ho implementato alcuni controlli custom (Tile, ApplicationBar, Textbox, Checkbox, Button, ImageButton, WrapPanel) e aggiunto un supporto generico per dispositivi Windows CE 6.x/7.x, oltre a Windows Mobile. Magari in futuro queste modifiche saranno integrate nel progetto principale. Per ora, scaricate i sorgenti da qui e utilizzateli nei vostri progetti embedded! Fatemi sapere se li impiegate da qualche parte o se trovate problemi/fix.

Vincitori embeddedSPARK 2011

Sono appena rientrato da Seattle, dove io e gli altri finalisti abbiamo trascorso una splendida settiamana. Prima di tutto… i risultati!

• 1° posto: Sebastian Londoño, Colombia – ArS8VER
• 2° posto: Gianni Rosa Gallina, Italia - KitchenPal
• 3° posto: Marco Bodoira, Italia - Digital Blackboard

Congratulazioni a tutti e ringraziamenti speciali a Microsoft (grande lavoro organizzativo da parte di Gitte-Lena, conosciuta anche come Steel) e ai giudici, Olivier Bloch, Samuel Phung e Mike Hall, per la grande esperienza che abbiamo avuto!

E’ stata una settimana nuvolosa e fredda (rispetto al clima italiano di questa stagione), ma non ha piovuto e, addirittura, abbiamo avuto un paio di giorni di piacevole e caldo sole! Abbiamo potuto visitare qua e là Seattle e il campus Microsoft in Redmond, abbiamo incontrato qualche persona di Microsoft e abbiamo parlato di Windows, Windows Embedded e del futuro. Ci saranno grandi novità, basta avere ancora un po’ di pazienza per qualche mese…

Concorso embeddedSPARK 2011 – Fase 2

Ci siamo! Finalmente, dopo più di tre mesi di duro lavoro, il prototipo di KitchenPal e delle sue app per Smartphone sono pronti.

Potete vederli alla pagina ufficiale del concorso. E’ disponibile anche la versione italiana del video, qui.

Questa volta ce l’ho fatta. E’ stata dura, ma molto divertente ed interessante. Presto i risultati…

Da Windows Mobile ad Android

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

• Sistema operativo:
  • Windows XP (32bit), Windows Vista (32/64-bit) o Windows 7 (32/64-bit)
  • Mac OS X 10.5.8 o successive (solo x86)
  • Linux (32bit)
• JDK 5 o JDK 6
• Eclipse IDE 3.4 o 3.5
• Eclipse JDT plug-in
• Android Development Tools (ADT) plug-in (opzionale)
• Android Software Development Kit
• Almeno una piattaforma Android (es. Android 1.5, Android 1.6, Android 2.2, etc.)
• Altri componenti ausiliari dell’SDK (es. per Windows, il driver USB per collegare il telefono al PC)

 

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!

Concorso Embedded ed esami di certificazione Microsoft

Alcune settimane fa avevo annunciato che avrei scritto alcuni post a proposito del lavoro per il concorso Microsoft Embedded Sparks 2010. Purtroppo, a causa del poco tempo libero nell’ultimo periodo e per alcune problematiche hardware/software nella preparazione del prototipo, ho dovuto interrompere lo sviluppo. Sarà magari per il prossimo anno…

Nel frattempo, ho anche studiato per dare due esami di certificazione Microsoft. Ho dato il primo a metà dicembre: era la versione beta dell’esame Windows Mobile 6.5 - Application Developer. Ho ricevuto comunicazione del fatto di averlo passato appena dieci giorni fa. E lo scorso mercoledì ho dato e passato l’esame Windows Embedded CE 6.0 - Development. Adesso sono un Microsoft Certified Technology Specialist nel campo embedded… ma questo è solo l’inizio: ho già iniziato a studiare per un nuovo esame embedded, Windows Embedded Standard 7 for Developers (precedentemente noto come Windows Embedded Standard 2011), che darò appena sarà disponibile (probabilmente per metà giugno).

Phome: un telefono di casa di nuova generazione

E’ passato un po’ di tempo dal mio primo post. Mi ero promesso di dedicare il giusto tempo e sforzo per scrivere regolarmente articoli sui miei interessi tecnologici, ma sfortunatamente ho fallito. Nei due mesi trascorsi sono stato molto occupato. Per la precisione, non solo nei due mesi passati, ma negli ultimi dieci: al di là di terminare gli esami all’università, ho lavorato quasi ogni giorno (e notte) alla mia tesi di laurea specialistica. Finalmente, ora è tutto concluso.

Questa è la descrizione di cosa ho sviluppato, magari a qualcuno di voi potrebbe interessare.

L’inizio: la casa digitale del futuro

Tutto è iniziato nel dicembre 2008. Stavo cercando un’idea per partecipare al concorso internazionale SPARKS Will Fly 2009, organizzato da Microsoft per promuovere le sue tecnologie embedded tra gli sviluppatori hobbisti e gli appassionati di tecnologia. Il tema del concorso era la casa digitale del futuro: per partecipare era necessario inviare un documento di 1-3 pagine che descrivesse un progetto embedded realizzabile con tecnologie Microsoft Embedded quali Windows Embedded CE 6.0 R2, Visual Studio 2005 e un kit EmbeddedSpark (VIA ARTiGO A1000 Barebone Pico-ITX).

L’idea mi è stata suggerita dalla mia nonna ottantenne, dopo la quotidiana “lezione tecnologica” per spiegare il funzionamento del telefono cellulare, dei telecomandi per TV+Videoregistratore+DVD (o in generale, ogni altro dispositivo tecnologico). Ho avuto una visione di una possibile parziale soluzione al problema che la gente continuamente affronta ogni giorno.

Siamo circondati da un’infinità di dispositivi e mezzi di comunicazione: telefoni, telefoni cellulari e smartphone, personal computer, palmari, televisori, dispositivi Media Center, console per videogiochi, applicazioni di Instant Messaging, browser Web, client E-Mail, software per comunicazioni VoIP, etc.
Al di là della linea di comunicazione c’è il mondo intero, ma spesso tutte queste tecnologie sono progettate per essere usate da solo una minoranza dei componenti familiari, per persone giovani, predisposte alla tecnologia e sempre in movimento: bambini, ragazzi e genitori. E gli altri? Anziani, casalinghe spaventate dalla tecnologia, persone disabili, persone che non hanno in casa ragazzi “tecnologici” che possano aiutarle, persone che pensano che mandare un SMS o navigare sul Web sia troppo complicato? Perché la nonna non può chattare, navigare sul web o inviare una E-Mail o un SMS? E come fare se vive da sola e soffre di qualche malattia (es. sordità, cecità, etc.) e volesse chiamare qualcuno, tenersi in contatto con i parenti o ricevere telefonate?

La maggior parte dei dispositivi sono troppo difficili da usare per le persone non-tecnologiche e offrono le loro funzionalità in modi inaccessibili, con centinaia di pulsanti, menu, sotto-menu, opzioni. Ogni dispositivo è differente dall’altro (le interfacce utente sono complesse e richiedono addestramento e pratica prima che sia possibile usarne al massimo le funzioni) e raramente possono condividere dati in maniera semplice ed automatica.

E se ci fosse qualcosa che potesse gestire tutte le comunicazioni in maniera consistente, automatica, semplice e accessibile per ogni membro di una famiglia?

Questo è il documento inviato nel gennaio 2009 alla prima fase eliminatoria del concorso: Home Communication Concentrator (HCC).


HCC: prototipo per il concorso

La vision immaginata per l’Home Communication Concentrator consiste in una rete cablata/wireless di sistemi embedded con schermo sensibile al tocco, che permette di gestire tutte le comunicazioni di casa progettata specificamente per persone non tecnologiche. I dispositivi possono essere posizionati ovunque, dove meglio si integrano con i propri bisogni e gli stili architetturali della propria casa: possono essere messi su superfici piatte o appesi ai muri.


L’attività principale di un dispositivo HCC è quella di monitorare e gestire le comunicazioni:

• Telefonate / video chiamate (se è disponibile una webcam) / VOIP
• E-Mail
• Instant Messaging e chat
• Navigazione Web
• Rubrica / Calendario / lista delle cose da fare

Tutte le attività possono essere controllate direttamente tramite comandi vocali o con un tocco sul display. L’interfaccia utente è molto semplice e non c’è bisogno di addestramento: svolgere qualunque attività è semplice quanto fare una telefonata (o addirittura più semplice). Il sistema può interagire con l’utente tramite voce e suoni e/o tramite messaggi testuali e immagini sullo schermo.
Mentre non è in uso, un dispositivo HCC può essere usato come cornice digitale per sequenze di fotografie, riproduzione video o per quasi qualunque cosa potrebbe venire in mente a qualcuno (è possibile estenderne le funzionalità con widgets personalizzati).

L’idea proposta è passata alla selezione della prima fase (50 partecipanti su più di 150) e tra gennaio e marzo 2009 ho iniziato a sviluppare un prototipo funzionante del sistema, usando Windows Embedded CE 6.0 R2, Visual Studio 2005 e il kit VIA Artigo. Per partecipare alla seconda fase del concorso bisognava inviare un video di 2 minuti che mostrasse il dispositivo in funzione.
Il video dell’HCC è disponibile qui. E qui c’è il documento descrittivo allegato.

Sfortunatamente il dispositivo non è passato alla fase finale, ma nel contempo ho presentato lo studio di fattibilità prototipale ad un mio professore del Politecnico di Torino, Giovanni Malnati, che ha acconsentito per continuare il lavoro come tesi di laurea specialistica in Ingegneria Informatica. Grazie a lui, a Beppe Platania (Beps Engineering) e a Raffaele Menolascino (Microsoft), ho sviluppato la tesi presso il Microsoft Innovation Center Torino.

Phome: tesi, tecnologie e architettura

L’obiettivo principale della tesi è stato il progetto e lo sviluppo prototipale di un sistema embedded per telecomunicazioni di nuova generazione, che in un prossimo futuro potrebbe sostituire nelle nostre case il telefono, rendendo accessibili a tutti i membri familiari (dai più giovani ai meno giovani, con un occhio di riguardo per gli anziani e per le persone che soffrono di handicap o altri disturbi) i moderni mezzi di comunicazione, quali Internet, E-Mail, SMS, sistemi di Chat e Social Networking, VoIP e, ovviamente, le telefonate tradizionali. Tra i requisiti di sviluppo è stato richiesto che la soluzione proposta fosse realizzabile con tecnologie attualmente disponibili (in particolare Microsoft Embedded), in modo da poter contenere i costi hardware e software e per avere un breve time-to-market.

A causa dei molti problemi affrontati durante lo sviluppo del prototipo per il concorso, in particolare la mancanza in Windows Embedded CE di un framework per la creazione di interfacce utente ricche ed accattivanti e le limitazioni hardware del kit (problemi di compatibilità dell’adattore Bluetooth USB, piccolo display touch, connettività di rete limitata), per il lavoro della tesi ho deciso di cambiare hardware e adottare un’altra tecnologia Microsoft Embedded. Così il nuovo prototipo è stato implementato usando un dispositivo Asus EeeTop equipaggiato con un’immagine personalizzata di Microsoft Windows Embedded Standard (WES). La parte di telefonia è fornita al sistema tramite un telefono cellulare Bluetooth HTC Touch Diamond, basato sul sistema operativo Microsoft Windows Mobile 6.1.


Phome è un dispositivo all-in-one, dall’aspetto accattivante e che costituisce un telefono di casa di nuova generazione: ingloba le funzionalità di telefono, gestione SMS, gestione E-Mail, browser Internet e cornice digitale in un unico dispositivo, offrendo un’interfaccia utente touch-friendly semplice, intuitiva, pensata soprattutto per l’uso da parte di persone anziane o poco pratiche di tecnologia e che richiede quindi solo un minimo sforzo di apprendimento. L’interfaccia, tra le altre cose, include funzionalità come tastiera virtuale e tastierino numerico virtuale per l’uso senza tastiera/mouse esterni, un sistema di input predittivo ad ampio vocabolario per facilitare la digitazione, funzionalità Text-To-Speech per ausilio alla visualizzazione.

Le funzionalità di telefonia ed SMS sono fornite tramite un telefono cellulare collegato via Bluetooth: Phome è un’unità Bluetooth Headset “da casa” e, quando connesso ad un dispositivo, ne diventa l’auricolare offrendo funzionalità di vivavoce; inoltre, grazie ad un profilo Bluetooth appositamente progettato, il Phome Mobile Service, basato su un protocollo client/server ad-hoc, rappresenta una semplice ed intuitiva interfaccia di controllo remoto del telefono, permettendo anche agli anziani di poter usare un cellulare e inviare/ricevere SMS o gestire la rubrica. Si è resa necessaria tale implementazione per poter astrarre dal particolare tipo di modello e sistema operativo, rendendo Phome potenzialmente compatibile con qualunque telefono Bluetooth. Il prototipo è stato sviluppato su un telefono Windows Mobile (usando .NET Compact Framework 3.5, ma è stato condotto uno studio di fattibilità anche su Android e piattaforme che supportano Java J2ME).

Per aggiungere la connettività Bluetooth all’EeeTop, è stato impiegato un adattatore Bluetooth USB con supporto allo stack Widcomm: questo stack è infatti l’unico che fornisce API gratuite, ben documentate e che permettono agli sviluppatori di accedere agli strati bassi dello stack, audio SCO incluso, consentendomi di re-implementare il profilo Bluetooth Headset (auricolare) secondo le specifiche standard e poter così controllare direttamente il routing audio con le API Multimediali Win32.

Oltre all’immagine di sistema WES, ho progettato e realizzato:

• un applicativo Windows Presentation Foundation, PhomeUI, che ha la funzionalità di shell di sistema e che va a sostituire la shell nativa “explorer” di Windows; è stata progettata adottando una struttura modulare e stratitificata, impiegando anche recenti design pattern, tra cui Model-View-ViewModel (MVVM), Separated Presentation e Composite Application, per permettere la separazione dei ruoli designer/sviluppatore, supportare l’estendibilità/plug-in, la testabilità e un framework evoluto per lo sviluppo di interfacce grafiche (che mi ha permesso di implentare tutta l’interfaccia grafica in meno di due mesi, mentre venivano sviluppate contemporaneamente le altri parti di sistema).

• librerie condivise (in parte native C++ e in parte managed) che forniscono le funzionalità alla shell per quanto riguarda:
  
  • Gestione Bluetooth + profili (nativa)
  • Gestione dell’audio Bluetooth (nativa)
  • Accesso ai database MS-SQL CE a tre livelli
  • Molti controlli WPF UI personalizzati
  • Funzionalità di base per la shell e per i moduli (eventi, comandi, Bluetooth Manager, Audio Manager, E-Mail Manager/POP3 Client, Settings Manager, Text-To-Speech con MSAPI 5.1)
  • Funzionalità di base per l’interfaccia grafica e per i moduli (Application Manager, Module Manager, Virtual Keyboard/Numpad, altri controlli UI)

• un applicativo .NET Compact Framework 3.5, PhomeServiceServer, per realizzare il servizio Bluetooth Phome su telefoni cellulari Windows Mobile 6.0 o successivi.
  

• moduli applicativi di esempio realizzati usando il pattern MVVM, per fornire all'utente:
  
  • funzionalità di telefonia (composizione, rubrica, preferiti);
  • gestione SMS (ricevuti, inviati, bozze, composizione, Tastiera virtuale + Input Predittivo);
  • gestione E-Mail (supporto per account POP3 multipli, E-Mail ricevute/inviate/bozze, composizione);
  • Impostazioni / configurazione Bluetooth con singolo tocco;
  • Home screen;
  • Web Browser (basato sul progetto Google Chromium, integrato in WPF tramite un wrapper open-source modificato per poterlo usare con la tastiera virtuale e renderlo compatibile con gli accorgimenti touch-friendly adottati nel resto dell’interfaccia);
  • Album foto (visualizzatore e presentazione a schermo intero).

Qui ci sono alcuni screenshot e foto del dispositivo e dell’interfaccia utente, realizzate durante lo sviluppo.

Conclusioni

Il sistema prototipale realizzato possiede un insieme minimo di funzioni che permettono alle persone e agli sviluppatori di valutare praticamente l’utilità e l’efficacia di un dispositivo simile in un generico contesto casalingo. L’obiettivo non era avere un prodotto completo e finito, ma quello di mostrare che dispositivi semplici da usare ed integrati possono già essere realizzati oggi, con tecnologie hardware e software già disponibili, a confronto con le migliaia di complicati dispositivi di comunicazione che ogni giorno ci circondano.

Ovviamente c’è ampio spazio per miglioramenti e ho già un po’ di idee per sviluppi futuri e una migliore interazione uomo-macchina e integrazione nel contesto casalingo, ma per il momento sono molto soddisfatto dei risultati raggiunti, della laurea e sono felice del fatto che ora mia nonna può inviare e ricevere SMS/E-Mail ed effettuare telefonate usando il telefono cellulare con appena qualche tocco su Phome.