Marco Bellinaso

Dal momento che Postino per iPhone sta piacendo molto...non ci siamo accontentati! Esce oggi una versione web-based totalmente integrata in Facebook. Non occorre registrarsi e creare un nuovo account. Se siete utenti di Facebook (e chi non lo è ormai?!) vi basta andare a questa pagina e potrete iniziare a creare le vostre cartoline, con le vostre foto e i vostri messaggi. Le cartoline verranno stampate e recapitate ai vostri amici o famigliari in tutto il mondo. Se avete già Postino per iPhone, e avete già acquistato dei francobolli, potrete associare l'iPhone al vostro account Facebook, così che i francobolli in vostro possesso possano essere usati da entrambe le parti. Viceversa, acquistando dei francobolli da FB questi potranno poi essere usati anche dall'iPhone.

Fatta questa presentazione, ci rimettiamo subito al lavoro con la creazione di ulteriori client per il Postino service!

Durante la notte di domenica scorsa Apple ha finalmente approvato e pubblicato su iTunes Postino, la nostra nuova applicazione per iPhone.

Questa volta si tratta di una applicazione a livello globale, a differenza di Locomotimes (la nostra precedente applicazione, che ha avuto circa 25.000 download in Italia). Come il nome suggerisce, si tratta di un'applicazione che ha a che fare con la posta, più precisamente le cartoline. Ma non si tratta della solita app per spedire e-card (anche se fa *anche* quello). Postino permette di spedire delle vere cartoline fisiche, stampate su carta di alta qualità, e che possono essere recapitate in tutto il mondo. Ovviamente è possibile scegliere una foto dalla photo gallery o scattarne una nuova, si scrive il messaggio e si sceglie l'indirizzo di destinazione (e-mail in caso di e-card o indirizzo fisico altrimenti). Ci sono varie "chicche" tra cui la selezione di una cornice (tra 20 built-in) per abbellire la propria foto, e il disegno "a mano" di una firma o disegnetto (si usa il dito sul touchscreen, similmente alle tante app di disegno). Nelle cartoline elettroniche è poi possibile includere automaticamente un link a Google Maps che mostrerà il luogo da dove è stata scattata la foto! E' disponibile una cronologia degli invii che mostra anche lo status di spedizione, e vari altri piccoli dettagli.

L'applicazione al momento è gratuita, ma lo sarà davvero per pochissimi giorni (a differenza di Locomotimes, che è rimasta gratuita, e per cui invece abbiamo rilasciato LocomotimesPRO a pagamento, con ritardi e binari di arrivo aggiornati in tempo reale ;)

Ovviamente i francobolli "virtuali" per spedire le cartoline fisiche hanno comunque un costo: si parte da 1.99$ (circa 1.4€) per il singolo francobollo (con spedizione ovunque nel mondo) ma si scende in base al numero di francobolli acquistati (si arriva al 20% di sconto).

Potete leggere ulteriori dettagli, oltre a vedere molti screenshot, sul nuovissimo sito http://www.angurialab.com

Una domanda che spesso ci fanno (e che fa parte di un'intervista che sarà pubblicata a breve) è la seguente: Postino va oltre al virtuale offrendo la possibilità di spedire cartoline fisiche. Da cosa vi è venuta l'idea?

Risposta: la vera rivoluzione sta nel rendere più semplice ed accessibili le attività di tutti i giorni. Mandare una cartolina è una di queste: spesso non troviamo quella che vorremmo, non sappiamo che francobolli acquistare (spesso all'estero...). Adesso si può mandare una cartolina personalizzata con la foto che vogliamo con semplicità e risparmiando anche! 

L'intervista completa è presente su MelaMorsicata.it

GetConnected è l'azienda bolognese con la quale sto lavorando da oltre un anno, in maniera sempre più stretta. Assieme a loro ho pubblicato Locomotimes (tra che l'altro già da qualche giorno ha superato i 20.000 download!) e stiamo lavorando assieme anche su nuovi prodotti. Il lavoro non manca e anzi sembra che le persone non siano mai abbastanza per tutti i progetti che escono, sia come commesse da clienti...che come prodotti commerciali. GetConnected sta quindi cercando nuovi programmatori da assumere...possibilmente giovani entusiasti, con una vera passione per l'informatica, che abbiano già una discreta esperienza ma che abbiano anche voglia di imparare ancora, lavorando su idee e tecnologie interessanti e moderne.

Come? Avete già sentito queste cose milioni di volte, per poi trovarvi di fronte al solito manager tecnicamente incompetente al momento del colloquio, che non valuta con il dovuto interesse (e rispetto) tutti i progetti, i software e i siti fighissimi che avete creato, magari da soli, con amici, nel tempo libero, per passione oltre che per professione?

Per dimostrare con i fatti che sono diversi, i ragazzi di GetConnected hanno dato il via ad una specie di concorso: inviate le vostre realizzazioni migliori in ambito web (basta anche solo il link al sito online, se non potete/volete spedire il sorgente) e avrete la possibilità di vincere il premio in denaro di 300€. Non male, per una cosa che avete già realizzato e che qualcuno vi chiede di mostrargli, no?

I progetti dovrebbero essere siti/servizi web e se volete vincere è meglio che siano in qualche modo innovativi, come idea e/o come tecnologie usate. Qualche paginetta fatta in Classic ASP per gestire un guestbook o delle news? mmm...no grazie! Un servizio sviluppato con ASP.NET / PHP / RoR con AJAX a gogò, mappe, mash-up e utilizzo di toolkit e framework vari? Fatevi sentire subito!

Il premio in denaro sarà solo per uno, ma tutti i partecipanti saranno presi in considerazione per una assunzione e/o collaborazione. Solo se lo si desidera ovviamente. Si può anche partecipare, vincere il premio e scappare...ma poi non dite che gli informatici in gamba non riescono a trovare (o cambiare facilmente) lavoro eh?!

Leggere libri di programmazione senza poi programmare e provare con mano quanto studiato vuol dire non aver imparato nulla. Mettersi li a realizzare i soliti esempi semplici e banali è ben poco divertente e anche poco utile. Ecco perchè per fare pratica ho voluto realizzare (assieme ai ragazzi di GetConnected) una applicazione reale, che non fosse troppo complessa ma che non fosse neanche un giocattolo.

Il risultato è Locomotimes, un'applicazione che permette di consultare in modo semplice e veloce gli orari dei treni per qualsiasi tratta nazionale e verso molte città europee. Le funzionalità sono parecchie; non mi soffermo qui sui dettagli perchè trovate tutto sulla pagina di iTunes o di GetConnected (qui c'è anche un video che mostra tutte le funzionalità), ma in breve:

