E’ l’obiettivo che si pone Google riguardo alla sua piattaforma mobile, per bocca di quello che possiamo definire a buon titolo il padre di Android: Andy Rubin, che lavora al progetto da quando è nato (circa 8 anni fa, nel 2003).
Per arrivarci la casa di Mountain View ha deciso di centralizzare e tenere saldamente in mano le redini dello sviluppo e deciderne la direzione, com’è stato puntualizzato nello stesso intervento.
Open source (o quasi, come sottolineato tempo fa), quindi, ma senza “bazar” : è l’approccio della “cattedrale” (anche se non molto diffuso in quest’ambito), che personalmente condivido poiché permette, sulla carta, di meglio incanalare le risorse ed evitare eccessive frammentazioni (possibili sempre e comunque, a causa di eventuali fork).
Tutto molto bello, quindi, ma le parole di Rubin non possono che provocare sensazioni strane, qualcosa di unico; un misto di fastidio e ilarità allo stesso tempo, con l’idea martellante che il personaggio in questione stia sicuramente scherzando, che la sua non possa che essere ironia o sarcasmo ben celati, sapientemente miscelati in un discorso di pura promozione del prodotto.
Già, perché tutto si può attribuire ad Android, tranne le qualità sopra citate. Lo sa bene chi ha avuto modo di lavorarci, magari professionalmente (quindi non fermandosi al classico hello world et similia).
La stabilità è stata una chimera fin dall’inizio, con un SDK rilasciato velocemente, ma le cui applicazioni sviluppate smanettandoci (per provare il nuovo sistema) tendevano a non funzionare già con la successiva versione.
In ogni caso il wizard di creazione del progetto è l’immagine della situazione di Android dal punto di vista dello sviluppatore, e non necessita di molte parole:
ben 12 versioni (13, con l’ultimo SDK per Honeycomb 3.2), più altre “varianti”… in soli 8 anni. Da guinness dei primati.
Senza parlare poi delle molteplici configurazioni hardware con cui bisogna avere a che fare. E pensare che c’è gente che ha l’ardire di affermare che il mercato Android non sia frammentato…
Ma non c’è niente di meglio di un eloquentissimo esempio del concetto che hanno di stabilità in casa Android:
FILL_PARENT (renamed MATCH_PARENT in API Level 8 and higher), which means that the view wants to be as big as its parent (minus padding)
Dopo diversi anni e ben 7 versioni qualcuno s’è svegliato e ha deciso di cambiare nome, dall’API level 8, a una delle costanti in assoluto più utilizzate nella definizione dell’aspetto (i famigerati layout) dei componenti dell’interfaccia grafica. Per aggiungere la beffa al danno, il termine risulta persino meno autoesplicativo rispetto al precedente.
“Ottimizzazione” e “bontà” meritano di essere trattate assieme (è proprio Android che ce ne dà la possibilità!), partendo dalla citazione di quella che possiamo considerare la pietra angolare di tutta la piattaforma di sviluppo: la classe View.
Com’è possibile vedere dalla paginetta a essa dedicata, discende direttamente da Object (astrazione? specializzazione? Concetti alieni agli ingegneri di Android) e si fa carico di tantissime responsabilità. Un chiaro esempio di God class, insomma; ovviamente da NON imitare assolutamente.
Un altro spunto sull’argomento lo dà la classe TextView, che dal nome dovrebbe permettere di visualizzare del testo. In effetti è proprio quello che fa, ma spulciando la documentazione salta fuori una caratteristica molto interessante:
Displays text to the user and optionally allows them to edit it. A TextView is a complete text editor, however the basic class is configured to not allow editing; see EditText for a subclass that configures the text view for editing.
Quindi TextView racchiude un intero editor di testo, che non è immediatamente abilitato, mentre la classe EditText si occupa semplicemente di quest’aspetto, come ci conferma dall’apposita paginetta:
EditText is a thin veneer over TextView that configures itself to be editable.
Chi ha sviluppato delle applicazioni dotate di interfaccia grafica, siano esse desktop o mobile, sa che quella di visualizzare delle scritte è di gran lunga l’esigenza più comune. Magari con colori e/o font diversi, più o meno grandi, allineate a destra, sinistra o centro, ma rimangono pur sempre delle scritte immobili, appiccicate sullo schermo.
Su Android, invece, qualunque scritta che dev’essere semplicemente visualizzata… si trascina dietro un intero editor! Il classico cannone usato per sparare a una mosca…
Un’altra operazione molto diffusa è visualizzare dei bottoni, ossia delle aree generalmente rettangolari che mostrano scritte e/o immagini che richiamano alla mente un’azione da svolgere a seguito del tradizionale click sull’oggetto in questione. La classe Button, che si occupa di tutto ciò, ha, però, un sorprendente genitore: TextView.
L’associazione logica sembrerebbe corretta: TextView visualizza un testo, per cui se diventa anche cliccabile abbiamo, di fatto, creato un link (ipertesto), e quindi effettuato la classica quadratura del cerchio.
Sarebbe tutto molto bello se non fosse che i bottoni non devono visualizzare soltanto testo, ma magari delle immagini, con un layout anche più complesso (immagine dentro e testo al centro; oppure immagine a sinistra e testo a destra; o ancora layout che prevedono diversi elementi che concorrono al risultato finale).
Ma a parte questa motivazione, che già di per sé sarebbe sufficiente a comprendere l’errore progettuale, c’è da considerare il fatto che la stessa classe View è un elemento cliccabile, poiché anche questa è una fra le sue tante responsabilità. In pratica View e qualunque suo discendente è, di base, cliccabile alla stregua di un bottone, a prescindere dalla sua effettiva specializzazione (che ne modellerà il comportamento atteso).
Pertanto sarebbe stato sufficiente derivare Button direttamente (sic!) da View per realizzare questo tipo di oggetti, anziché portarsi appresso un editor completo: quando mai un bottone ha pure l’esigenza di editare il testo eventualmente presente al suo interno? Agli sviluppatori di Android l’arduo (perché tale è) compito di convincere della “bontà” e “ottimizzazione” di queste scelte…
Per finire (ma ce ne sarebbero tante cose da dire) riguardo a quest’ultimo argomento, ruotare il display comporta la distruzione e successiva ricreazione dell’activity corrente (per i non addetti ai lavori, si tratta di un’applicazione o parte di essa che interagisce in un preciso momento con l’utente)!
E’ facile immaginare il costo di quest’operazione per un’applicazione che fa uso di layout complessi, magari con dati che sono stati precedentemente scaricati da un server remoto (scenario tutt’altro che insolito, in un mondo sempre più online / cloud).
Sarebbe stato troppo complicato invalidare il display, ed eseguire il ricalcolo (grafico) di tutti gli elementi tenendo conto delle mutate dimensioni dell’area visibile? I programmatori esperti non lasciano nemmeno il beneficio del dubbio…
Mentre per il discorso “bontà” delle API si può tranquillamente chiudere con un’altra chicca:
public int getDisplayId ()
Since: API Level 1Returns the index of this display. This is currently undefined; do not use.
Otto anni e tredici versioni delle API non sono stati sufficienti per definire una buona volta quest’API pubblica…
Per cui mi scuserà il sig. Rubin ma, alla luce di tutto ciò (e di molto altro), le sue affermazioni potrebbero trovare applicazione soltanto in un universo che funzionasse con logica negata. Decenni di ingegneria del software, programmazione a oggetti, ma anche semplice buon senso, impediscono fortemente di condividerle a chi ha un minimo di infarinatura ed esperienza sugli argomenti…
