È stato appena pubblicato il toolkit grafico LWUIT (Lightweight UI Toolkit) realizzato da Sun Microsystems e destinato ai terminali MIDP. LWUIT supera i limiti della libreria LCDUI di componenti nativi del Mobile Information Device Profile, offrendo un approccio simile a Swing ma evidentemente semplificato, ma allo stesso tempo ricco di componenti e funzionalità

In attesa di poterlo provare e valutare in maniera più dettagliata, una breve carrellata delle funzionalità permette di cogliere l’importante di questo progetto. Tra i componenti sono disponibili i pulsanti, liste, menu, checkbox, radio button e dialog (FINALMENTE!). I componenti possono essere organizzati attraverso layout complessi e animati con effetti quali scorrimenti, rotazioni, gradienti e così via. È presente una estesa gestione dei font e dei temi, che consentono di cambiare al volo il look dell’applicazione.

L’ho provato su un Nokia 6120 (Series 60 3rd Edition) e su un Sony-Ericsson W910i (JP-8) e l’effetto è davvero molto gradevole. Sul Sony-Ericsson è leggermente più veloce, mentre sul Nokia le animazioni appaiono in qualche modo più gradevoli (anche se talvolta troppo lente).

Sono già disponibili i binari della libreria, il javadoc e un tutorial: puntate i browser su https://lwuit.dev.java.net/.

Ecco qualche snapshot dell’applicazione demo, eseguita sul Nokia 6120c:

Il pesciolino del tema Ocen (l’ultimo qui sopra) sguazza tranquillo, proprio come se si trattasse di uno degli ormai diffusi temi realizzati in Flash. Chissà se avrà più successo il LWUIT o il progetto Capuchin di Sony-Ericsson, che mira all’integrazione di Java e Flash Lite. Staremo a vedere. Il 2008 è sempre più interessante….

La Public Review Draft di MIDP 3 è stata approvata. Ancora un piccolo passo verso MIDP 3 (ragazzi, sbrigatevi, che la concorrenza [iPhone, Android…] è alle porte!).

La notizia sta facendo il giro del mondo: Sun Microsystems ha annunciato che sta lavorando ad un porting della Java Virtual Machine ed in particolare ad una implementazione di Java Micro Edition per l’iPhone di Apple. L’annuncio arriva a 24 ore dal rilascio dall’SDK ufficiale, conditio sine qua non per poter intraprendere lo sviluppo di applicazioni con la benedizione di Apple.

Qualcuno ha anche ricordato che all’indomani della presentazione dell’iPhone Sun auspicò che il nuovo device fosse dotato di runtime Java. Auspicio completamente ignorato da Apple. Ora che c’è l’SDK, Mamma Sun deve farsi il runtime da sé.

Una sconfitta? Ovvero: Sun deve arrendersi al fatto che Apple snobba JME ed è costretta a farsi il runtime da sé? Direi di no. Qualche riflessione:

