Marco Bellinaso

Ormai un annetto fa (wow!) ho pubblicato un post dal titolo "Librerie e framework open-source per sviluppatori iPhone" dove parlavo di alcune delle librerie iPhone usate in alcuni progetti recenti. Nel tempo, come qualsiasi altro sviluppatore, mi sono salvato tra i bookmark una quantità di altro materiale interessante: articoli, video, esempi di codice, librerie, framework, servizi web e quant'altro. Oggi ho pubblicato il malloppone a quest'url: http://www.mopapp.com/directory/best-resources-iphone-developers

 A parte l'utilizzo dell'inglese, il concetto è lo stesso: ho descritto brevemente ciascuna risorsa censita, e ho censito solo quelle risorse che ritenevo effettivamente utili e di buona qualità. Nonostante non fosse mia intenzione creare un elenco kilometrico, la pagina conta già più di 60 risorse, e sicuramente si allungherà via via nel tempo. A proposito, chiunque volesse contribuire mi può contattare privatamente o scrivere qui nei commenti ;)

A presto una lista analoga per dev Android...

E a presto anche una descrizione di Mopapp.com, il sito-servizio (ad oggi in beta privata, ma presto in beta pubblica!) per sviluppatori mobile che ospita la pagina...

Oggi sono stato al Dip. di Ingegneria a Bologna, dove si teneva un workshop sulla programmazione iPhone. Il mio intervento verteva sulle tecniche per l'interrogazione asincrona e il consumo di servizi REST JSON, e a tale scopo avevo preparato un piccolo clientino per Twitter (il pratica il nuovo Hello World della programmazione :)

Di seguito le slide e il sorgente:

HelloTwitter.zip (66,14 kb)

La società per la quale lavoro, GetConnected Srl (assieme alla spin-off AnguriaLab LLC) cerca nuovi sviluppatori da inserire nel proprio organico, nella sede di Bologna (pressi del centro). Le figure che cerchiamo sono dei buoni programmatori / analisti, con una discreta esperienza lavorativa, ma anche dotati di molta passione e voglia di imparare e migliorarsi costantemente. Programmatori che ancora lavorano con VB6 e che almeno per conto proprio non si sono aggiornati, che non sanno cosa sia AJAX / jQuery / REST / MVC, che non leggono nessun blog tecnico e che sostanzialmente vogliano fare un lavoro "comodo" senza faticare troppo per restare aggiornati...astenersi prego! :)

Le tecnologie da conoscere? In GetConnected si lavora molto con .NET, Java, Adobe Flex e Flash, iPhone / BlackBerry / Android SDK...and more. Sviluppiamo app web-based (molto AJAX), portali (Alfresco, di cui siamo partner, o cose custom), servizi e app per telefoni (al momento iPhone, Android, BlackBerry e WinMobile...ma vorremmo andare anche su Nokia/Symbian con Flash Lite o Java). I candidati ideali devono avere una buona conoscenza di almeno una delle tecnologie citate, meglio se un paio. E ovviamente una conoscenza di base su tutto quello che ci sta attorno (DB SQL Server / MySql, web server, HTML, CSS, i pattern più diffusi, la capacità di analizzare problemi e fare delle stime...)

Se state cercando lavoro o quello attuale vi annoia e non vi stimola, e quanto detto sopra non vi spaventa (anzi!) allora potete contattarci per venire a conoscerci! 

Da qualche mese a questa parte il mio lavoro è all'80% su progetti di sviluppo per iPhone (in un prossimo post dirò perchè questo mi dia molta soddisfazione :). Si tratta sia per progetti interni da pubblicare sotto il brand di AnguriaLab che per soluzioni custom per clienti (vecchi e nuovi) di GetConnected che si sono resi conto delle ottime potenzialità di questa piattaforma (sia tecnologiche che di penetrazione del mercato) e ne vogliono aproffittare sia per aumentare la propria visibilità che effettivamente per incrementare il proprio fatturato raggiungendo nuovi potenziali clienti e offrendo qualcosa di più rispetto ai propri competitor.

L'SDK dell'iPhone è veramente vasto e molto completo, e spesso rende molto semplici operazioni come dialogare con il GPS o la fotocamera on-board, scaricare dati da web, manipolare i contatti o gli appuntamenti presenti nel telefono, gestire animazioni ed effetti di transizione tra schermate ecc. ecc. Cose che su altre piattaforme possono a volte essere piuttosto complesse e problematiche (per i limiti intrinseci dell'hardwar, per i limiti dell'SDK, o per la non-uniformità dei vari modelli su cui gira un certo sistema operativo)

