Questi giorni sono stati pubblicati diversi post sull'imminente uscita di Windows Mobile 6.
Da ieri sono anche disponibili i relativi SDK, che mi hanno risolto un grande problema con gli emulatori sotto Vista (ora riesco a farli connettere al Device Center, il nuovo ActiveSync per Vista)!
Al di là delle novità tecniche, che al momento non ritengo molto importanti per il tipo di applicazioni che sviluppo, quello che mi ha più colpito è il nuovo cambio di nome delle varie piattaforme: la versione Pocket PC sarà rinominata in "Classic", la Smartphone in "Standard" e la Pocket PC Phone Edition in "Professional".
Quello che mi chiedo è se fosse proprio necessario fare questo nuovo cambiamento: nella versione precedente, si era fatto un passo in avanti, allineando le versioni tra Windows CE e Windows Mobile, portati entrambi alla release 5 (invece di 4.2 vs 2003).
Ora, con questo cambio di nome, di cui ancora non ho colto l'utilità, non vedo come possa diminuire la confusione da parte di tutti gli utenti (utente finale, commerciali, nonché developer), come se non bastasse già quella che c'era nello spiegare alla gente che sviluppare per una delle 3 piattaforme è ben diverso che farlo nelle altre, nonchè l'incompatibilità tra tutte le versioni e gli strumenti di sviluppo (vedi a riguardo, ad esempio, questo post e quest'altro).
Perchè, invece di fare tutti questi cambiamenti (che in questo caso fortunatamente sono stati solo nel nome), non pensano di più alla compatibilità e a facilitare la vita dello sviluppatore, invece di renderla più complicata?
Ad esempio, il CF 2.0 ha permesso di sviluppare applicazioni per Windows CE 4.2, ancora diffusissimo, solo dal SP 1, mentre sviluppando in ambiente nativo (c++) da Visual Studio 2005, si ha il supporto solo per CE >= 5 (e tra l'altro in Vista non è più supportato eVC++, che nel mio pc non gira più, per cui si deve ricorrere ad una macchina reale o virtuale con XP).
In PalmOS, un'applicazione sviluppata in c++ gira tranquillamente dalla versione del sistema 3.5, uscito ormai da molti anni, a quelle attuali (5.x), ed hanno affrontato anche il passaggio di architettura dalle CPU Motorola 68K alle ARM in modo del tutto trasparente per lo sviluppatore (funziona lo stesso file compilato, non è necessario neanche ricompilarlo!)...è chiedere troppo avere un po' più di rispetto per lo sviluppatore anche in ambiente Windows Mobile, che magari vuole utilizzare gli strumenti più nuovi come il c++ in Visual Studio 2005, ma non può farlo senza problemi perchè non sono supportate piattaforme ancora sul mercato?
Una situazione analoga c'è sulla gestione di dispositivi che non vedo perchè non sono resi standard.
In particolare, mi riferisco alla gestione dei lettori di barcode nei dispositivi che ne sono dotati: perchè non vengono realizzate delle API standard per pilotarli, ed invece ogni volta occorre legarsi all'SDK del particolare produttore (quindi occorre sia perdere tempo a vedere le particolari API proprietarie, sia creare nel codice delle referenze ad altre librerie, che al solito non agevolano l'utilizzo del programma su dispositivi di diversi produttori).
Alla fine tutti i lettori di barcode necessitano di quelle poche funzioni di base per essere pilotati (abilitazione / disabilitazione / evento di lettura e settaggio di qualche parametro, come il bip ed i formati che si vogliono supportare)...sarebbe tanto complicato avere da parte del sistema operativo un'API standard per gestirli?
posted @ sabato 10 febbraio 2007 17:41