• Partiamo da lontano. Gli sviluppatori JME dipendono inevitabilmente da due componenti: IDE e emulatori, che comprendono toolchain e librerie. Nella fattispecie, Netbeans e il Wireless Toolkit rappresentano la dotazione standard di ogni sviluppatore. È ormai noto che il Wireless Toolkit e, di conseguenza, il Mobility Pack di Netbeans non sono disponibili per Mac. Stessa situazione per emulatori ed SDK dei vari manufacturer. La domanda (polemica) nasce spontanea: perchè Apple avrebbe dovuto supportare JME sull’iPhone, se Sun per prima ha completamente ignorato lo sviluppo JME su Mac OS X?. Il fatto, poi, che l’SDK dell’iPhone sia disponibile solo per Mac OS X la dice lunga sull’atteggiamento di Apple che si potrebbe sintetizzare in questa frase: "nello sviluppo mobile siamo finora stati ignorati da tutti (Sun, Nokia, Motorola, Microsoft [ovvio!]… con la sola eccezione Adobe); ora che il device più desiderato è il nostro, saranno gli altri a doversi muovere verso Mac OS X". Non fa una piega. Chi di spara ferisce, di spada perisce. Occhio per occhio, dente per dente. Insomma, cercate il proverbio che più vi piace.
• Assodato che l’iPhone è ormai protagonista del mercato dei mobile device e che, dunque, non si può né ignorare né boicottare, chi vuole portarvi la propria tecnologia deve rimboccarsi le maniche e lavorarci sopra. Va da sé che la qualità del porting dovrà essere assoluta e frutto di un lavoro meticoloso, sia per la grafica che per le funzionalità. Sull’iPhone, infatti, non si trovavo le incoerenze di molti sistemi operativi più o meno proprietari che popolano i telefoni di mezzo mondo. L’obiettivo è arduo e la posta in gioco elevata. Da qui la domanda: perchè Sun dovrebbe affidare/delegare ad altri lo sviluppo del runtime JME, rischiando magari che un lavoro di scarsa qualità ne comprometta la credibilità sull’iPhone? Guardando alla babele che esiste nel mondo JME vien proprio da chiedersi se sia stata una buona idea quella di consentire a chiunque di scrivere i runtime Java embedded o se forse non sarebbe stato meglio avere un maggiore convolgimento da parte di Sun. Il cuore ha sempre suggerito di avere un approccio aperto, la storia ha dimostrato che tutti i runtime desktop alternativi sono stati abbandonati in favore di quello Sun, che nel frattempo è stato perfezionato, migliorato, velocizzato. Nel Micro World, invece, gli sviluppatori sono costretti a scrivere una applicazione per ogni diversa famiglia di terminali (come se su desktop si dovesse scrivere una versione per ogni rilascio di CPU da parte di Intel e AMD!) e spesso il risultato non è garantito. Libreria standard ed API opzionali, infatti, mostrano comportamenti imprevedibili, rendendo impossibile realizzare applicazioni che sulla carta appaiono scontate (per le caratteristiche del device, per ciò che dichiara il manufacturer…). Ben venga, dunque, che Sun rilasci una Java Virtual Machine e un runtime Java Micro Edition ufficiali per l’iPhone e che garantisca agli sviluppatori che le applicazioni Java troveranno realizzati in questo device il paradigma "Write Once, Run Everywhere". Mi piace ricordare che il runtime Personal Java sviluppato da Sun per i primissimi iPaq era eccezionale se confrontato con i successivi Jeode o CrEme, che mostravano UI completamente incoerenti rispetto al sistema operativo sottostante. Per parecchio tempo ho preferito usare quella beta di Personal Java piuttosto che usare quegli accrocchi! Poi è arrivata IBM con J9 e le cose sono andate meglio… più o meno. Ma questa è un’altra storia!
• Così diversi sono i gusti delle persone da una nazione all’altra, da un continente all’altro, da un livello sociale ad un altro, che è praticamente impossibile pensare di progettare e realizzare un oggetto che piace a tutti indistintamente. O, meglio, che tutti sarebbero disposti a comprare. Ecco perchè alla lunga, a mio avviso, l’approccio JME (una piattaforma per qualsiasi device) sarà vincente rispetto a soluzioni chiuse come Windows Mobile, Symbian o lo stesso Android. Quest’ultimo, infatti, non è un semplice runtime ma la somma di sistema operativo, runtime Java sui generis e libreria di componenti. Affronterà Google il porting dei due livelli superiori per l’iPhone? Lo farà per gli smartphone Symbian? Non credo. Ragionamento diverso è stato fatto da Adobe e Microsoft, ben intenzionati a far funzionare Flash e Silverlight ovunque. Allora il risultato è scontato: Android è l’ennesima nuova piattaforma su cui fare porting delle applicazioni e, come tale, un vicolo cieco. Lo stesso vale per lo sviluppo Objective-C su iPhone, ovviamente! Man mano che le piattaforme native o pseudo-native si moltiplicano diventa sempre più difficile per le piccole realtà (piccole ma vivaci e in grado di portare nuove idee) riuscire a supportarle tutte, con il risultato che intere fette di potenziali utenti vengono inesorabile tagliate via. Proviamo a contarle: Windows Mobile, PalmOS, Blackberry, Symbian (divisa in Series 60 e UIQ), iPhone, Android, OpenMoko, MOTOMAGX (di cui però si sa ancora poco della piattaforma nativa). E poi c’è Java, trasversale con parecchia fatica. Ho l’impressione che anzichè migliorare si stia peggiorando: prima tre sistemi (Windows, Symbian con l’aggiunta di Linux e/o PalmOS, il primo adolescente e il secondo agonizzante), oggi sicuramente sei.
• L’avvento di soluzioni migliori, così mi sembrano l’iPhone e Android per aspetti diversi, sarà inevitabilmente di stimolo anche per gli altri attori di questo mercato. Ad esempio, per Nokia, impegnata più a vendere telefoni che a fare vera innovazione. Ad esempio, per il JCP, accusato da più parti di aver deluso le aspettative in termini di qualià (alla fine i manufacturer fanno come vogliono!) e di velocità (MIDP 3 sembra non arrivare mai…).

