Intense Minimalism

iPhone App: inside WideTag’s WideNoise

Qualcuno che mi segue su Twitter se ne sarà accorto da un bel pezzo, ma nei mesi scorsi ho rilasciato (e  aggiornato) assieme a Babele la mia prima applicazione per iPhone, WideNoise. Era già da un po’ che giocavo con Xcode, ma questa è la prima applicazione di una portata rilevante che realizzo. Portable Firefox CX per quanto utilissimo è davvero un giocattolo al confronto.

Origine

Il progetto nasce all’interno di WideTag mentre si rifletteva su qualche modo efficace di utilizzare le tecnologie spime-centered che stavamo sviluppando su qualcosa di più vicino alle persone, qualcosa di intuitivo e facilmente utilizzabile. In origine pensavamo a dei rilevatori di inquinamento, o anche solo di CO2, ma agganciare un sensore ad un telefono oltre che comunque con una certa complessità necessiterebbe anche la vendita del sensore stesso.

Così ad un certo punto abbiamo notato che anche l’inquinamento acustico è una forma di inquinamento, peraltro molto poco percepita e del quale non si parla a sufficienza. L’idea originale? Io ricordo un accenno di Bru, ma anche Babele e Lee avevano qualcosa di simile che gli ronzava in testa. Non saprei a chi attribuire la proposta iniziale però.

Design

Siamo partiti dalle funzionalità che volevamo incluse, sostanzialmente due:

1. La rilevazione del rumore ambientale, ovvero raccolta dei dati dagli spime.
2. La mappatura del rumore su una cartina, ovvero tracciatura utile e sociale dei dati degli spime.

Vista l’esistenza di due funzionalità distinte, abbiamo realizzato due tab, uno di sampling dal microfono e uno di visualizzazione della mappa.

Da un punto di vista dell’interazione volevamo qualcosa di semplice, il più automatico possibile. L’ideale sarebbe stato ovviamente il velocissimo “Premi un pulsante e tutto poi funziona in automatico”.
Dopo alcuni test iniziali così abbiamo notato però che non era raro voler fare delle rilevazioni senza per forza vederle anche nella mappa globale, così abbiamo scorporato le due funzionalità: rilevazione e invio dei dati.

La mappa invece è stato un problema un po’ maggiore perché ci sarebbe piaciuto realizzare una heatmap, ma risultava computazionalmente troppo pesante e sostenere i costi per l’hardware necessario a generarla era un po’ eccessivo visto lo scopo limitato di WideNoise.

La prima idea è stata quella di visualizzare il dato medio dell’area visualizzata, ma abbiamo subito notato che un numero preciso rischiava di creare aspettative su un’area che poi concretamente non erano corrispondenti alla realtà.

Nella ricerca di un sistema più fuzzy abbiamo pensato a mappare vari “oggetti” a varie fasce di rumorosità. In questo modo abbiamo avuto: piuma, gatto, televisione, automobile, dragster, t-rex e concerto rock, come intensità crescente. Il risultato per certi versi ha superato le aspettative: questa è una delle feature che è piaciuta di più e ha anche permesso di rendere più comprensibili numeri che sono troppo astratti: le persone normalmente non sanno “40 db” cosa significa come rumorosità. Se invece dico “televisione” allora già il discorso cambia.

Nella versione 2.0 abbiamo poi cercato di renderlo più sociale. Da un lato creando un po’ di rumore (:P) su Twitter, dall’altro creando un widget delle rilevazioni che si fanno in modo da poterle inserire su siti e blog. Abbiamo anche aggiunto alla mappa le singole rilevazioni della persona e un pannello globale sul sito che visualizza in tempo reale le rilevazioni.

Note tecniche

Affrontare quasi da zero una applicazione per iPhone non è una cosa difficile, ma neppure esattamente una passeggiata. Iniziamo quindi con lo scordarci un bel ‘print “Hello world”‘ alla Python.

L’inizio è buono: gli strumenti di sviluppo sono molto ben progettati e riescono a nascondere un po’ del fatto che, alla fine, stiamo parlando pur sempre di C, seppure in una sua forma evoluta chiamata Objective-C.

Il modello di sviluppo basato su MVC (più VC che MVC secondo me, ma è soggettivo suppongo) semplifica ulteriormente le cose e InterfaceBuilder è uno strumento eccezionale: le interfacce base vengono fatte in un istante, anche se bisogna ben capire il modo in cui si agganciano gli oggetti e gli eventi al codice Objective-C sottostante.
Da un punto di vista degli eventi si gestisce quasi tutto tramite delegation (associando oggetti agli eventi). Io ho provato un po’ di artifici – fattibili – per tentare un approccio più JavaScript-like (associando funzioni agli  eventi) ma alla fine non essendo quello formalmente accettaato si rischiano situazioni miste brutte a vedersi e a gestirsi.

L’unico grosso difetto è forse la sintassi di Objective-C, che a mio parere è difficile da digerire (le quadre… *sigh*). Insomma: se si riesce a trovare un modo di adattare questa sintassi al proprio stile credo che non ci siano alla fine grossi problemi.

La documentazione non è facilmente reperibile perché comunque è un linguaggio per certi versi di nicchia. Abituato alla facilità di reperire informazioni su PHP, Ruby, Python qui spesso si deve scavare nei lunghi documenti ufficiali Apple o in forum.