- elenco indicizzato e filtrabile di tutte le stazioni supportate
- possibilità di includere solo le soluzioni di viaggio con determinati tipi di treno
- un sacco di informazioni nei risultati (partenza e arrivo non solo per il viaggio totale ma anche per tutti i cambi, alert se i cambi sono troppo ravvicinati, tipi di treno, durata del viaggio, tariffe di prima e seconda classe, link per l'aquisto online...)
- cronologia delle ricerche passate (così che fatta una volta sia possibile consultare i risultati in futuro senza dover fare un'altra connessione)

Per chi come me prende spesso il treno credo che l'applicazione possa essere molto utile. Si, lo so che il sito di Trenitalia può essere consultato tramite Safari...ma occorre 10 volte lo stesso tempo, pazienza e traffico dati. L'applicazione sarà gratuita per un po', quindi...se avete un iPhone andate a scaricarla subito! ;)

NOTA: in realtà lo sviluppo di questa applicazione è terminato da almeno un mese...nel prossimo post racconterò perchè ci abbiamo messo così tanto per essere pubblicati online e darò qualche consiglio per evitare un'attesa logorante :)

Su questo blog ho già parlato varie volte dell'iPhone. Ho avuto prima la versione 2G e poi la 3G...e nonostante attualmente usi regolarmente un BlackBerry Bold continuo a pensare che l'iPhone sia un dispositivo assolutamente innovativo e con alcune qualità (e soprattutto con delle potenzialità) ancora molto superiori alla concorrenza. Alcuni aspetti in particolare poi dovrebbero interessare molto gli sviluppatori. Per questi motivi (e per soddisfare un po' la mia curiosità e passione per la tecnologia) ho ordinato il libro Beginning iPhone Development (APress) appena fu annunciato e prima che fosse effettivamente disponibile (causa il fatto che fino a pochi mesi fa l'SDK era ancora sotto NDA e non se ne poteva scrivere pubblicamente...). Solo recentemente però ho iniziato un progetto e mi sono messo a studiarlo realmente.

Sviluppare per iPhone significa dover usare Mac OSX, imparare l'IDE di sviluppo XCode (fornito gratis con il sistema operativo o scaricabile gratuitamente assieme all'iPhone SDK), imparare il linguaggio Objective-C e il framework Cocoa Touch (che è parte di Cocoa + estensioni specifiche per iPhone, allo stesso modo di quello che fa il .NET Compact Framework e l'SDK di Windows Mobile rispetto al .NET Framework full). Oltre a questo bisogna abituarsi a programmare secondo il modello Model-View-Controller (che molti conosceranno anche in ambiente .NET o Java...ma sicuramente non tutti) e a tutta una serie di piccole e grandi differenze rispetto al modo di lavorare con altri ambienti e linguaggi. Di sicuro ci vuole un po' di tempo per prenderci la mano ed essere produttivi, e non è che essendo esperti con qualche altra tecnologia il lavoro con l'iPhone sia subito un gioco da ragazzi.

Proprio per questo motivo è utile avere una guida come quella in questione, che che insegni come muoversi partendo dai concetti base e mostrando passo per passo come: disegnare una vista, associarci un controller, collegare gli elementi della UI alle proprietà del controller, gestire gli eventi (tramite delegate)...e poi via via fare cose più complesse come riempire una lista associata ad una sorgente dati, personalizzare l'aspetto delle tabelle, costruire dei percorsi di navigazione tra viste distinte, gestire l'accesso al file system, realizzare qualche piccola animazione ed effetto grafico, gestire touch e gesture, localizzare un'applicazione, gestire la fotocamera e fare 2 cose sul multimedia.

Il libro è strutturato proprio come un corso, e quindi va letto in ordine. Alla fine si avrà una buona idea di come si lavora su questa piattaforma e il tanto codice di esempio fornito potrà anche servire come base di partenza (e miniera per copia-incollare piccole parti) per i primi progettini. Alla fine non si potrà dire di essere esperti, ma non si sarà più neppure degli sprovveduti. Il libro ad esempio spende ben 120 pagine per parlare di liste e navigazione tra viste, dato che sono concetti fondamentali e importanti per praticamente tutti gli applicativi (ad eccezione probabilmente di videogame e applicazione esclusivamente "grafiche", che sono programmate in modo diverso), ma non parla di accesso a web service o risorse via HTTP, programmazione multi-threading (importante ad esempio per recuperare o elaborare dei dati mentre l'utente usa qualche altra funzione dell'applicazione), utilizzo avanzato di alcuni controlli, interazione con altre applicazioni (il browser o il programma Mail ad esempio), accesso ai contatti del telefono, debugging, deployment dell'applicazione su un iPhone reale di test, o del processo (pieno di insidie) di firma e pubblicazione dell'applicazione in AppStore. Altri argomenti come l'accesso ai database Sqlite, la gestione delle gesture, dell'accelerometro e del GPS sono appena accennati in poche pagine, in modo insufficiente per un utilizzo immediato proficuo.

Le mancanze elencate sopra non si possono però considerare dei veri difetti del libro; sono mancanze "by-design", volute, dato che il titolo inzia con "Beginning..." e non con "Professional...". Quello che però ci sarebbe stato proprio bene in un libro del genere è un capitolo sul linguaggio (sintassi, costrutti, programmazione ad oggetti, categorie, reflection, gestione delle memoria) e le classi base tipo NSString, NSDate, NSArray, NSDictionary ecc. Non vorrei ovviamente una trattazione dettagliata di questi argomenti, (ci vorrebbe ovviamente un libro dedicato solo a quello) ma solo "un riassunto", un "quick-start" per chi viene magari da altri linguaggi e si trova un po' spiazzato dalla sintassi e da alcuni concetti di Objective-C. Ad ogni modo, se si è già letta la documentazione ufficiale di Apple sul linguaggio, anche questo non costituirà un problema.

L'importante è che una volta imparati i concetti di base sarà molto più semplice cercare (e capire) specifiche informazioni online, nella documentazione ufficiale...o in un secondo libro più avanzato. Non si tratta quini della classica bibbia omnicomprensiva, ma è uno strumento efficace e quasi indispensabile per partire con il piede giusto. In conclusione, è una perfetta prima guida, altamente consigliata.

In questo periodo – lavoro "normale" permettendo – sto sviluppando una applicazione iPhone che recupera dei dati da un web service .NET. Lavoro su un MacBook Pro con OSX come sistema operativo principale e Windows XP su VMWare Fusion. Chiaramente su OSX uso XCode per lo sviluppo del codice iPhone, e sulla VM con XP uso Visual Studio 2008 per lo sviluppo del web service.

Tutto bene con lo sviluppo, fino al momento di dover interrogare il web service che gira nella VM dal simulatore iPhone. Il problema è che in XP non ho neanche installato IIS, perchè la versione 5 ha troppi limiti ed è fin troppo diversa da IIS6. Quindi ho pensato che tanto valeva sviluppare usando il Web Development Server integrato in VS2008 e poi fare i test finali sul server Win2003 con IIS6. Il Web Development Server però non accetta richieste remote, ovvero processa solo richieste provenienti dalla macchina di sviluppo dove gira. Come fare quindi per testare l'integrazione iPhone/WS, senza dover necessariamente installare IIS o senza pubblicare ogni volta il WS sul server Win2003?

La soluzione è stata davvero semplicissima: basta scaricare Port Forwarding for Windows (programmino freeware, fornito anche di sorgenti, e che non richiede neanche installazione) e configurarlo per redirezionare le richieste che arrivano sulla porta 80 verso la porta gestita da Web Development Server. Un minuto ed il gioco è fatto.

Note
1) Io ho scelto la porta 80 per semplicità, ma potete scegliere la porta che volete...basta che vi ricordiate di aprirla nelle regole del firewall.
2) Di default la porta usata dal Web Development Server è dinamica, e questo è un problema perchè dovreste cambiare ogni volta la regola di forward. Per ovviare basta impostarla staticamente dalle proprietà del progetto ASP.NET.