Nonostante queste belle parole, anche l'SDK dell'iPhone ha i suoi punti deboli. Se è vero che gestire alcune cose complesse è molto semplice, è quasi paradossale che gestire come in teoria "semplici" come riempire schermate di elenco con immagini o con testo su più righe, costruire menu di navigazione a più livelli, gestire una cache locale su disco per i dati scaricati da web, lavorare con JSON, XML, regular expression...siano cose non dico complesse, ma quantomeno macchinose e dispendiose da programmare. Perlomeno se si usano solo gli strumenti di default offerti da Apple.

Ecco allora un elenco di librerie di codice (tutte open-source e sotto licenza BSD o simili) che sto usando al momento e che permettono di ridurre molto i tempi di sviluppo per alcune funzionalità, rendendo il proprio codice anche più conciso, leggibile e manutenibile:

1) Three20: sviluppata da Joe Hewitt, autore dell'ottima applicazione Facebook Connect per iPhone, questo framework nasce appunto dal codice che Joe ha scritto per Facebook. La libreria è veramente ricca di classi; in pratica molti dei componenti di UI di base sono stati riscritti o estesi con nuove funzionalità. Ad esempio invece che usare UIButton, UILabel o UITableViewController si potranno usare le classi TTButton, TTLabel o TTTableViewController; queste versioni offrono nuove proprietà per renderizzare i componenti con stili grafici aggiuntivi, o magari per implementare una data source (nel caso di view che renderizzano elenchi, ad esempio) in poche righe e in modo centralizzato invece che dover ogni volta implementare delegate e protocolli che richiedono di scrivere un tot di metodi ogni volta. Altri componenti molto interessanti sono TTPhotoViewController e TTThumbsViewController che gestiscono schermate per visualizzare librerie di foto a tuto schermo o in versione miniatura, oppure TTURLCache per gestire una cache locale di immagini e altri contenuti scaricati via web. E altro ancora...date un'occhiata alla pagina linkata per saperne di più. Oltre a fornire una grande quantità di codice pronto all'uso questa libreria è anche un ottimo esempio di "codice ben scritto", da usare come modello per imparare i pattern e le best-practice più comuni della programmazione con Cocoa e Objective-C. 

2) OpenFlow: vi piace l'interfaccia tridimensionale CoverFlow che Apple ha usato dentro la sua app iPod quando l'iPhone è in orizzontale? Vi piacerebbe utilizzarla all'interno dei vostri programmi? In questo post Erica Sadun spiegava appunto come usare la classe UICoverFlowLayer per tale scopo; peccato la si possa usare solo in applicazioni che non saranno pubblicate sull'App Store ufficiale, perchè si tratta di una API privata e quindi Apple non gradisce che la si usi! OpenFlow invece è una totale reimplementazione custom, realizzata da Alex Fajkowski mediante CoreGraphics e QuarzCore per gli effetti di prospettiva e riflesso. L'effetto finale è pressochè perfetto! E' possibile caricare le immagini tutte in un colpo solo o in maniera asincrona via via che queste devono essere visualizzate (strada da seguire nel caso le immagini siano da scaricarsi da online magari) ed è possibile cambiare le dimensioni degli elementi visualizzati. Anche qui ci sono cose interessanti da imparare studiandosi i sorgenti ;)

3) JSON-Framework: ormai quando si interroga un servizio online è molto probabile che questo restituisca dati in JSON piuttosto che XML, data la sua maggiore compattezza e quindi maggiore velocità di download e minore consumo di banda. Questa libreria offre dei metodi "stand-alone" + una estensione alla classe NSString, per cui semplicemente chiamando la nuova proprietà JSONValue di una stringa contenente dei dati in formato JSON questi vengano "parserizzati" e inseriti in un array o dizionario, eventualmente gerarchico. Più semplice di così...