Il sistema di gestione certificati per sviluppatori è invece un inferno a mio avviso, e una cosa che da Apple proprio non ci si aspetterebbe. Finché sviluppate sul simulatore tutto bene, ma sia per andare sul device fisico sia per rilasciare sullo store è necessario generare dei certificati.
Io mi sarei aspettato una bella gestione trasparente della cosa: un sistema, anche un applicativo separato, dal quale fare richiesta automatica con il proprio account sviluppatore, con tutta l’amministrazione lato server necessaria, anch’essa automatizzata.
Non vi dico qual è il processo esatto, vi dico solo che è tediante e fa perdere un bel po’ di ore, che si moltiplicano nel caso qualcosa vada storto (ad un certo punto durante le beta dell’iPhone OS 3.0 mi son ritrovato con 3 certificati intestati a me, tutti scaduti o “rotti”).

Sinceramente, mi aspetterei che in futuro:

1. Automatizzassero la gestione dei certificati. (questo fattibile già oggi, se volessero).
2. Abilitassero bridge verso linguaggi interpretati (o pre-compilati in qualche modo) come Python, Ruby o perché no, HTML/CSS/JavaScript. Su Mac OS X già ci sono. (questo credo oggi non fattibile perché C è comunque immensamente più veloce e leggero di un interprete qualunque).

Tornando all’applicazione in sé, Babele ha fatto un ottimo lavoro di taratura nonostante le limitazioni del microfono dell’iPhone che come è ovvio che sia è realizzato per ottimizzare la risposta sulla voce umana – è quello il suo scopo.

Da parte mia grossi problemi non ne ho trovati, alla fine si tratta soltanto del tempo (molto) necessario per scrivere tutto quello che serve in C, andando a capire i vari framework (UIKit primo fra tutti). Dal mio punto di vista molte cose potrebbero essere astratte e sarebbe bello se ci fossero librerie per gestire automaticamente certe cose (come qualche astrazione sulle funzionalità HTTP esistenti). Pian piano queste stanno nascendo ma sono mediamente ad uno stato embrionale: non c’è ancora nulla di solido e affermato.
Una cosa bella sarebbe poi se queste librerie non venissero distribuite come file sorgente ma già pacchettizzatae in framework. Questo putroppo è ancora più raro. :/

Note di rilascio

Il primo rilascio da parte di Apple è stato molto veloce (2gg), poi però per la 2.0 hanno segnalato dei problemi e non ci è stata approvata. Purtroppo quello che succede in questo caso è che i messaggi di risposta di Apple ai motivi sono sempre piuttosto inutili, nonostante qualcuno si prenda sempre la briga di allegare degli screenshot.

Nel nostro caso solo dopo molto tempo (e molti scambi di mail con messaggi copia-incollati e screenshot inutili) abbiamo capito che non era un problema di UI nonostante quanto dicessero i tecnici Apple. Riducendo pian piano le possibilità abbiamo trovato che era un problema dell’algoritmo di encoding base64 e quindi con certe password non riusciva a postare su Twitter. Come potete immaginare, né io né altri avevamo password con i caratteri incriminati, quindi a noi funzionava sempre tutto correttamente.

L’esperienza non è stata delle migliori. Oltretutto se il tecnico avesse risposto alla nostra prima mail con quanto chiedevamo (il log) avremmo risolto nel giro di un giorno, e non di mesi.

Questa sequenza di scambi ci ha permesso però di vedere che, almeno per noi e la nostra app, il ciclo di approvazione sembra essere di una/due settimane, con la comunicazione da parte di Apple inviata il sabato, indipendentemente se le correzioni venivano fatte da noi domenica oppure venerdì (salvo un caso).

Riporto i valori indicativi delle nostre submission:

1. 1.0: inserita il 22 gennaio 2009, approvata il 24 gennaio 2009 (sabato).
2. 2.0: inserita il 18 marzo 2009, rifiutata il 28 marzo 2009 (sabato, alle 23:48) [a].
3. 2.0b: inserita il 29 marzo 2009, rifiutata il 4 aprile 2009 (sabato, alla 1:55).
4. 2.0d: inserita il 6 aprile 2009, rifiutata il 18 aprile 2009 (sabato, alle 3:19).
5. 2.0e: inserita il 8 maggio 2009, approvata il 18 maggio 2009 (lunedì) [b].
6. 2.0.1: inserita il 2 giugno 2009, approvata il 19 giugno 2009 (sabato) [c].

[a] Nota: la 2.0 è stata in sovrapposizione con l’evento di presentazione di iPhone OS 3.0 il 17 marzo.
[b] Nota: l’unica approvazione non fatta un sabato.
[c] Nota: la 2.0.1 è stata a cavallo del WWDC (8-12 giugno) e quindi ha saltato una settimana di approvazione.

Ringraziamenti

I primi ringaziamenti vanno ovviamente alle tre persone che stanno portando avanti l’idea di WideTag: Leandro Agrò, Roberto Ostinelli e David Orban. Un grandissimo ringraziamento anche al co-autore di questo piccolo software, Aaron ‘Babele’ Brancotti. E, mea culpa me ne stavo scordando, un grazie anche a Trinity Dunnit per la grafica steampunk.