Vi segnalo il blog bitematico J2MESoccer, curato da Emanuele Pecorari. Come dice il nome, questo blog parla di Java Micro Edition e di calcio; vista la mia totale indifferenza al secondo, lo apprezzo per il primo tema, in particolare per la tenacia nel trovare (e raccontare) i bug riscontrati sui runtime Java dei terminali più diffusi.
Archivi categoria: Mobile
La frammentazione dell’offerta Linux per device mobili
Riprendo il mio post fatto qualche tempo fa a proposito del lancio di Android e un interessante articolo scritto da Tony Mobily su Free Software Magazine.
In buona sostanza, è sempre più evidente che la frammentazione della piattaforma Linux produce come unico risultato la dispersione delle forze (gratuite) della community, la creazione di inutili antagonismi (Tony cita più volte quella tra Gnome e KDE, ma potrebbero esserci tanti altri esempi validi, come quella tra Netbeans e Eclipse nel mondo Java), la dilagante incompatibilità di software etichettato “per Linux” tra diversi dialetti del sistema operativo.
Il problema, ben noto in ambiente desktop, si sta riproponendo nel mondo mobile. Fioccano i progetti, sorgono community, appare timidamente qualche device.
Perchè tutto questo? Mi verrebbe da dire che ciascuno aspira a diventare il vincitore della crociata pro-mobile-Linux e dunque non ha nessuna intenzione di condividere lo scettro con altri. E proprio qui sta l’errore: il podio dei vincitori e’ enorme, gigantesco, non esiste un secondo posto. Guardando agli albori di Linux, penso al messaggio di Linus ma al contemporaneo sforzo del progetto GNU nel produrre compilatori, librerie e tutto il resto. Chi vince? Linus? O Stallman? A me sembra tanto che l’uno senza l’altro avrebbero fatto poca strada (o comunque l’avrebbe fatta in tempi decisamente più lunghi).
Esistono anche esempi contrari, che dimostrano come la scelta di una sola piattaforma/libreria/API porti inevitabili vantaggi. Rimanendo nel mondo Linux, penso a cosa è accaduto a Bluez e Affix, librerie per l’accesso allo stack Bluetooth. Dopo un breve periodo di coesistenza, si è di adottare Bluez come libreria standard, ufficiale per Linux. Affix, sviluppata direttamente da Nokia, è stata messa da parte, ma è innegabile che la community ne abbia avuto un beneficio: Bluez è stata continuamente migliorata, sono stati realizzati binding per tutti i linguaggi di programmazione, il porting su diverse piattaforme hardware è stato incoraggiato.
Torniamo al mondo mobile. Cosa accadrà a OpenMoko, Maemo, Android e Qtopia? Aggiungo, a quanto elencato da Tony, altri quattro player: Moblin di Intel, MOTOMAGX di Motorola (attesa per febbraio), ALP (Access Linux Platform) di Access, Java FX Mobile di Sun Microsystems. Ben otto piattaforme per il mobile computing. I magnifici 8 o gli 8 dannati?
Chi, nella community, avrà la forza e la voglia per portare le proprie applicazioni su tutti questi ambienti? Alla fine ne rimarrà solo uno: quale? E che fine faranno gli sforzi fatti sui perdenti? Qualcuno comincia a pensare che Windows Mobile o Symbian, ciascuno nel proprio mercato, possano essere una scelta più assennata e ragionevole, specie se si vuole tutelare un minimo il tempo e le risorse spese a imparare e sviluppare.
Si annuncia un 2008 turbolento…
Save your Series 60!
These days I’ve been thinking about objects obsolescence. All manufacturers improve their products (ranging from electronic devices to cars), giving us the perception that any old product (that is, what we’ve bought just some weeks ago) is obsolete. Upcoming products are faster, simpler, cheaper, beautiful as no other previously released. In a word: better. Even if we don’t need to change what we previously get (it still works as good as expected), new features are provided only by new models and keeping old ones implies to miss new possibilities. Implications can be surprisingly strong. Think about cars: some municipalities prohibit city access to cars not compliant with Euro 4 specification. Something similar happens with computers: new applications may require most recent operating systems, that require new hardware (that luckly doesn’t require you to update your house to get it!).
Obsolescence is pervasive in the mobile phone market. Not only manufacturers improve performances of hansets, fueling them with faster connections, larger displays and huge memory capacity; they also transform mobile phones in "fashion objects", as clothes or jewels. Developers know that just one or two new models per year are actually revolutionary: the others are just well-known-old-phones with a different case and name.
Obsolescence invokes update, which produces disposing: any time we update our devices with new models, we usually have to dispose obsolete items. For a limited time, we may try to keep both… but… after a while, we will prefer one (usually the newer!), so that the other will be disposed (usually the older!). Considered that there are about 2 billions of mobile phones and that average lifetime of each is 23 months, we will have a lot of "small yet connected intelligent devices" ready to be disposed.
Is there any way to reuse and/or recycle them? Recycle (disassembling devices and ruse part of them as components for new devices) is not so easy; plastics and electronics have been designed and tailored to work together, to separate and reassemble them requires a complex integration plan. Reuse (use those devices as they are even for different applications) is more practicable for "common people". In general, reuse beats recycle. Reuse is feasible for devices that provide enough power (CPU, memory, communication facilities) to be programmed and interfaced with the rest of the world.
Not any mobile device can be reused as an embedded system. Many devices can’t be programmed, many others have so frustraing limitations that any idea dies before starting to write one line of code! 🙁
Among others, Nokia Series 60 is one of the most used smartphone platforms. Handsets based on this platform, once announced, are considered as state-of-the-art devices for a certain period of time: high resolution displays, enhanced multimedia capabilities, extended communication interfaces, robust and mature programming environment with a rich set of languages and tools. Month after month, the finnish manufacturer invades the mobile phones market with new award-winning families of handsets. Series 60 was born with 7650, but maturity arrived with 6630 and N70. Most recent devices, based on the 3rd edition of the platform, are market leaders and new models will appear during the Mobile World Congress.
We are pleased to get new devices, but what happens to old Series 60? Unfortunately, they can’t compare with upcoming, styilish smartphones, which expose unbelieveble performances. However, they are still powerful enough to be used for anything but as phone! Can we consider Series 60 2nd edition handset just programmable devices with communication capabilities? I believe we can. There should be an initiative to encourage people (mostly developers) to reuse their Series 60 as "new" embedded devices instead of considering them as "obsolete" phones. Something like "Save your Series 60" (let’s say "SyS60"), would be an attempt to find a wait to avoid that 100 millions of Series 60 sold till the end of 2007 would be trashed in less than two years.
Thanks to my friend Davide, pioneer in mobile application development, I’ve been introduced to Python development on Series 60. I believe that Python for Series 60 is not suitable for industrial projects, for which Java Micro Edition or native C++ are still best solutions. In fact, JME portability and C++ performances are unbeatable. However, Python is excellent for fast prototyping, powerful as C++ and simpler than Java. Python can be the driver to “Save our Series 60” and reuse them as funny and useful devices.
I spent some hours playing with Python, it is funny as Davide said! 🙂 Take a look to this interesting PyS60 tutorial, by Jurgen Scheible.
VM e librerie Sun SPOT rilasciate su licenza open source
Su segnalazione di Massimiliano Dessì, ho il piacere di diffondere questa notizia: Sun ha finalmente rilasciato con licenza open source il codice sorgente della virtual machine e delle librerie dei Sun SPOT! Maggiori dettaglio qui:
Attendiamo ora che siano finalmente disponibili i developer kit per il mercato europeo…
JavaFX Mobile: si muove qualcosa
Nel maggio dello scorso anno, in occasione della JavaOne 2007, Sun annunciò JavaFX e JavaFX Mobile. Di JavaFX apparvero subito esempi di codice e moduli per Netbeans, mentre di JavaFX Mobile fu pubblicata solo qualche informazione frammentaria e piuttosto varia.
Dopo il tam tam su blog e newsletter, l’interesse per JavaFX Mobile è andato pian piano scemando. In effetti, non essendoci nulla con cui "giocare", era inevitabile che gli sviluppatori indirizzassero la loro attenzione altrove (Android?).
Dalla Mobile & Embedded Developer Days conference che si svolge in questi giorni arrivano finalmente nuove notizie su JavaFX Mobile! È confermato lo "stato di salute" del progetto, nato dalle ceneri di Savaje e basato su Linux e Java Standard Edition. Segnalo la presentazione Developing JavaFX Mobile Applications fatta da Noel Poore, che chiarisce alcuni aspetti dell’architettura di questa piattaforma, in particolare la coesistenza di CLDC/MIDP e Java SE (piuttosto, dov’è finita CDC?).
Si attende a breve un apposito modulo per Netbeans, con emulatore dedicato.
JSR-82 su IBM J9 per Windows Mobile (CDC e CLDC)
Segnalo a tutti coloro che lavorano con Java Micro Edition su Windows Mobile che è disponibile il porting della Bluetooth API JSR 82 per le virtual machine Mysaifu e IBM J9 (sia CLDC che CDC!):
http://code.google.com/p/bluecove/wiki/WindowsMobile
Purtroppo l’API non è supportata totalmente (ad esempio, manca il supporto L2CAP), ma è più che sufficiente per effettuare il discovery di dispositivi e servizi e gestire connessioni RFCOMM.
The uncomplicated desire to connect
È evidente che chi ha preparato questa presentazione non ha mai configurato le impostazioni di rete di un Series 40! 😀 😀 😀 "The uncomplicated desire to connect", infatti, trova qualche ostacolo su certi telefoni. Battute a parte, è fuor di dubbio che Nokia faccia i migliori telefoni in assoluto:
Buon weekend.
Filtro per ChoiceGroup POPUP
Il ChoiceGroup
è un componente della libreria LCDUI di MIDP che consente di visualizzare liste di elementi a scelta multipla o esclusiva all’interno di un Form
. Il ChoiceGroup
dispone della modalità POPUP
, che consente la selezione di un singolo elemento attraverso una piccola finestra di popup, riducendo lo spazio occupato sul Form
e migliorandone di conseguenza la leggibilità.
A differenza di altre librerie di componenti, LCDUI non consente di filtrare la lista digitando le prime lettere della parola cercata. Su Python per Series 60, ad esempio, il componente selection_list
dispone di questa funzionalità facilmente attivabile in fase di visualizzazione. Si consideri il seguente frammento di codice, che visualizza una lista di paesi della Sardegna:
import appuifw
cities = [u"Abbasanta",
u"Budduso'",
u"Cagliari",
u"San Gavino",
u"Sassari",
u"Serri",
u"Sestu"]
index = appuifw.selection_list(cities , 1)
Come visibile in questo snapshot di un Nokia 6630, alla pressione di una lettera sul keypad, la lista viene automaticamente filtrata e, dunque, ridotta:
In ambiente MIDP è possibile implementare questa funzionalità utilizzando un TextField
e registrando un ItemStateListener
che aggiorna il ChoiceGroup
in base al testo digitato dall’utente. Il codice sorgente è semplice (ma, ahime’, non estremamente sintetico come in Python):
public class SearchForm
extends Form
implements ItemStateListener {
private String CITIES[] = new String[] {
"Abbasanta",
"Budduso'",
"Cagliari",
"San Gavino",
"Sassari",
"Serri",
"Sestu"};
private ChoiceGroup citiesList;
private TextField searchField;
public SearchForm() {
super("Seleziona citta'");
init();
}
private void init() {
citiesList = new ChoiceGroup("Citta' ("
+ CITIES.length + "): ", Choice.POPUP);
citiesList.setLayout(Item.LAYOUT_SHRINK);
for (int i = 0; i < CITIES.length; i++) {
citiesList.append(CITIES[i], null);
}
append(citiesList);
searchField = new TextField("Cerca: ", "", 40,
TextField.ANY);
searchField.setLayout(Item.LAYOUT_NEWLINE_AFTER);
setItemStateListener(this);
append(searchField);
}
public void itemStateChanged(Item item) {
if (item == searchField) {
updateList();
}
}
private void updateList() {
citiesList.deleteAll();
for (int i = 0; i < CITIES.length; i++) {
if (CITIES[i].startsWith(searchField.getString())) {
citiesList.append(CITIES[i], null);
}
}
citiesList.setLabel("Citta' (" + citiesList.size() + "): ");
}
}
Eccolo in esecuzione su Nokia 6120c:
Digitando sul TextField
si attiva il filtraggio della lista:
Prima o poi doveva capitare
I telefoni sono veri e propri PC:
A volte non si avviano piu’!
MIDP 3 Public Review Draft
Il Java Community Process ha appena rilasciato la specifica Public Review Draft di MIDP 3, reperibile all’indirizzo http://jcp.org/en/jsr/stage?listBy=public. Più o meno come un anno fa (era il Natale 2006…), la review si concluderà dopo tre mesi, ovvero a marzo 2008.
Ci è voluto un anno per passare dall’Early Draft alla Public Review. Credo sia normale che di fronte a tanta lentezza del JCP vi siano iniziative come quella della Open Handset Alliance, pur scegliendo la piattaforma Java come base applicativa per Android, abbandoni del tutto JME e predisponga un set di API alternative. Qualcuno sostiene che MIDP3 non farà in tempo a vedere la luce e che l’intervallo di tempo tra la specifica finale (attesa per giugno 2008), la disponibilità dei primi dispositivi e la loro progressiva diffusione sarà così lungo che sarà ormai tempo di avere CDC/PP o qualcos’altro anche sui terminali entry level.
Io non sono così drastico e pessimista, ma sono convinto che l’inerzia che MIDP3 manifesta non giovi a nessuno, neppure a coloro che stanno spendendo tempo e risorse per redigerne la specifica. Rispetto a qualche anno fa, il mondo del mobile computing non è più una nicchia: è una arena, piena di gladiatori e belve feroci. Ci sono i produttori dei terminali, ormai rimasti praticamente in cinque (Nokia, Motorola, Samsung, LG, Sony-Ericsson), e le cordate che supportano gli ambienti operativi (Java ME, Symbian, Windows Mobile, Flash Lite, Linux in varie salve). Ciascuno nel proprio dominio (hw o sw), talvolta saltando e componendo scelte azzardate che miscelano hardware e software, è pronto a vendere la famiglia per sbaragliare la concorrenza. In questo senso essere lenti e poco reattivi rispetto al mercato può essere fatale.