Marco Bellinaso

Librerie e framework open-source per sviluppatori iPhone

Marco Bellinaso — Thu, 03 Sep 2009 15:57:00 -0500

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! ;)

Postino approda anche su Facebook

Marco Bellinaso — Tue, 23 Jun 2009 14:41:00 -0500

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!

99 (o più) idee per il tuo prossimo logo o web design

Marco Bellinaso — Sat, 13 Jun 2009 12:56:00 -0500

Ideare, scegliere e realizzare il logo per un'applicazione o un sito web è un'attività critica e importante. Una scelta sbagliata può dare un'idea negativa all'utente ancora prima che questo abbia effettivamente valutato l'opera. Anche se il logo non è "brutto" ma è piacevole e realizzato in maniera professionale, non necessariamente rifletterà in maniera opportuna "l'anima" dell'applicazione/sito. Magari è troppo serio e cupo per il target giovane al quale ci si rivolge...o viceversa.

Ecco perchè è importante affidarsi a dei professionisti ai quali spiegare dettagliatamente cosa fa il prodotto, a chi si rivolge, che idea deve suggerire il logo, ecc. Purtroppo anche il grafico più bravo non ha delle idee limitate e avrà comunque un proprio gusto personale che tenderà ad inserire in qualche modo nelle proprie proposte. Se il grafico è un freelance poi, diventa troppo dispendioso fargli fare decine di bozzetti diversi, o addirittura commissionare i bozzetti a grafici diversi per poi scegliere il preferito da finalizzare.

O almeno era così per chi non conosce 99designs! Tramite questo servizio (fondato dal co-fondatore del famosissimo SitePoint...ovvero il corrispettivo di HTML.it a livello mondiale) è possibile richiedere una qualsiasi realizzazione grafica (non solo loghi ma anche siti web, design per cancelleria, magliette, banner, cartelloni pubblicitari ecc.) creando un vero e proprio contest. In pratica si descrivono le proprie necessità e le proprie preferenze sullo stile, si offre un premio in dollari (vedere qui per i premi minimi per le varie categorie), si paga e si attendono le prime proposte! Il contest dura una settimana di default, ma può essere ulteriormente esteso. Sebbene sia sempre prepagato, può essere garantito o meno. "Garantito" significa che bisogna per forza scegliere un vincitore: questo tipicamente attira più partecipanti perchè questi sanno che almeno uno dovrà necessariamente vincere; d'altra parte espone anche alla possibilità che non ci piaccia nessun design ma si debba comunque scegliere e pagare qualcuno. I contest non garantiti invece forse attirano un po' meno gente (ma dipende anche dalla somma offerta!) ma consentono di venire rimborsati se non si vuole scegliere nessuno dei design proposti.

Con GetConnected abbiamo usato con soddisfazione 99designs per il logo di AnguriaLab, spin-off che sviluppa applicazioni per iPhone e altre piattaforme mobile.Volevamo un logo che fosse bello da vedere, ma che suggerisse anche simpatia, freschezza e divertimento. Il risultato direi che c'è!

La cosa che ci è piaciuta di più di 99designs è stata proprio la possibilità di poter scegliere tra decine e decine di idee anche molto diverse; è stata un'opportunità che non avremmo mai potuto avere seguendo la strada tradizionale. I design proposti possono essere commentati e si può chiedere all'autore di apportare varie modifiche, un po' per volta, fino ad arrivare alla versione che si ritiene ottimale. Per il logo di AnguriaLab abbiamo trovato dei grafici veramente disponibilissimi alle modifiche...pure troppo, visto che alla fine ci è dispiaciuto premiarne solo uno!

Consiglio: aspettate fino alla chiusura per la scelta finale. Il logo che abbiamo scelto per il nostro contest è stato inviato a un'ora dal termine (la durata totale è stata di 7 giorni), quando ormai eravamo assolutamente convinti di un'altra idea inviata già il secondo giorno!

Finito il contest molti grafici ritirano le proprie proposte, probabilmente per il timore che il gestore del contest rubi le loro idee senza averli premiati. Ecco perchè incollo di seguito uno screenshot con varie proposte di un contest ancora in corso, anzichè il nostro :)

P.S: leggi la segnalazione originale di Alberto Falossi.

Spedire vere cartoline dal proprio iPhone? Con Postino si può!

Marco Bellinaso — Tue, 02 Jun 2009 12:38:00 -0500

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

Qualche consiglio per chi vuole pubblicare applicazioni iPhone

Marco Bellinaso — Tue, 21 Apr 2009 18:55:00 -0500

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

Programmatore web/ajax? Vinci un premio in denaro...e un lavoro!

Marco Bellinaso — Fri, 17 Apr 2009 18:42:00 -0500

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?!

Controllare gli orari dei treni con Locomotimes per iPhone

Marco Bellinaso — Sat, 04 Apr 2009 07:32:00 -0500

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

Imparare a programmare per iPhone

Marco Bellinaso — Wed, 25 Feb 2009 08:05:00 -0500

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.

Web Development Server, Windows XP e richieste remote