Anche senza consultare molte ricerche di mercato (che pure esistono in gran quantità) è sotto gli occhi di tutti come il mercato di smartphone e PDA si stia evolvendo tantissimo e velocemente. Ormai non è difficile passeggiare per strada incrociando non solo manager e "gente del settore" (leggi geek) ma anche ragazzini che parlano non con un normale telefono, ma con un dispositivo fornito di ampio schermo touchscreen e con migliaia di colori brillanti, connettività bluetooth, wi-fi e UMTS/HSDPA (più veloce di quello che fino a pochi anni fa si aveva nel PC di casa!), GPS, fotocamera da 2-5 MPx, vari GB di spazio disponibile, CPU potenti, tastiera estesa per una comoda digitazione, sensori di movimento...e magari qualcos'altro ancora. E' altresì chiaro che con una configurazione hardware di questo livello le possibilità per gli sviluppatori non mancano, ed infatti ecco fiorire giochi a volte paragonabili a quelli delle console portatili, e programmi / utility di tutti i tipi. Ci sono ormai moltissime aziende che hanno fatto del mobile il loro unico business, sviluppando applicazioni per tutte le maggiori piattaforme esistenti, e raggiungendo a volte anche un gran successo.

Con il fatto che (1) il mercato del software per mobile è in grande espansione, (2) molte idee possono essere sviluppate senza grandi investimenti di tempo e denaro ma con prospettive di guadagni potenzialmente interessanti, (3) è comunque la possibilità di imparare qualche nuova tecnologia e/o linguaggio divertendosi molto di più che facendo l'ennesima applicazione gestionale desktop-based, è normale che molti siano guardando a questo settore con l'intenzione di buttarsi dentro, o perlomeno di iniziare a "bagnarsi il piede" (espressione americana...chissà se in italiano fa lo stesso effetto :)

Vorrei allora proporre una analisi molto semplice e veloce delle principali piattaforme e delle tecnologie di sviluppo ad esse collegate, con l'intenzione di chiarire almeno parzialmente le idee a chi non si sa decidere.

Apple iPhone

E' chiaramente il device del momento, quello più di moda e che molti vorrebbero. Recentemente il suo AppStore, il negozio di applicazioni consultabile tramite iTunes (e solo tramite quello...) ha raggiunto le 10.000 applicazioni (la maggior parte delle quali è gratis o costa 0,79€ o poco più).

Cosa serve per sviluppare:
* Un qualsiasi Mac Intel-based
* L'ambiente di sviluppo gratuito XCode (presente direttamente nel DVD di OSX)
* L'iPhone / iPod Touch SDK, scaricabile gratuitamente
* Le chiavi per firmare digitalmente per proprie applicazioni: 99$/anno