4) RegexKitLite: le regular expression sono una delle più belle invenzioni per i programmatori...e quelli che ancora non le conoscono non sanno quanto tempo stanno sprecando e cosa si stanno perdendo :) Cercare, estrarre, sostituire sottostringhe all'interno di un'altra stringa con le regex diventa un compito veloce e "pulito". Senza? Preparatevi a scrivere blocchi e blocchi di codice nidificato e indici di inizio-fine stringa che non potranno far altro che confondervi le idee :) Su Mac OSX esiste ICU, una libreria C/C++ statica che tra le altre cose implementa anche le regex. RegexKitLite invece è una libreria che wrappa queste funzioni C all'interno di classi Objective-C di semplice utilizzo. Come per JSON-Framework, anche in questo caso la classe NSString base viene estesa con nuovi metodi per cercare e sostituire sottostringhe complesse.

5) KissXML: certo, ormai molti servizi restituiscono JSON, ma XML ovviamente è tuttora usatissimo...e bisogna lavorarci. In Cocoa "full" (quello usato per app che girano su OSX) c'è NSXML, ovvero un set di classi (NSXMLDocument, NSXMLElement, NSXMLNode ecc.) in grado di effettuare il parsing di testo XML in un singolo passo e di rappresentarlo poi con una struttura gerarchica  in memoria, per una semplice navigazione ed estrazione dei dati. Probabilmente per motivi di performance e di consumo di memoria queste classi non sono state rese disponibili nel framework Cocoa Touch dell'iPhone e ci si dovrebbe invece accontentare della classe NSXMLParser: è un parser SAX, che quindi analizza l'XML in modalità asincrona e solleva vari eventi via via che legge e trova nodi ed elementi. E' inoltre a sola lettura, quindi non va bene per creare o modificare documenti XML. Soluzione più comoda? KissXML, che basandosi sulla libreria C libxml2 implementa un qualcosa in stile NSXMLDocument. Se vi trovate a dover lavorare con XML non enormi e magari già presenti in locale, è decisamente un'ottima alternativa in quanto a comodità.

===

Queste sono solo le librerie che sto usando nel progetto su cui sto lavorando al momento. Sul web c'è molto altro e ogni giorno trovo qualcosa di interessante e utile; nuovi progetti nascono e crescono. Molto è open-source e con una community di supporto che ci gira attorno. Sta succedendo un po' quello che è successo anche con .NET e con altri framework di enorme diffusione e successo...e di questo i programmatori iPhone di qualsiasi livello devono senz'altro rallegrarsi! ;)

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

Se volete affrontare l'avventura dello sviluppo per iPhone c'è un consiglio prezioso che vi posso dare: iscrivetevi all'iPhone Developer Program con almeno un mese di anticipo rispetto alla data prevista di fine sviluppo, o un mese e mezzo rispetto alla data entro cui vorreste vedere l'applicazione effettivamente pubblicata su iTunes!

Una volta terminato lo sviluppo (probabilmente avendo sudato sette camicie, specie se si tratta della prima esperienza su questa piattaforma) uno sviluppatore/azienda vorrebbe solo pubblicare il proprio lavoro il più velocemente possibile, per iniziare a raccogliere feedback e introiti. Senza la consapevolezza di alcuni meccanismi di Apple si rischia però di passare varie settimane con l'ansia...

Per pubblicare su iTunes serve innanzitutto essere iscritti all'Apple Developer Program, che ha un costo di 99$. Uno si aspetterebbe che l'iscrizione venga confermata all'istante, a seguito di una mail di conferma dove cliccare un link, o al limite dopo un processo di approvazione di massimo 24-48 ore (come avviene per esempio nel caso si richieda un certificato per firmare applicazioni per BlackBerry). Invece, l'approvazione al programma da parte di Apple richiede circa 2 settimane...che potrebbero tradursi in 3-4 se al primo giro "sbagliate" a fornire qualche informazione o documento ("sbagliate" è virgolettato, perchè per qualche policy non ben specificata alcuni indirizzi e-mail per i contatti di riferimento non vengono accettati, ad esempio). La cosa strana è che nella prima settimana non sembra esserci alcuna attività...non vi vengono neppure chiesti i soldi...è solo dopo una settimana che vi viene chieso il pagamento e documenti vari attestanti l'identità della vostra persona fisica o della vostra società. La settimana di verifiche manuali che seguono questo step la potrei anche capire...ma la prima? Non bastava chiedere pagamento e documenti tramite una mail automatica, subito dopo la compilazione del modulo online?