Marco Bellinaso — Tue, 24 Feb 2009 12:15:00 -0500

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.

Ma non sai cercare con Google? Aspetta che ci penso io...

Marco Bellinaso — Wed, 28 Jan 2009 16:10:00 -0500

Vi è mai capitato di rispondere in questo modo (o almeno desiderare di poterlo fare...) a qualcuno che vi fa una domanda banale e che ovviamente non ha speso neppure 10 secondi provando a fare una ricerca veloce su Google? Invece di rispondere come vorreste, fate voi la ricerca per conto suo...non direttamente su Google però, ma su LetMeGoogleThatForYou. Copiate l'Url generata dal sito e inviatela al vostro interlocutore. Per vedere l'effetto ottenuto al click provate voi stessi con l'immagine in questo post (e fate attenzione alle spiegazioni :)

Mini recensione BlackBerry Bold

Marco Bellinaso — Wed, 21 Jan 2009 08:14:00 -0500

Esattamente un mese fa ho ricevuto in "prestito a scadenza indeterminata" (grazie ad Alessandro, Federico, James e Davide!) uno dei recenti BlackBerry Bold. Da allora il mio iPhone 3G è rimasto spento e chiuso in un cassetto. Il motivo è presto detto: sebbene iPhone abbia un'interfaccia utente e un tipo di interazione che non ha pari in nessun'altro telefono, la sua effettiva utilità "sul campo" risulta limita da almeno due fattori:

1) Le limitazione che Apple impone agli sviluppatori di terze parti: non poter scrivere applicazioni che girano in background significa ad esempio non poter avere client Messenger, Gtalk o Skype sempre attivi e pronti a ricevere messaggi. Oppure significa non poter ricevere eventi di sistema in qualsiasi momento (nuovo SMS o mail in ingresso) per scatenare qualche operazione particolare. Non poter accedere a varie funzioni telefoniche (invio SMS, gestione completa della fotocamera ecc.) riduce ulteriormente il numero di applicazioni utili che si possono creare. Resta pur sempre una gran quantità di cose che si possono fare, ma meno di quelle che desidererei. Ora che un abbonamento da 3€ a settimana mi consentirebbe di avere 2GB di traffico a settimana, vorrei tenere Messenger e Gtalk sempre attivi...non poterlo fare è un "deal breaker".

2) La tastiera su touchscreen funziona discretamente bene, sicuramente infinitamente meglio dei vari tentativi he ho provato su molti altri telefoni, ma non è al livello di una tastiera fisica. Va bene per scrivere un Url nel browser, o un SMS...ma scordatevi di scrivere un mini-documento Word o una mail di più di 2 righe...specie se non avete un'infinita pazienza, tempo...e se non siete perfettamente fermi! Si perchè se provate a scrivere mentre camminate o mentre siete in macchina (non alla guida...) con qualche vibrazione e scoprirete che centrare il tasto voluto si complica significativamente.

Per quella che è la mia esperienza, il BlackBerry Bold risolve in modo quasi brillante entrambe le problematiche. Partiamo dalla seconda: la sua tastiera fisica è ottima, probabilmente la migliore che abbia mai provato. E' sufficientemente ampia per essere usata comodamente, i tasti hanno un buon feedback e non mancano un colpo; inoltre si auto-retroillumina in condizioni di oscurità. Riguardo al primo punto, anche se è vero che neppure col BlackBerry un programmatore può fare tutto-tutto (non si possono ad esempio cancellare SMS in ingresso o spostarli, non si possono chiudere applicazioni o interagirci in qualche altro modo, la customizzazione di applicazioni di sistema è un po' limitata ecc.), la libertà che si ha è di un'ordine di grandezza superiore a quella dell'iPhone. E' un dato di fatto, non un'opinione!

A parte questo, anche le applicazioni di sistema del BlackBerry sono molto più complete: c'è un Address Book "serio" (con i gruppi), il copia e incolla (che non pensavo mi sarebbe stato così utile finchè non ho dovuto iniziare a rispondere a molti clienti con una risposta fissa contenente Url e altre informazioni), un registratore video, un gestore di password, un editor per Word, Excel e PowerPoint, e altre cosette ancora.

Tutto il sistema è velocissimo e passare da un'applicazione all'altra (o chiuderla) è cosa di un istante - anche l'iPhone è sufficientemente veloce, ma non a questi livelli...colpa non tanto forse della potenza reale, ma delle onnipresenti animazioni...belle, ma che ovviamente rubano un po' di tempo.

La batteria dura circa 2 giorni con un normale utilizzo (mezz'ora di telefonate al giorno, qualche SMS, connessione 3G sempre attiva, programmi in background come Messenger e Gtalk sempre attivi, e un po' di navigazione). Niente male, diciamo al pari dell'iPhone.

Il browser integrato mi ha lasciato così soddisfatto che non ho neanche provato ad installare alternative come Opea Mini. Certo, il browser dell'iPhone non ha paragoni, ma quello del Bold comunque ha sempre renderizzato correttamente tutti i siti che visito e i suoi 3 livelli di zoom consentono di navigare le pagine molto comodamente.