Conoscenze richieste:
Objective-C & Cocoa Touch. Objective-C è un C con così tante cose in più, e con così tante differenze, che alla fine resta "C" solo nella sintassi degli statement di base (if, for, while, switch ecc.). Definizione di interfacce, classi, UI ecc. si fa tutto con una sintassi e degli strumenti di sviluppo che sicuramente risulteranno nuovi e anche piuttosto strani a tutti coloro non ancora abituati alla programmazione per Mac. Viceversa, chi già è in grado di programmare applicazioni desktop per OSX si sentirà piuttosto a suo agio: stesso strumento per creare le interfacce utente (Interface Builder), stesso linguaggio (anche se mancante di alcune novità dell'ultima versione, come la gestione automatica della memoria), e framework simile (Cocoa Touch, un sottoinsieme di Cocoa).

Ovviamente per chi viene da altri mondi (C#/VB.NET su Windows, o magari Java) l'impresa non è certo impossibile, ma solo un po' più ardua rispetto ad altre piattaforme. Recentemente sono usciti dei libri, tra i quali consiglio Beginning iPhone Development che possono davvero fare la differenza. Se partite da zero in questo ambiente, investite sicuramente nel libro se non volete perdere giorni cercando di capire come funziona questo mondo. Una volta iniziato poi sarà invece sicuramente più facile approfondire i dettagli dalla documentazione online.

Pro:
* Lo stesso programma può funzionare su iPhone e iPod Touch (a patto ovviamente che non usi la fotocamera o le funzioni telefoniche, non presenti nell'iPod), garantendo un grandissimo mercato.

* AppStore è l'unico store ufficiale dove pubblicare le proprie applicazioni, ed è perfettamente integrato sia con l'iPhone sia con iTunes => buona visibilità e ottime probabilità di essere trovati se l'utente cerca le keyword giuste

* Buon framework per creare con semplicità animazioni ed effetti grafici particolari.

* Presenza del DB engine Sqlite, e di una versione ridotta di OpenGL, oltre a tutta una serie di componenti e classi per creare belle interfacce utente, gestire l'interazione con l'utente, manipolare dati ecc. (le solite cose che ci si aspetta insomma, ma con parecchie cose in più sul lato della UI)

* Uniformità dei dispositivi: si sviluppa una volta sola, sapendo che tutti i propri utenti avranno dei device praticamente identici (stessa risoluzione, stessa potenza, stessa risoluzione della fotocamera ecc.). In realtà si può differenziare tra iPhone 2G e 3G (nel 2G manca il GPS) o tra iPhone e iPod Touch, ma comunque questo è nulla rispetto a quello a cui sono abituati gli sviluppatori in altre piattaforme!

Contro:
* Gli strumenti di sviluppo sono gratis, ma bisogna per forza avere un Mac per sviluppare.

* 99$/anno per avere la possibilità di stare nello store di Apple - non pochissimo per chi inizia, e soprattutto non poco per chi intende sviluppare applicazioni free!

* E' necessario pagare la licenza (leggi: le chiavi) anche per applicazioni custom per uno specifico cliente. Anzi in quel caso bisogna spendere 299$ per la licenza Enterprise.

* La documentazione e il supporto (sotto forma di forum, chat ecc.) sono ancora limitati rispetto ad altre piattaforme di sviluppo.

* Apple trattiene il 30% dalle vendite come commissione. E' una percentuale che "ci sta" in generale, ma la cosa negativa è che non c'è alternativa, ovvero oltre a pubblicare la mia applicazione sullo store non posso *anche* pubblicarla per conto mio e farmi pagare su PayPal, così da risparmiare sulle commissioni. (sto ovviamente trascurando la possibilità di scrivere applicazioni per device craccati - in quel caso c'è un mercato del tutto diverso, e una serie di riflessioni che non affronterò in questo post)

* Il costo medio delle applicazioni è attorno ad 1$...di conseguenza bisogna vendere veramente molto per guadagnarci qualcosa.

* Sebbene il sistema operativo di iPhone contenta di fare un sacco di cose, di fatto poi le API pubbliche consentono di fare molto ma molto meno: scordatevi di fare applicazioni che girano in background, applicazioni che intercettano eventi di sistema (chiamata / sms in arrivo), inviano SMS o mail, interagiscono con applicazioni di sistema quali il calendario, e che in generale accedono al device a basso livello. Le API per tutto ciò ovviamente esistono e Apple le usa per i propri applicativi, ma sono classificate come "private", non sono documentate, e se le usate Apple non vi consentirà di pubblicare il vostro programma nel suo store, relegandovi di fatto al mondo dei dispositivi craccati.

* Oltre ai limiti appena citati, c'è anche il fatto molto antipatico che Apple potrebbe rifiutare per una serie di motivi la vostra applicazione: non seguite qualche standard sull'interfaccia utente, avete fatto un'applicazione che fa qualcosa di simile ad un'applicazione di sistema (anche se magari lo fa molto meglio) esistente (o futura...), la vostra applicazione non rispetta certi standard prestazionali ecc. ecc. E' veramente troppo facile vedere la propria applicazione respinta...magari anche per più volte, e per motivi che spesso fanno imbestialire gli sviluppatori (che dopo aver speso settimane di lavoro vorrebbero vedere la propria creazione online il più presto possibile). Insomma la situazione è questa: iPhone è un sistema piuttosto chiuso, molto limitato riguardo a quello che vi permette di fare, e i programmatori sono in balia dei gusti di Apple.

In conclusione, le possibilità sono molto interessanti, ma potrebbero esserlo anche infinitamente di più se solo Apple cambiasse un po' politica e si aprisse di più. Attualmente ritengo che a meno che non abbiate veramente l'idea semplice ma geniale che vi faccia vendere centinaia di migliaia di copie, il motivo per buttarsi su iPhone sia piuttosto quello di farsi della buona esperienza su questa piattaforma e poi vendersi come consulenti: di lavoro sembra essercene parecchio, mi dicono amici da quel fronte ;)

Symbian devices (Nokia e altri)

I device con Symbian sono senz'altro meno "emozionanti" di iPhone (che per molti versi è stato una piccola rivoluzione), ma sono solidi, ben collaudati e diffusissimi. Sembrerebbero quindi un buon mercato dove indirizzarsi ma...a quanto pare se n'è già accorto da tempo un sacco di gente e attualmente ci sono quantità industriali di software per qualsiasi categoria. Trovare un'idea non ancora realizzata sembra una vera impresa. Se comunque questo non vi spaventa, continuate a leggere.

Cosa serve per sviluppare:
* Va bene praticamente qualsiasi PC con Windows, Linux o un Mac con OSX.
* Un IDE/compilatore Java (tipicamente Eclipse se volete restare nel free) o C++ (il vecchio Visual C++, il nuovo Visual Studio con C++, o il quotato CodeWarrior C++) (www.metrowerks.com)

Conoscenze richieste:
C++ per "applicazioni native", oppure J2ME (mobile edition) per applicazioni che girano dentro il runtime Java-based. Le applicazioni Java sono tipicamente più lente (niente giochi 3D spettacolari) e limitate (niente accesso a basso livello, niente funzioni avanzate quali intercettazioni di eventi di sistema ecc.), ma comunque è la scelta più produttiva e semplice per un gran numero di applicazioni che non richiedono cose molto particolari. C++ per contro permette di fare di tutto (ma proprio di tutto) sul Symbian, personalizzando qualsiasi aspetto...ma svilupparci sembra essere parecchio impegnativo, anche per chi già conosce il C++.

Sviluppare in Java ha anche il vantaggio che l'applicazione potrà poi essere portata anche su altre piattaforme con sforzi spesso molto ridotti, a volte addirittura assenti. Per un confronto tra le due opzioni fate riferimento a questo whitepaper. Per chi viene dal mondo .NET, imparare J2ME è una questione di pochi giorni. Chi invece già conosce Java deve sono vedersi le poche classi per creare l'interfaccia utente. In generale è un compito tranquillamente alla portata di chiunque abbia già delle buone basi di programmazione object oriented moderna.

Pro:
* Enorme diffusione della piattaforma.

* Facilità di sviluppo con Java.

* Portabilità della applicazioni sviluppate con Java.

* Costi di sviluppo molto ridotti o assenti.

* Libertà di scelta di vari canali di distribuzione (sul proprio sito, su store di terze parti ecc.).

* Il supporto per il mondo Java (sotto forma di forum, libri, corsi) di sicuro non manca.

Contro:
* Mercato già affollatissimo.

* Non c'è uno store centralizzato, bisogna registrarsi su vari store, ognuno con le proprie regole, le proprie commissioni, le proprie dati per l'invio dei compensi ecc.

* Esistono centinaia di diverse configurazioni hardware di cui tenere conto, e questo può facilmente diventare un inferno per lo sviluppatore che deve testare il software in infiniti simulatori, differenziare parti di codice, scrivere istruzioni dettagliate per modelli diversi, compilare una lista di compatibilità ecc.

In generale Symbian è una scelta con la quale difficilmente l'investimento di tempo andrà sprecato, non fosse altro che comunque Java è praticamente onnipresente. E' però un po' difficile creare applicazioni innovative data la ricchezza di software esistente.

BlackBerry

I BlackBerry prodotti da RIM (Research In Motion) sono dispositivi relativamente nuovi nel mercato italiano, ma già da molti anni popolarissimi negli USA, dove tra alti e bassi RIM è tra le prime 3 aziende del settore. Storicamente associati esclusivamente al mercato business (manager e impiegati che hanno bisogno di essere sempre collegati alla mail aziendale), gli ultimi modelli (Bold e Storm) sono di sicuro interesse anche per la massa degli utenti consumer, attenti alle funzioni multimediali, all'estetica, alla ricchezza di applicazioni.

Cosa serve per sviluppare:
* Va bene praticamente qualsiasi PC con Windows, Linux o un Mac con OSX.
* Eclipse + un plug-in di RIM; oppure il JDE, un ambiente derivato da Eclipse fatto su misura per lo sviluppo con BlackBerry. Se si inizia da zero con Java consiglio la seconda opzione, dato che richiede una più semplice installazione e configurazione.
* Un set di chiavi per firmare digitalmente le proprie applicazioni. Si comprano tramite il sito di RIM, e costano solo 20$, una-tantum.

Conoscenze richieste:
J2ME, come per Symbian. Ovviamente oltre alle classi generiche di J2ME RIM ha aggiunto tutta una serie di classi specilizzate per accedere alle funzionalità e caratteristiche peculiari del proprio sistema operativo e dei propri dispositivi, ma tipicamente si tratta solo di classe che ereditano da una classe J2ME base e la estendono con nuove proprietà (ad esempio BlackBerryContact the deriva da Contact). Come detto sopra per Symbian, provedendo dal mondo .NET la strada sarà perlomeno in pianura: pochi giorni dovrebbero bastare per leggersi le parti fondamentali della documentazione (disponibile a partire da qui), a guardarsi la vasta schiera di esempi installati assieme al JDE, e per cominciare a fare le prime prove concrete.

Pro:
* Semplicità di sviluppo.

* Non ci sono libri dedicati ma la documentazione ufficiale è piuttosto completa, gli esempi ufficiali coprano praticamente tutto, e il forum di supporto per sviluppatori è molto frequentato e vivo (una risposta arriva di solito in qualche ora).

* Il mercato potenziale è enorme, ma rispetto ad altre piattaforme esistono ancora pochi software => c'è più spazio per le proprie idee.

* Il prezzo medio delle applicazioni commerciali è piuttosto elevato (sui 15$), quindi con un'idea discreta ci si ripaga il tempo speso e ci si guadagna qualcosa in breve tempo.

* Esistono decine di device con caratteristiche diverse...ma almeno sono tutti di RIM, quindi è più facile tenerli sotto controllo e gestire una lista di compatibilità.

* RIM fornisce i simulatori di tutti i device, in modo da semplificare di molto il test delle proprie applicazioni.

* Tra le classi di J2ME e le estensioni di RIM è possibile interagire con il sistema operativo e le applicazioni di sistema in modo piuttosto completo: si possono intercettare molti eventi di sistema, scrivere delle applicazioni che girano in background e partono all'avvio, mandare SMS e mail, accedere al GPS, utilizzare connessioni verso indirizzi remoti, accedere ai dati del calendario e della rubrica, disegnare interfacce personalizzate, gestire suoni e video ecc.

* RIM ha annunciato che nel 2009 pubblicherà un suo store ufficiale, il che dovrebbe aiutare ancora di più le vendite di applicazioni di terze parti.

Contro:
* SDK parzialmente limitato per alcuni aspetti: non è ad esempio possibile cancellare SMS, intercettare degli eventi particolari, cambiare alcune impostazioni di sistema (profilo attivo, audio, immagine di sfondo della schermata principale) o cambiare il comportamento di alcune applicazioni di sistema.

* I file prodotti dalla compilazione (.JAR e .COD) non possono superare una certa dimensione massima. Ad esempio un file di 8MB (dimensione raggiunta includendo al suo interno molti file di testo, immagini ecc.) non verrà installato nel telefono.

* Non è presente un DB Engine installato di default. SQL Anywhere 11 di Sybase include UltraLite J per BlackBerry, un motore di database relazione che può andar bene in molte situazioni, ma è comunque un software da installare separatamente, e ha le sue limitazioni (soprattutto sul numero di oggetti gestibili)

In generale, vista l'ottima diffusione attuale del BlackBerry negli USA e la potenziale ottima diffusione futura globale, questa è una piattaforma sulla quale può aver molto senso investire. Tra l'altro, se si cambiasse idea e si volesse passare al mondo Symbian, buona parte delle conoscenze acquisite continuerebbero ad essere utilizzate.

Windows Mobile devices (HTC, Samsung, HP, Palm e altri)

Molti dei discorsi fatti per Symbian valgono anche per WM. Ci sono in commercio tantissimi dispositivi diversi, di produttori diversi, per qualsiasi tasca ed esigenza. WM è un sistema operativo piuttosto stabile e dalle mille possibilità, anche se purtroppo seriamente (e forse irrimediabilmente) compromesso da un'interfaccia grafica antiquata, scomoda...e brutta.

Cosa serve per sviluppare:
* Un PC con Visual Studio 2005/2008 Standard o Professional. Le versioni Express (gratuite) purtroppo non includono il supporto per lo sviluppo mobile.

Conoscenze richieste:
C#/VB.NET (anche C++ in realtà, ma ormai con C#/VB.NET si fa praticamente tutto...ad eccezione forse di videogame complessi) e il .NET Compact Framework. Se sviluppate già per Windows con Visual Studio, in pratica sapete già tutto e oltre quello che serve (si fa per dire, in realtà bisogna ovviamente studiarsi gli approcci, pattern e guideline specifiche delle applicazioni per mobile). Anche venendo dal mondo Java l'esperienza non dovrebbe essere traumatica. A semplificare di molto le cose c'è il fatto che Visual Studio è il più avanzato IDE al mondo, con potenti strumenti di design visuale delle interfacce grafiche, un editor di codice e un debugger eccellenti, e tutta una serie di strumenti di contorno che semplificano di molto la vita. Purtroppo a pagamento però.

Pro:
* Semplicità di sviluppo.

* Visual Studio è il miglior IDE che si possa desiderare, e la facilità di sviluppo ne beneficia ulteriormente.

* Ricca disponibilità di libri, tutorial, screencast, esempi e documentazione di vario tipo. Come per lo sviluppo in altri ambiti, Microsoft si distingue positivamente in questa categoria.

* Disponibilità di SQL Server Mobile Edition per la gestione di complessi database relazionali direttamente sul device (con la possibilità di sincronizzarsi con SQL Server)

* Libertà di scelta di vari canali di distribuzione (sul proprio sito, su store di terze parti ecc.)

* Ampia libertà di sviluppo: l'SDK permette di fare praticamente di tutto. Dove non sia possibile fare qualcosa con il .NET Compact Framework, è di solito possibile farlo con C++ a più basso livello.

* Nessuna approvazione e/o firma da organizzazione esterne è necessaria per il deployment dei propri applicativi custom.

* Grande disponibilità di componenti commerciali (es: griglie avanzate o controlli per realizzare grafici) già pronti all'uso.

Contro:
* Mercato già piuttosto saturo, è difficile creare applicazioni particolarmente originali.

* Non esiste uno store centralizzato per la vendita => Meno visibilità, meno facile essere trovati.

* Creare un'interfaccia utente accettabile per i propri programmi significa sostanzialmente crearsela da zero. Del resto così facendo si perde l'uniformità con il resto delle applicazioni - per quanto brutta la UI, di solito una qualche uniformità è utile.

In conclusione WM può essere una buona piattaforma per sviluppare in libertà applicazioni di vario tipo, anche se creare qualcosa di "fuori dal coro" richiede uno sforzo ulteriore rispetto a quello che si potrebbe pensare.

Conclusioni generali

iPhone ha un hardware molto interessante, è di moda e con un buon mercato; ma è molto limitato per le applicazioni di terze parti, e la politica di Apple è difficilmente apprezzabile dagli sviluppatori.

Symbian è diffusissimo, molto flessibile e potente. Il test e il deployment può però diventare molto problematico dato l'elevato numero di dispositivi in commercio da vari produttori. Il mercato è già molto affollato.

Il BlackBerry è in espansione, svilupparci sopra costa praticamente zero ed è semplice. C'è meno competizione rispetto alle altre piattaforme. L'SDK e l'OS stesso però a volte risulta limitato, e non ci sono molte sorgenti di informazioni e supporto oltre a quelle ufficiali (comunque molto buone)

Windows Mobile e Symbian hanno più o meno gli stessi pro e contro - l'uno o l'altro è quasi una scelta di vita!

Nella propria scelta c'è un fattore al quale io personalmente ho dato una grandissima importanza: cosa conosco già? Io ho deciso che se dovevo sviluppare delle utility nel mio tempo libero (almeno per ora), doveva essere abbastanza stimolante e divertente. Lavorare con gli stessi linguaggi, framework e IDE con i quali lavoro tutto il giorno non mi avrebbe dato questi stimoli. Ho deciso che imparare un minimo di Java e di Objective-C mi avrebbe fatto solo bene. Viceversa qualcuno potrebbe voler fare lo sforzo minimo e usare quello che già conosce: anche questa è ovviamente una scelta rispettabilissima...alla fine l'importante è iniziare con qualcosa...se poi piace e si vuole guardare verso altri orizzonti...

Ultimamente, lavorando spesso a casa su progetti sia personali che per clienti, mi è cominciata a venire "l'ansia da backup". In realtà è una sensazione già provata parecchie volte, dopo che l'altr'anno mi era saltato un disco pieno di roba. Fortunatamente già da vari anni uso una qualche forma di software di backup che regolarmente copia tutti i dati importanti su un disco esterno quasi esclusivamente dedicato a quello scopo; quindi praticamente nessuna perdita seria in quell'occasione.

La preoccupazione è in realtà generata dal pensiero che se parto per le vacanze e qualcuno mi entra in casa rubando PC e disco esterno, ho perso anche il backup. Idem se scoppia un piccolo incendio o se un vaso di fiori pieno d'acqua mi si rovescia sulla scrivania inondando tutto. Certo, basterebbe anche fare il backup su un NAS opportunamente nascosto e collocato separatamente rispetto al PC. E se però il backup mi servisse mentre sono in viaggio di lavoro, magari per una o due settimane? Non mi posso certo portare dietro il disco esterno, avrei sempre il problema furto/smarrimento, oltre all'ovvio problema di ingombro / peso / scomodità. Beh ma mi potrei portare dietro una copia su DVD, no? No perchè non ho voglia di sprecare n DVD, e soprattutto non ho voglia di star li a far scrivere i DVD ogni volta. Configurare il NAS in modo che sia visibile dall'esterno? Mmm, già è una configurazione di troppo per i miei gusti (devo avere un IP statico, e se non ho un IP statico devo usare qualcosa come DynDns.org), e comunque richiede di tenere in casa una connessione costantemente attiva.

E allora? Allora ho cominciato a pensare all'opportunità di fare dei backup online, tramite dei servizi dedicati. Dopo un po' di ricerche tramite il fido Google e dopo aver letto decine di recensioni entusiastiche, anche per me la scelta è caduta su Mozy. Il piano base da 4.95$ al mese (3.75€ al cambio attuale) consente di archiviare dati illimitati! Niente male, considerando che non è affatto difficile spendere più di 45€ all'anno comprando software di archiviazione, DVD vergini e HD esterni...

Ma le cose sono anche migliori, perchè se dovete archiviare meno di 2GB di dati, Mozy è totalmente free. Certo non salverete la vostra collezione di musica e film, ma probabilmente in 2GB i documenti e i progetti di lavoro (parecchio codice, nel mio caso) ci potrebbero tranquillamente stare. Questa è pertanto l'opzione che sto usando al momento - nel caso dovessi aver bisogno di ulteriore spazio, l'upgrade è comunque immediato da effettuare.

A parte la versione Home da 4.95$ per spazio illimitato, ci sono anche le versioni Pro ed Enterprise che permettono di fare il backup di file server, SQL ed Exchange, oltre a poter girare sulle versioni server di Windows e OSX. Si veda questa pagina per un confronto. Per "l'utente normale" (e qui includo anche il professionista che lavora senza un'infrastruttura fantascientifica) la versione Home è comunque sufficiente nel 99% dei casi.

Una volta iscritti e scaricato il software Mozy Client, lo si configura scegliendo le cartelle da backuppare, e impostando la schedulazione preferita (quando il computer non sta facendo nulla, ad una certa ora del giorno, in una certa data, ecc.). In pratica si trova gran parte di quello che c'è in un software di backup "classico". Il backup effettuato è incrementale, funziona anche con i file correntemente aperti, e supporta il versioning, il che risulta perfetto per chi modifica spesso i propri documenti (es: i sorgenti di un programma in fase di sviluppo) e vuole tornare alla versione di una data specifica. Certo non sostituisce software di versioning come SVN o TFS, ma è già qualcosa di molto utile.
Oltre che tramite l'applicazione dedicata di configurazione, è possibile aggiungere un folder al backup tramite una nuova voce aggiunta al menu contestuale di Windows Explorer (Gestione Risorse) in fase di installazione. Davvero comodissimo.

Per quanto riguarda la sicurezza, tutte le comunicazioni client-server sono cifrate tramite SSL. I dati sul server di Mozy sono poi cifrati tramite una chiave a 448bit! La chiave può essere quella di default di Mozy, oppure una scelta dall'utente. La prima opzione è consigliata per utenti senza troppi segreti da proteggere, e che non vogliono o non sanno crearsi una propria chiave; la seconda opzione dovrebbe comunque permettere anche ai più ansiosi di dormire sonni tranquilli.

Infine, per il restore dei dati ci sono almeno tre scelte:
1) Si fa tutto tramite l'applicazione desktop
2) Da Windows Explorer si può accedere al proprio spazio remoto sul server di Mozy tramite un hard disk virtuale chiamato MozyHome Remote Backup, che si comporta come un disco locale!
3) Si va sul sito di Mozy e dalle pagine private del proprio account sfogliare il materiale salvato online e scegliere cosa si vuole scaricarsi. Dopo aver confermato la selezione Mozy si mette al lavoro zippando il materiale scelto, e informa l'utente via mail quando questo è pronto. All'arrivo della mail l'utente può quindi scaricarsi lo ZIP auto-estraente in locale; questa soluzione può rivelarsi davvero eccellente nel caso si voglia scaricarsi qualcosa (magari non tutto il backup, ma solo qualche documento specifico) mentre si è da un cliente, in vacanza o comunque in qualche luogo senza il proprio PC e soprattutto senza una copia locale dei dati con i quali si lavora da casa.

Ancora non vi basta per convincervi a provarlo?

Dopo 10 anni di consulenze on-site per una moltitudine di clienti diversi, c'è una cosa che non smette di colpirmi e sorprendermi, anzi lo fa sempre di più con il passare del tempo. Sto parlando dell'apparente incapacità di moltissimi programmatori di cercare informazioni online. Non è affatto raro trovare qualcuno che ha un problema e che sta li ore ed ore a sbattere la testa con il proprio codice non funzionante, a grattarsi la testa davanti ad un criptico messaggio di errore che non se ne vuole andare, e al massimo ridursi a cercare lumi nella documentazione locale installata assieme al software/framework/IDE/linguaggio del caso.

Ma come si fa...non è infinitamente più semplice, immediato e produttivo cercare la soluzione online, e più specificatamente tramite Google? Con un messaggio di errore spesso è semplicissimo, basta copiare e incollare il messaggio as-is, e metterlo tra virgolette in modo da cercare la frase esatta. Pochi risultati? Togliete le virgolette. Troppi risultati? Aggiungete, fuori dalle virgolette, qualche parola chiave relativa al vostro contesto. Con un problema tipo "come eseguire del codice javascript al termine di un aggiornamento parziale tramite UpdatePanel di ASP.NET?" le cose si complicano, ma solo un po'.

In realtà oltre ai programmatori che per qualche misterioso motivo proprio non pensano di usare un motore di ricerca per trovare una soluzione, ci sono quelli che ci pensano, anche subito magari, ma mollano dopo qualche query infruttuosa. Essere in grado di cercare con profitto su Google è un'abilità che va affinata con la pratica, come qualsiasi altra cosa, quindi è normale che cercare a caso senza criterio spesso porti a cattivi risultati. Ma il problema è anche che la stragrande maggioranza dei programmatori italiani usa tool di sviluppo localizzati in italiano, legge documentazione in italiano, e parla solo con colleghi italiani. Usare un IDE/framework in italiano significa che i messaggi di errore saranno in italiano, e cercare in Google quel messaggio di errore in italiano ovviamente produrrà una quantità di risposte infinitesimale rispetto alla ricerca dello stesso messaggio di errore in lingua originale, ovvero in inglese. Tradurre "a occhio" il messaggio di errore non funziona bene, anzi mettendo il messaggio tra virgolette quasi sicuramente non funzionerà affatto. (questo è anche causato dal fatto che l'iniziale traduzione da inglese a italiano spesso viene fatta in modo un po' fantasioso, e solo quel primo traduttore potrebbe forse essere in grado di compiere il procedimento inverso ottenendo perfettamente la frase di partenza :-)

A parte i messaggi di errore da copiare e incollare, e indipendentemente dalla lingua dei propri strumenti, una larga percentuale di programmatori si ostina a cercare soluzioni e pezzi di codice scrivendo in italiano. Questo non è patriottismo o nazionalismo...è poca furbizia, o poco interesse. Certo, in italiano abbiamo delle fantastiche risorse come i forum di ASPItalia , i forum di Visual-Basic.it, oppure vari newsgroup. Una ricerca lì vale la pena farla, magari anche lasciare la propria domanda se non si trova già qualcosa di pronto...ma nel caso i primi 10 minuti di ricerca in italiano non risolvessero la questione vogliamo passare all'inglese?

In Italia abbiamo programmatori bravissimi, come in ogni altra parte del mondo...ma siamo pochi, pochissimi se paragonati alle decine di milioni di programmatori che usano l'inglese come lingua principale o che comunque lo conoscono sufficientemente da scrivere in linguaggio *tecnico*. E' una questione di numeri, tutto qua. Qualcuno alza la mano dicendo che non conosce l'inglese? Beh, è ora di impararlo! Non averlo studiato a scuola non è una ragione valida. L'inglese è facile da imparare, ed esistono infinità di corsi su CD, DVD, film
sottotitolati, libretti semplici per cominciare a farci la mano. L'inglese tecnico poi, quello che serve ad un programmatore per capire e farsi capire, è formato da una sintassi di base, un piccolissimo sottoinsieme di termini generici, e una grande quantità di termini specifici di settore (da conoscere in ogni caso). Anche con una conoscenza di base, e leggendo documentazione in inglese, si sta prestissimo a farci la mano. Scrivere funziona alla stessa maniera, bisogna cominciare a farlo. E sempre di più in futuro.

La prossima volta che farete un colloquio di lavoro a qualcuno chiedetegli come si comporta davanti ad un messaggio di errore incomprensibile o davanti ad un problema che non sa come risolvere. Se non vi dirà che cerca su Google (o perlomeno su forum e newsgroup di settore) e se ammetterà di non poter leggere e scrivere in inglese tecnico, pensateci bene...

Una corretta attitude verso la ricerca può servire più di una conoscenza di partenza della tecnologia di turno; e l'inglese non serve solo per gestire eventuali clienti o partner stranieri, serve per il lavoro di ogni giorno.

Nella mia recensione dell'iPhone dicevo che finalmente è davvero possibile avere Internet in tasca, grazie alle ottime capacità di Safari Mobile e grazie alla facilità di interazione offerta dalla UI e dallo schermo multitouch del device. Questo vuol forse dire che le informazioni che ci servono (per lavoro, per svago ecc.) possono essere sempre ricercate e consultate tramite i siti web esistenti, piuttosto che tramite applicazioni native ad-hoc? La risposta è: certamente no.

Il motivo è semplice: una pagina web pesa tranquillamente 500 KB (o anche molto di più, se siamo un po' sfortunati) tra html + css + immagini, ma le informazioni testuali che effettivamente ci servono saranno probabilmente pochi KB; se il problema fosse solo il maggiore tempo di attesa prima che i contenuti vengano scaricati basterebbe essere più pazienti, ma c'è ovviamente dell'altro. Il vero problema è che - in Italia ma in parecchi altri Paesi - non c'è una connessione flat per il traffico dati sui device mobili, ma si paga a traffico effettuato, eventualmente con dei pacchetti prepagati a tariffa "conveniente" (relativamente alle tariffe normali, altrimenti di conveniente ci sarebbe ben poco...). Ad esempio il Vodafone Pack prevede un traffico di 150 500 MB settimanali al costo fisso di 3€. Un traffico di questa entità è sufficiente per controllare la posta tramite i client integrati, e per visitare sporadicamente qualche sito web piuttosto leggere. Se però bisogna frequentemente consultare un paio di pagine da 500 KB di un certo sito, per ricavare poche informazioni relative ma disperse in più pagine, è chiaro che a 1 MB al colpo si stà presto a consumare una fetta troppo grossa del traffico disponibile.

Ecco dunque il senso di una applicazione nativa: questa si dovrebbe scaricare - tramite un web service o qualcosa di simile - solo i dati "grezzi" necessari, e poi formattarli, manipolarli e visualizzarli localmente. Ho provato a scrivere un web service classico (in ASP.NET...tecnologie MS forever dove possibile ;) che restituisse solo i dati: 45 KB di testo. 1/22 del traffico richiesto dalla navigazione via web per ottenere gli stessi dati...non male come risparmio no? Certo c'è da mettersi lì ed investire tempo a sviluppare una applicazione nativa custom, il che può non essere semplice, ma probabilmente l'applicazione potrà essere molto apprezzata da chi ha spesso bisogno di quelle info ma non vuole consumarsi tutto il suo traffico settimanale. Chissà, magari per un risparmio del genere sui costi di connessioni potrebbe essere pure disposto a pagare qualcosa per ringraziarvi del lavoro...

45K è un valore accettabile, ma pensandoci un po' si può fare di meglio. In quei 45K ci sono anche tutti i tag XML della risposta, dato che si tratta di un web service. XML/SOAP sono lo standard per un web service multipiattaforma, interoperabile e facilmente interpretabile...ma tutto ciò ci serve nel caso di una applicazione mobile che usa assolutamente in esclusiva quel servizio? No, non serve. In un caso del genere va benissimo un HttpHandler che si prende i parametri in querystring, e restituisce del plain text dove tutte i dati di risposta sono accodati in un ordine conosciuto e sono separati da un carattere particolare specifico. Come si faceva una volta ai tempi di ASP insomma. Il servizio di test che ho sviluppato con questo approccio produce delle risposte medie di 15K. 1/3 del traffico richiesto dal WS, e 1/66 del traffico richiesto dalla navigazione di 2 pagine web. Un risparmio che difficilmente non si può apprezzare. Come al solito quindi ogni soluzione o tecnologia va contestualizzata alla specifica situazione e necessità.