Nella mia recensione dell'iPhone dicevo che finalmente è davvero possibile avere Internet in tasca, grazie alle ottime capacità di Safari Mobile e grazie alla facilità di interazione offerta dalla UI e dallo schermo multitouch del device. Questo vuol forse dire che le informazioni che ci servono (per lavoro, per svago ecc.) possono essere sempre ricercate e consultate tramite i siti web esistenti, piuttosto che tramite applicazioni native ad-hoc? La risposta è: certamente no.
Il motivo è semplice: una pagina web pesa tranquillamente 500 KB (o anche molto di più, se siamo un po' sfortunati) tra html + css + immagini, ma le informazioni testuali che effettivamente ci servono saranno probabilmente pochi KB; se il problema fosse solo il maggiore tempo di attesa prima che i contenuti vengano scaricati basterebbe essere più pazienti, ma c'è ovviamente dell'altro. Il vero problema è che - in Italia ma in parecchi altri Paesi - non c'è una connessione flat per il traffico dati sui device mobili, ma si paga a traffico effettuato, eventualmente con dei pacchetti prepagati a tariffa "conveniente" (relativamente alle tariffe normali, altrimenti di conveniente ci sarebbe ben poco...). Ad esempio il Vodafone Pack prevede un traffico di 150 500 MB settimanali al costo fisso di 3€. Un traffico di questa entità è sufficiente per controllare la posta tramite i client integrati, e per visitare sporadicamente qualche sito web piuttosto leggere. Se però bisogna frequentemente consultare un paio di pagine da 500 KB di un certo sito, per ricavare poche informazioni relative ma disperse in più pagine, è chiaro che a 1 MB al colpo si stà presto a consumare una fetta troppo grossa del traffico disponibile.
Ecco dunque il senso di una applicazione nativa: questa si dovrebbe scaricare - tramite un web service o qualcosa di simile - solo i dati "grezzi" necessari, e poi formattarli, manipolarli e visualizzarli localmente. Ho provato a scrivere un web service classico (in ASP.NET...tecnologie MS forever dove possibile ;) che restituisse solo i dati: 45 KB di testo. 1/22 del traffico richiesto dalla navigazione via web per ottenere gli stessi dati...non male come risparmio no? Certo c'è da mettersi lì ed investire tempo a sviluppare una applicazione nativa custom, il che può non essere semplice, ma probabilmente l'applicazione potrà essere molto apprezzata da chi ha spesso bisogno di quelle info ma non vuole consumarsi tutto il suo traffico settimanale. Chissà, magari per un risparmio del genere sui costi di connessioni potrebbe essere pure disposto a pagare qualcosa per ringraziarvi del lavoro...
45K è un valore accettabile, ma pensandoci un po' si può fare di meglio. In quei 45K ci sono anche tutti i tag XML della risposta, dato che si tratta di un web service. XML/SOAP sono lo standard per un web service multipiattaforma, interoperabile e facilmente interpretabile...ma tutto ciò ci serve nel caso di una applicazione mobile che usa assolutamente in esclusiva quel servizio? No, non serve. In un caso del genere va benissimo un HttpHandler che si prende i parametri in querystring, e restituisce del plain text dove tutte i dati di risposta sono accodati in un ordine conosciuto e sono separati da un carattere particolare specifico. Come si faceva una volta ai tempi di ASP insomma. Il servizio di test che ho sviluppato con questo approccio produce delle risposte medie di 15K. 1/3 del traffico richiesto dal WS, e 1/66 del traffico richiesto dalla navigazione di 2 pagine web. Un risparmio che difficilmente non si può apprezzare. Come al solito quindi ogni soluzione o tecnologia va contestualizzata alla specifica situazione e necessità.