Un'altra cosa simpatica del BlackBerry (e della sua tastiera) è che offre un milione di scorciatoie alle operazioni più comuni. Ad esempio per rispondere ad un SMS o mail (anche nei programmi non di sistema ma che comunque aderiscono alle linee guida di RIM, come ad esempio il client GMail fatto su misura da Google) basta premere "R", per scrollare verticalmente una pagina (utile proprio nel browser) si preme la "space bar", per cancellare un elemento da una lista si preme "backspace" ecc. ecc.

Volendo trovarci dei difetti, devo dire che la qualità costruttiva generale è inferiore a quella del dispositivo di Apple, pur essendo comunque più che discreta. Ad esempio la cornice esterna non è di metallo ma di plastica, il coperchietto posteriore è di "plasticaccia" leggera, e a premere sullo schermo questo si abbassa di mezzo millimetro. Nell'iPhone il case esterno è assolutamente perfetto e super rigido. Un altro difetto, non del telefono in questione quando piuttosto della piattaforma BlackBerry, è che il software di terze parti costa molto di più (costo medio sui 10$) dei rispettivi per iPhone (costo medio sui 1-2$). Inoltre spesso il software è meno curato nell'aspetto, anche se magari può fare più cose.

In molti potrebbero preferire l'ampio display dell'iPhone a quello del Bold: è una critica ragionevole, ma ovviamente dipende dall'utilizzo che farete del telefono. Se volete qualcosa per telefonare e scrivere, e da usare solo di tanto in tanto come player video, il display del Bold è più che sufficiente - nonostante la dimensione più ridotta infatti la qualità è eccelsa: colori brillanti e risoluzioni uguale a quella dell'iPhone (480x320). Se cercate un device per vedere contenuti multimediali, e che quando serve vi contenta anche di telefonare, allora l'iPhone è quello che fa per voi.

In conclusione, per ora con il BlackBerry Bold + flat dati da 3€/settimana (senza il quale si perdono molti dei vantaggi e del gusto di avere un device di questo tipo!) sono soddisfattissimo: la tastiera mi consente di scrivere in scioltezza anche mail piuttosto lunghe, o di chattare con Messenger e Gtalk; la parte telefonica funziona semplicemente come ci si aspetterebbe, il browser fa bene il suo lavoro, e il display mi permette di vedere qualche episodio di una sitcom quando spendo una mezz'ora in treno.

Da notare infine che il nuovo BlackBerry Storm sembra essere un'ulteriore ottima alternativa all'iPhone): ampio display per contenuti video e navigazione su web, solo touch-screen, e applicazioni di terze parti che potenzialmente possono fare quasi tutto. La mancanza della tastiera è quasi una scelta di vita però.

Sviluppare per iPhone, BlackBerry, Symbian o Windows Mobile?

Marco Bellinaso — Mon, 15 Dec 2008 18:57:00 -0500

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

Backup remoto con Mozy

Marco Bellinaso — Mon, 15 Dec 2008 08:58:00 -0500

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?

Nuovi stili per Gmail...e per tutto il resto!

Marco Bellinaso — Mon, 24 Nov 2008 08:00:00 -0500

Qualche giorno fa Google ha regalato ai propri utenti di Gmail una nuova piccola feature: la possibilità di cambiare lo stile di default scegliendo un tema alternativo. Per andare nella galleria dei temi basta cliccare Settings / Themes e poi scegliere una delle attuali 31 possibilità.

Una moltitudine di blog hanno già parlato di questa novità (manco fosse una cosa così eccezionale), omettendo di citare che in realtà esiste già da tempo una soluzione (di successo direi, dato che è usata da quasi 2,5 milioni di persone) per fare la stessa cosa...ma per qualsiasi sito! Parlo dell'estensione Stylish di FireFox, e del relativo sito di supporto UserStyles.org.

Quello che fa questa estensione è sostanzialmente molto semplice: permette di applicare a qualsiasi sito o pagina uno stile CSS custom. Cambiando lo stile CSS è possibile cambiare colori, immagini e loghi, e addirittura rendere visibili o invisibili alcune sezioni della pagina (ad. esempio una colonna laterale contenente solo pubblicità). Il sito UserStyles.org è un enorme repository di stili creati e condivisi da altri utenti: basta cercare il nome di un sito e verranno elencati i relativi stili custom da scaricare e applicare tramite Stylish.

Ecco un esempio di come si può trasformare FaceBook:

...oppure Google:

Oltre a rendere un sito più gradevole alla vista (perlomeno secondo i propri gusti...) quest'estensione può essere molto comoda per i possessori dei mini notebook da 9" o 10" che vanno così di moda ultimamente: applicando infatti uno stile che elimini (nascondendole) colonne o sezioni di pagina "inutili", la ridotta risoluzione dello schermo potrà essere usata al meglio per visualizzare i contenuti "interessanti".

L'importanza di Google e dell'inglese per uno sviluppatore

Marco Bellinaso — Mon, 10 Nov 2008 19:00:00 -0500

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.