In conclusione, penso che sia da apprezzare lo sforzo di Apple per realizzare l’SDK per l’iPhone (tornando indietro sui suoi passi, dunque) e l’entusiasmo di Sun nel realizzare in tempi brevi il runtime JME per questo device. Se entrambi lavoreranno bene sicuramente saranno di esempio per tutti gli altri, facendo in modo che venga voglia di emulare e superare i propri concorrenti per la qualità e non solo il fatturato.

Annuncio a sorpresa al GSMA Mobile World Congress di Barcellona: Sony-Ericsson, finora fedele alla sua Java Platform e a UIQ 3.0, introduce un nuovo terminale basato su Windows Mobile 6. Si chiama XPERIA X1, ha una interfaccia touchscreen, design a conchiglia e tastiera estraibile lateralmente.

Newsletter e blog hanno sottolineato l’importanza di questo passaggio nella strategia di Sony-Ericsson. Perchè Windows Mobile? Forse perchè la specializzazione Symbian della casa svedese (UIQ) non ha raggiunto il successo della Series 60 di Nokia? Sembrerebbe di no, visto che sono stati contemporaneamente annunciati due nuovi terminali basati su questa piattaforma, gli smartphone G700 e G900. Dunque, la causa sembrerebbe non essere UIQ. Potrebbe essere un tentativo di esplorazione di un mercato (quello Windows Mobile, appunto) in crescita ma del tutto snobbato dai finlandesi? Questa ipotesi appare più probabile.

Appena apparse le informazioni sul portale sviluppatori Sony-Ericsson, però, la mia curiosità è stata un’altra: sarà presente un runtime Java ME, pur trattandosi di Windows Mobile? La risposta è affermativa, anche se il set di API è piuttosto ristretta e non è dato sapere da quale codebase derivi (una JP? J9? altro?):

• CLDC 1.1 e MIDP 2.0
• PIM & FC API – JSR 75
• Wireless Messaging – JSR 120
• Mobile Media API -JSR 135

Insomma, siamo tornati indietro di quasi cinque anni (caratteristiche simili le aveva il buon Nokia 6600). Stupisce la mancanza della JSR 82, della Location API (visto che c’è il supporto A-GPS…). Il terminale ha uno schermo spaventoso, ben 800×480 pixel: non sarebbe stato male avere la JSR 226 per il rendering di grafica SVG. Questa poverissima dotazione sembra più un contentino che una concreta volontà di supportare Java ME su Windows Mobile. Che amarezza…