Da sapere inoltre che far parte del programma è necessario per pubblicare la propria applicazione su iTunes, ma anche per poter provare il programma sul device fisico in aggiunta che sul simulatore. Potete ritardare i test reali per un po'...ma cominciate a farli quando siete almeno a metà dello sviluppo perchè potreste avere varie sorprese, e più tardi cominciate a fare i test più tardi ve ne accorgerete...con il risultato che dinveterà più difficile trovare e risolvere i problemi.

Una volta terminata e testata l'applicazione la si invia per l'approvazione di Apple. Per Locomotimes questo ha richiesto davvero poco tempo: abbiamo caricato i file di venerdì pomeriggio, e lunedì mattina ho trovato la mail di accettazione! In generale però i tempi sono più lunghi, una media di circa 7 giorni. In effetti questo è stato esattamente il tempo necessario per far approvare la versione 1.1 di Locomotimes, quindi prendete questo come dato di riferimento. Prima di inviare l'applicazione assicuratevi anche di usare i tool di Apple (Instruments sopra tutto) per controllare l'allocazione della memoria, l'assenza di memory leak e l'utilizzo della CPU da parte della vostra applicazione; se non si "comporta bene" è probabile che Apple la rigetterà, costringendovi ad effettuare comunque i test, ma a perdere un'altra settimana per la seconda verifica e pubblicazione.

Quando Lomotimes è stato approvato, abbiamo avuto una spiacevole sorpresa: non poteva andare online perchè ad Apple mancavano ancora il contratto relativo alla vendita delle applicazioni. Cioè, Apple vi chiede una serie di documenti solo per farsi iscrivere al programma e per avere la possibilità di ottenere un certificato con il quale firmare le applicazioni e poterle provare sul telefono. Per poter poi distribuire le applicazioni dovete firmare uno specifico contratto, da stampare e spedire ad Apple per posta, in formato cartaceo! Se non ci sono problemi con la spedizione (busta persa, in ritardo ecc.) il tempo per "spuntare" anche questo step richiede altre 2 settimane. In totale siamo quindi a 4 settimane dalla data di compilazione del modulo online.

Se nel frattempo che il contratto viene spedito e approvato avete inviato e fatto approvare anche l'applicazione, 4 settimane risulta essere il tempo medio necessario per andare online.  Non è raro però leggere in giro per i forum di gente che ha atteso mesi prima di vedere online le proprie applicazioni, o perchè i contratti sembravano non arrivare mai o perchè le applicazioni vengono rigettate (a volte con motivazioni quantomeno discutibili).

Questo post non vuole necessariamente essere una critica al meccanismo di pubblicazione richiesto da Apple. E' così e basta. Onde evitare settimane di snervante attesa è però importante conoscerlo e saperlo affrontare con un discreto anticipo. In compenso una volta sopravvissuti alla prima pubblicazione le seguenti vi sembrerano quasi una pesseggiata :)

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 :)

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...

A molti possessori di iPhone (2G o 3G) capita di sperimentare un antipatico bug per il quale l'iconcina degli SMS presente nella schermata home mostra costantemente il bollino rosso di "1 messaggio non letto", quando in realtà questo non esiste. All'arrivo di un nuovo sms il contatore passa a "2", si legge il nuovo sms, il contatore torna a "1", e sembra non esserci modo di fargli intendere ragione e riportarlo a zero come dovrebbe essere. Anche ri-aprire e scorrere tutte le discussioni presenti nell'applicazione di messaggistica, per assicurarsi di non aver davvero saltato alcun messaggio, non sortisce alcun effetto.

La causa è di uno di quegli SMS che gli operatori inviano per notificare che mentre il telefono era spento, occupato o senza rete qualcuno ha cercato di chiamarci. Per qualche sconosciuto motivo quell'sms è in grado di confondere il not-always-smart-phone. Cancellare l'sms incriminato non risolve il problema. La soluzione è tuttavia molto semplice e veloce (una volta scoperta :). Ecco come fare:

1) Spegnere l'iPhone.
2) Farsi chiamare dalla persona che ha originariamente causato l'invio dell'sms da parte dell'operatore. E' possibile capire quale sia questa persona perchè quando si lancia l'applicazione di messaggistica questa tipicamente aprirà automaticamente la discussione con quel contatto.
3) Riaccendere l'iPhone.
4) Entro pochi secondi dovrebbe arrivare l'sms di notifica dell'operatore. Cliccare "Close" nella popup di notifica, e il contatore dovrebbe rinsavire!