Come accennato nel precedente articolo, uno dei più grossi problemi di cui soffre Android è quello della frammentazione, argomento questo che meritava di essere approfondito, in particolare dal punto di vista tecnico.
Senza entrare troppo nei dettagli, una buona base di partenza per comprendere il concetto è rappresentata dalla finestra che si apre quando si decide di creare (o modificare) una nuova macchina virtuale (Android Virtual Device, abbreviato con AVD) sulla quale far girare il nostro codice:
All’apparenza non ci sono molte voci, ma le tre più importanti (Target, Skin, e Hardware) sono sufficienti a complicarci la vita, presentando numerose opzioni / possibilità. La più importante, che abbiamo già avuto modo di conoscere, è la prima, che consente di specificare quale versione delle API (nel gergo di Android, “API Level“) vogliamo utilizzare:
Chi volesse scrivere un’applicazione per Android 1.0 e 1.1 (API Level 1 e 2, rispettivamente) rimarrà deluso: non è, infatti, possibile selezionare l’apposita versione delle API, per cui Android 1.5 rappresenterà necessariamente il requisito minimo.
A parte gli scherzi (chi volesse, potrebbe sempre procurarsi le precedenti versioni dell’SDK), il nocciolo della questione si presenta subito e rappresenta la classica domanda che un programmatore si pone quando deve iniziare un nuovo progetto: quale versione scegliere?
La risposta è scontata: dipende dagli obiettivi che ci si pone. Per cui un programmatore scanzonato e che non deve dar conto a nessuno, se non a se stesso, potrà decidere di smanettare con ciò che vuole.
Un professionista che ha ricevuto un progetto da portare avanti (con tanto di famigerata scadenza) non può permettersi tutta questa flessibilità (e nemmeno ce l’ha: alla fine non è certo lui a scegliere il target), per cui andrà in primis a controllare la situazione del mercato:
Tolti di mezzo i tablet (che hanno sostanzialmente un mercato a sé), la situazione è abbastanza chiara: si possono eliminare tutte le API Level fino alla 6, inclusa la 9 che è stata una meteora sparita velocemente, ma non si possono ignorare la 7 (13% è una fetta consistente di utenza ancora attiva, nonché potenziale cliente), 8 e 10.
La scelta di un’API rimane un’operazione molto dolorosa, da qualunque punto di vista la si veda. Da quello del produttore, perché tagliare equivale a dover fare a meno di quote di mercato. Da quello del programmatore, che vorrebbe utilizzare nuove API che gli semplificano la vita e si vede costretto a ripiegare su quello che offre quel particolare SDK.
Un esempio di quest’ultimo è rappresentato da Froyo (Android 2.2 / API Level) 8, che ha introdotto una nuova libreria / framework (Stagefright) per la gestione del multimedia (sebbene ci sia qualche problema, in quanto non risulta abilitata in tutti i dispositivi che montano questa versione): se ne dovrà fare a meno, continuando a sbattersi con la precedente soluzione (OpenCore, che non gode di particolare stima dagli addetti ai lavori).
La stabilità delle API, citata nel precedente articolo, dipende anche da questo: fornire a chi sviluppa strumenti che non cambiano troppo e troppo velocemente nel tempo. La buona fattura è anch’essa importante, ed è incomprensibile che, per fare un esempio veramente grossolano, soltanto da Android 3.0 (API Level 11) sia possibile cambiare da XML l’alpha channel (opacità / trasparenza) di un widget, costringendo quindi a ricorrere al solito, verboso da morire, codice Java…
Anche la grafica riveste un ruolo fondamentale, tant’è che le moderne applicazioni mobile tendono a essere particolarmente curate da questo punto di vista. Molto tempo viene speso soltanto per raggiungere quest’obiettivo (non particolarmente gradito ai programmatori, che tante volte devono improvvisarsi “designer”; ruolo che non è certo il loro), tenendo anche conto delle diverse risoluzioni esistenti per gli schermi in dotazione.
La gestione della grafica, intesa sia come disposizione dei widget nello schermo che come immagini a corredo dell’applicazione, è abbastanza complessa ed esula dagli scopi di quest’articolo. In maniera estremamente semplice e a puro titolo divulgativo, possiamo dire che Android prevede alcune tipologie di asset di riferimento dalle quali recuperare ciò che serve in base all’effettiva risoluzione del dispositivo corrente.
Sempre tralasciando il discorso dei tablet, per i telefonini sono previsti 3 tipi di asset: ldpi, mdpi, hdpi. Il primo rappresenta il riferimento per gli schermi 240×320, il secondo per quelli 320×480, mentre l’ultimo 480×800. In linea teorica sarebbe possibile mettere a disposizione un solo asset, lasciando poi il compito ad Android di scalare opportunamente le immagini per lo schermo di destinazione.
Praticamente questa strada è assolutamente consigliata per diverse ragioni. La prima è che gli aspect ratio risultano abbastanza diversi fra di loro (0,75, 0,67, e 0,6 rispettivamente), per cui il processo di adattamento introdurrebbe di fatto delle aberrazioni visive che possono risultare fastidiose. Soprattutto al collega grafico, particolarmente attento a che il suo lavoro non venga giustamente snaturato, che potrebbe quindi anelare al vostro scalpo.
Il secondo è rappresentato dalla qualità del risultato finale: un’immagine pensata per la 240×320 risulterebbe troppo sgranata a 480×800 a causa della mancanza di dettagli dovuta alla più bassa risoluzione. Una pensata per la 480×800 sarebbe povera di dettagli e un po’ pasticciata a causa della necessità di dover tagliare buona parte dell’informazione e scegliere un campione più o meno rappresentativo di quella originale.
La realtà risulta, però, ben diversa, e i dispositivi non si limitano a quelle 3 risoluzioni, com’è possibile vedere dalla voce “Skin” citata all’inizio dell’articolo:
A complicare ulteriormente le cose, a seconda dell’API Level è presente il supporto a determinate risoluzioni oppure. Ad esempio l’API Level 3 prevede le seguenti:
Mentre la 13 soltanto questa (ma ricordiamo che è riservata ai tablet):
Fortunatamente Android mette a disposizione uno strumento per cercare di adattare la grafica a seconda della risoluzione: le 9-patch. In sintesi, si tratta di immagini realizzate secondo un preciso schema che consente di definire quali parti delle medesime devono rimanere rigorosamente invariate (per non deformare la grafica) e quali possono essere “allungate” (replicate, per la precisione) per riempire lo spazio a disposizione. L’esempio presente alla fine del link vale più di mille parole.
Si tratta di un’idea semplice e geniale, sicuramente molto utile, ma che ha pure i suoi limiti (la pietra filosofale in informatica non è stata ancora inventata). Innanzitutto le parti fisse possono risultare troppo grandi su display piccoli (es: bordi troppo spessi, che mangiano troppo spazio), oppure troppo piccole su display grandi (es: bordi troppo esili e di difficile individuazione).
A parte questo, le 9-patch possono essere impiegate soltanto laddove sia necessario riempire lo sfondo (background) di un widget, quale potrebbe essere un bottone o una casella di testo, ad esempio. Non è, però, possibile ricorrervi nel caso di immagini con precisi disegni (stelline, lenti d’ingrandimento, frecce, ecc., ma anche loghi), che non possono certo essere “stirati” (vedi collega grafico di cui sopra).
Brevemente, l’ultima voce, Hardware, permette di specificare un insieme di caratteristiche da un nutrito elenco per il dispositivo da emulare:
Va sottolineata la differenza rispetto alle altre due: laddove si trattava di una singola scelta fra un insieme, qui si tratta di scegliere un insieme di caratteristiche fra tutte quelle a disposizione, il che fa letteralmente esplodere il numero di combinazioni possibili e i relativi test necessari a carico degli sviluppatori (anche se nessuno sano di mente si metterebbe a testare proprio tutte le combinazioni, ma solo quelle più “plausibili” o in ogni caso “comuni”).
Ci sono, poi, due diverse valutazioni da fare, che possono sembrare complementari, ma che in realtà sono legate e “compenetranti”. La prima è che se un’applicazione ha bisogno di rilevare le coordinate geografiche, il dispositivo dovrà necessariamente mettere a disposizione hardware adeguato allo scopo (GPS, AGPS, o una combinazione dei due). Poco male: è ovvio che l’applicazione non girerà in mancanza, e che quindi si perderà una parte del mercato per forza di cose, perché non si può certo modificare il target.
Per contro, l’assenza di una caratteristica può determinare scelte anche molto diverse, e influisce sicuramente sulla creatività e la possibilità di sperimentare tirando fuori un prodotto innovativo. E’ anche facile intuire il perché: se, ad esempio, il “GPS” non è in dotazione a tutti, si tenderà a toglierlo di mezzo per arrivare a un minimo comune denominatore che consenta di abbracciare il più ampio market share.
Il risultato netto è che sarebbe sostanzialmente inutile perdere tempo cercando di capire come sfruttare strumenti come questi, perché non fanno parte delle caratteristiche di “base”, standard, della piattaforma, e pertanto disponibili ovunque.
E’ scontato che questa libertà di scelta di cosa inserire o meno in un dispositivo si traduca in un mercato più variegato e in grado di coprire fasce molto ampie, dalle più economiche ma scarne, alle più costose ma ben carrozzate. Ma è anche vero che l’assenza di un minimo comune denominatore sufficiente ampio (ricco?) può minare la qualità dei prodotti finali fruibili dall’utenza, per quanto detto sopra.
Infine se, nonostante tutta questa disquisizione, non ci si fosse ancora convinti della (notevole) frammentazione di questa piattaforma mobile, riusciranno forse le recenti dichiarazioni di Rubin & soci riguardo alla prossima versione di Android, Ice Cream Sandwich:
…and it’s putting a stop to Android fragmentation…
There’s nothing worse than your friends having a more recent Android version than what you have, and thus getting cool new features. Google said they want “one OS that runs everywhere.” They’re going to do this by adapting the framework and adding new APIs “to help developers optimize for all various devices.”
Personalmente mi sfugge come si possa arginarla introducendo nuove API. Inoltre un’altra grande pecca di Android è che i dispositivi non sono tutti aggiornati all’ultima versione; anzi, a volte non è proprio possibile farlo. Ed è proprio questo il motivo per cui si cerca, al solito, il livello minimo delle API. Magari sarà un mio limite, per cui aspetto chiarimenti in merito, ma al momento la situazione rimane tutt’altro che rosea…
P.S. Sicuramente salterà all’occhio la mancata citazione dei layout relativi, che aiutano nella disposizione dei widget a seconda delle diverse risoluzioni. Non sono un’esclusiva di Android, per cui non aveva senso parlarne; al contrario delle 9-patch.
… e poi ci sono anche i “tablet” cinesi che fingono di essere smartphone esponendo una risoluzione “fake”. Per non parlare delle personalizzazioni OEM, come quelle di Samsung, che spesso e volentieri includono un set di codec audio/video leggermente diverso da quello standard e quindi anche eventuali applicazioni che sfruttano uno streaming multimediale (con corrispondente applicazione lato server) devono essere pensati a dovere…
Il compatibility package cerca di risolvere questo problema, non va bene per tutte le esigenze ma non è male..
Il compatibility package cerca di risolvere questo problema, non va bene per tutte le esigenze ma non è male. Poi io considero solo dal 2.1 in avanti, i possessori dei tablet cinesi si adattino..
Beh se si è sopravvisuti alla frammentazione dei pc windows non vedo perchè non si dovrebbe sopravvivere a questa.
L’alternativa è il metodo apple, ovvero un device ogni tot anni e una pianificazione rigidissima ad opera di una singola azienda. Praticamente il modello sovietico e sappiamo tutti che il modello del bazaar ( quello capitalistico ) ha vinto.
La situazione non mi sembra cosi drammatica anche vista la concorrenza.
Anche iphone ormai, per motivi fisiologici, inizia a sentire una certa frammentazione avendo 3 telefoni e svariati modelli di ipod touch con caratteristiche tecniche e dotazioni hw diverse. Anche li il modello con la base di istallato maggiore (il 3g) non può contare su api aggiornate dato è stato lasciato a una vecchia versione di ios. Inoltre viene lasciato molto meno spazio alla libertà di utilizzo delle funzioni hw del telefono e del sistema da parte degli sviluppatori (cosa che per gli utenti ha qualche pro e molti contro).
Mentre Win phone è stato un flop pur avendo una base praticamente identica su tutti i telefoni (è riuscito a vendere meno di bada). Oggi i telefoni con questo os sono nella fascia media per caratteristiche tecniche e non hanno telefoni di fascia alta ne di fascia bassa che unito ha un ecosistema (e un sistema) immaturo non riescono ad attrarre il pubblico.
Secondo me a voi sfugge il fattore commerciale di questa rapida evoluzione del livello API.
Son stati geniali (commercialmente) a proporre tutte queste rapide evoluzioni in soli 3 anni di prodotti: il ricambio c’è stato e i manufacturer hanno gioito di questa politica adottando sempre più device android, i quali, prontamente dopo pochi mesi dal lancio venivano lasciate obsoleti..
puro marketing
cmq benvento nel mondo android Cesare: vedrai che col tempo ti ci abitui :D
Io onestamente non capisco perchè tutte queste paranoie per la (presunta) frammentazione di Android.
Volete un sistema non frammentato ? C’è iOS… Con i costi che ne consegue, e con le limitazioni del caso (nessuna possibilità di avere una tastiera se non con accessori after market…).
I PC sono sopravvissuti tranquillamente con HW frammentati. E’ vero a volte con i driver si diventa pazzi, ma almeno hai delle possibilità che sistemi più chiusi (vedi i Mac) non hanno (tante scemenze USB riesco a farle funzionare solo su W$).
L’articolo l’ho trovato interessante, ma ritengo che il titolo non gli faccia giustizia. Più che di frammentazione, parla delle evoluzioni delle API, e di come i programmatori devono “arrabbattarsi” per convivere con queste evoluzioni.
Personalmente ritengo che la “paura” della frammentazione nasca più dalla difficoltà di seguire un mercato “isterico”, che da un problema oggettivo.
L’articolo parla della frammentazione (lo dicono gli stessi progettisti della piattaforma!), perché esiste e bisogna, purtroppo, conviverci. Non si può certo ignorarla, per lo meno un professionista non può farlo.
Il paragone con Windows, più volte citato, non regge, perché le API sono abbastanza stabili, e in genere è possibile effettuare gli aggiornamenti.
Vero è che si tratta di piattaforme chiuse, ma non interessa né al programmatore né tanto meno all’utente finale (che vuole semplicemente utilizzare lo smartphone o il tablet senza necessariamente sapere cosa c’è sotto la “scocca”).
@Antonio: grazie per le informazioni. :)
@Albe: il compatibility package è una pezza che aggiunge anche confusione, nella misura in cui, ad esempio, non consente di utilizzare attributi introdotti nelle API level successive a quelle selezionate per il progetto.
Inoltre è tutta roba in più che deve trascinarsi nell’applicazione. Mentre le API standard sono, ovviamente, già a disposizione.
Infine, non vedo cosa ci sia di male nei tablet cinesi, se soddisfano le specifiche della piattaforma. Android non è forse “libero”?
@valentino: iOS non è certo paragonabile ad Android quanto a frammentazione. C’è, ma decisamente ridotta. Inoltre tutti i telefoni si possono aggiornare alla versione 4, e soltanto con la 5 verrà a mancare questa possibilità con quelli più vecchi.
Windows Phone 7 è un flop nelle vendite, ma per il resto è una piattaforma molto ben progettata (a cui manca, purtroppo, un parco applicativo consistente). L’articolo, comunque, verteva principalmente su questioni tecniche, non su marketing e vendite.
@imayoda: dopo aver assaggiato la Nutella è molto, molto difficile abituarsi ad altro. ;-;
Ottima disamina per uno sviluppatore
Inoltre lo sviluppatore deve scegliere oltre a risoluzione e api level anche la piattaforma
android fino ad adesso ha supportato la piattaforma arm
Ma se si produce software per android bisognerà anche fare i conti con la x86 di intel
@massimo: con x86 non ci sono grossi problemi, perchè tutto il software è interpretato e le NDK compilano automaticamente per ARM e/o x86 in base a qualche flag di configurazione. Bisogna essere veramente poco avveduti ad inserire codice Assembly dentro il codice compilato con NDK, che sarebbe poi l’unico modo per rompere la compatibilità tra le varie architetture.
Da incompetente, convengo che forse la frammentazione cominci ad essere eccessiva ma, un minimo di livellamento sui requisiti hardware minimi già esiste (RAM ad esempio), probabilmente nel futuro si andrà verso una maggiore standardizzazione ad esempio nei display, credo che nel giro di un paio d’anni avremo solo 2 o 3 risoluzioni tipo qHD, HD (su quest’ultima credo andrà a convergere anche apple con prossime release di iOS) e 480×800 per i low cost; anche perché il numero di produttori “importanti” andrà a diminuire, con fusioni e acquisti tipo motorola-google, fino a rimanere al massimo 3 o 4 multinazionali a spartirsi il 90 % del mercato e, in quel momento sarà più semplice “standardizzare”
@Cesare
definisci meglio Nutella ahahah
Su qualche commento ho letto che iOS comincia a soffrire di frammentazione, bhè questo lo può dire solo un fan-droid non certo un programmatore.
Prima di tutto, tutti i device sono aggiornabili ad iOS4 (solo la prima generazione ha subito qualche taglio a qualche features che non comporta particolari problemi al progarmmatore).
Le statistiche parlano di un 90-95% circa di device aggiornati al 4.x, le API non hanno mai subito cambiamenti “radicali” (al massimo aggiunte), la frammentazione hardware che influenza il codice è minima ed è solo su particolari questioni che entrano nelle dita di una mano (risoluzione, giroscopio, opengles, camera\flash, altro?) e sono ampiamente gestibili con un effort minimo di codice e testabili con al più 3 devices.
Pensa se invece di google ci fosse stata la comunità linux: invece di quelle poche centinaia di combinazioni ne avresti viste come minimo 100000 e tutte basate su facezie del tipo “forko perchè Pippo ha detto che mi scaccolo con le cuffiette degli auricolari… Non è vero: lo faccio con l’antenna”.
Alla fine da tutto sto marasma si capisce solo una cosa: che symbian ha perso solo per colpe sue (o per meglio dire, di nokia) e non per meriti altrui…
@Shin_Shishi: non ritengo plausibile l’uso di schermi HD o simili su dispositivi che hanno schermi che arrivano al più a 4″.
Con l’iPhone 4 e il suo retina display abbiamo già sfondato il tetto dei 300dpi, che sono un valore impressionante ed elevatissimo che ci permette di visualizzare immagini molto definite.
Considerato l’uso che se ne fa, va benissimo così. Le prossime innovazioni saranno rappresentate da schermi con colori sempre più reali, e il famigerato 3D che è sempre dietro l’angolo.
Chiuso OT.
@imayoda: meglio di no. C’è già abbastanza carne al fuoco adesso. :P
@Dany: totalmente d’accordo.
Dimenticavo di aggiungere un ulteriore fattore di frammentazione: le Google API.
Per ogni Android API Level esiste la corrispondente Google Inc. API, che comprende i servizi del cloud (Gmail, Maps, Docs, Contacts, Market). La maggioranza dei device a basso costo non è dotata di queste API (perchè non sono open source come Android, ma si pagano le royalties a Google) quindi bisogna considerare l’eventualità, ad esempio prevedere dei codepath alternativi nel caso non siano presenti tali API.
Quindi, ad esempio, può essere carino integrare un programma con Google Calendar, Contacts, ecc… ma bisogna anche prevedere la loro assenza nel sistema perchè moltissimi device ne sono sprovvisti.
E’ vero che in molti casi si riesce ad installare il Market e il resto del Google framework, ma si tratta di procedure non ufficialmente supportate e che potrebbero invalidare la garanzia (tramite rooting del dispositivo). In definitiva non si tratta di procedure alla portata di tutti, ma bisogna essere smanettoni.
Soprattutto penso non sia legale, perché Google ne detiene come minimo il copyright, essendo tutta roba sua.
Comunque nelle immagini che ho allegato sono ben visibili le Google API, ma non ho voluto includerle nel “conteggio” e nel discorso della frammentazione, perché proprio perché si tratta di un “di più”, anche se sono ufficialmente supportate nell’SDK. Ci sarebbero anche le API Level di altri produttori, che aumentano ulteriormente il numero.
Alla fine ho optato per non citarle (ma tanto sono visibili; per chi vuol vedere), poiché ritengo già sufficiente la presenza di ben 13 API, e inoltre per evitare banali accuse come quelle di voler cercare il pelo nell’uovo che avrebbero inquinato more solito l’argomento.
“Chi volesse scrivere un’applicazione per Android 1.0 e 1.1 (API Level 1 e 2, rispettivamente) rimarrà deluso: non è, infatti, possibile selezionare l’apposita versione delle API, per cui Android 1.5 rappresenterà necessariamente il requisito minimo”
BHe dai visto che nono esistono in commercio terminali con versioni precedenti di android alla 1.5 ci può stare :D Il primo è stato l’htc G1 ma poi aggiornato ad android 1.5. Il magic (secondo terminale) è uscito subito cn questa versione, poi aggiornato a 1.6 e quasi tutti hanno ricevuto addirittura froyo (tranne quelli di alcuni operatori come il magic di tim in teoria fermo ancora a cupcake).
Scherzi a parte :) Capisco la questione dal punto di vista dello sviluppatore ed effettivamente un “problema” c’è! ma a me sembra cmq un “falso” problema, alla fine non sembra così insormontabile la cosa e sono più i benefici portati da questa frammentazione che gli inconvenienti!
Sicuramente bisognerebbe avere terminali il più aggiornati possibile e pretendere API “migliori”, più stabili!
Ma la situazione non mi sembra ugualmente così tragica. A me pare una situazione molto simile a quella di windows! se uno si compra un terminale di fascia bassa senza acceleratore grafico o gps (anche se nn mi risultano terminali android senza gps) poi non può pretendere di far girare le stesse applicazioni che vanno su un galaxy s2! così come chi compra un un computer con grafica intel integrata non pretendere di giocare come chi ha una scheda at/nvidia di ultima generazione!
@Antonio Barba
Sicuro che si “paghi la licenza” per le google apps! Io sapevo che google richiedeva solo che i terminali avessero determinate caratteristiche per potevi accedere (la presenza del modulo telefonico) ma non costavano niente!
Quali sarebbero questi moltissimi device sprovvisti di google apps? sta cosa mi suona nuova!
Come già detto, il paragone con Windows non regge proprio, perché ha delle API molto stabili. E non si può mischiare il discorso delle API con quello dell’hardware, che sono due cose ben separate (come ho esplicitato nell’articolo).
Mi sfugge poi come potrebbero addirittura esserci dei benefici da questa frammentazione, peraltro citata dagli stessi progettisti che hanno già pensato a una possibile soluzione (o pezza; il “compatibility package”) e sembra ne stiano tirando fuori un’altra con la prossima versione di Android.
Comunque da sviluppatore che ha avuto modo di lavoraci, vorrei sapere da te quali vantaggi ci sarebbero, perché io vedo solo problemi. E non sto nemmeno citando le altre piattaforme per confronto, perché voglio mantenere il discorso esclusivamente su Android.
Insomma, vorrei sapere da sviluppatore cosa c’è di bello in questa frammentazione.
P.S. Quella su Android 1.0 e 1.1 era una battuta. Stigmatizzata poi giusto nella riga successiva. ;)
@zephyr83: giusto ieri guardavo i tablet della Olivetti e della Mediacom, che non hanno il Market e le altre applicazioni Google. Dispositivi come questi sono veramente tantissimi, quasi tutti sulla prima fascia di prezzo.
@Cesare E l’NDK? Che mi sai dire sull’NDK?
@Antonio Barba
Come dicevo google per il market (e quindi penso anche per le google apps) richiede che i dispositivi abbiano il modulo umts (o quello telefonico proprio, nn ricordo bene)! questa è l’unica richiesta ma non ho mai letto di royalty da pagare! anche google ha sempre sostenuto che è gratuito ma non posso metterci la mano sul fuoco per questo ti ho chiesto se hai qualche dettaglio in più!
In ogni caso le google apps con tanto di market si possono mettere lo stesso dopo “volendo” :)
@Cesare Di Mauro
Non so se ai tempi di windows 95 c’erano tutte ste gran API stabili :)
Cmq parlavo di vantaggio in senso generale! La frammentazione hardware ha portato alla diffusione della piattaforma facendo contenti i vari produttori! Il vantaggio per lo sviluppatore è un bacino di utenza vastissimo e non mi pare sia poca da cosa! Certo ho detto anche io che ci vorrebbero API migliori e che i produttori dovrebbero impegnarsi di più con gli aggiornamenti (anche se alla fine la situazione non è così tragica), ma la frammentazione di tipo hardware ha portato più vantaggi in generale che svantaggi!
Sicuramente per uno sviluppatore sarebbe meglio poter sviluppare su un’unica piattaforma, usare un solo linguaggio di programmazione magari a vita e avere a disposizione miliardi di potenziali “clienti” facoltosi! :D Però la soluzione definitiva e migliore per tutti non esiste :)
@zephyr83: stando a questo documento http://source.android.com/faqs.html#what-kinds-of-devices-can-be-android-compatible
a partire da android 2.1 non è più richiesta la presenza di hardware di telefonia (quindi il modulo UMTS/GSM è obbligatorio solo con Android 1.6 e precedenti).
Inoltre, nello stesso documento, si legge che la procedura di verifica della compatibilità è gratuita, ma bisogna contattarli privatamente per ottenere la licenza di Android Market (che include anche tutta la base software delle Google API’s).
Sui costi non saprei dirti con precisione, ricordo di alcuni articoli che ne parlavano, qualche anno fa, ma non ricordo i dettagli.
@Antonio Barba
Grazie per le info, sarebbe da approfondire meglio la cosa (per curiosità) ma meglio farlo altrove se capita che poi andiamo troppo OT :)
Continui a non voler rispondere e a mischiare la diffusione di un prodotto con la frammentazione che si porta dietro a livello di sviluppo.
A questo punto è chiaro che o non hai mai sviluppato su Android, oppure lo devi difendere per una questione prettamente ideologica su un FATTO che è ben noto e conclamato dagli stessi progettisti (almeno loro dovrebbero sapere di quali mali soffre la loro creatura, no?).
P.S. Le Win32 esistono dai tempi di Windows NT, per cui prima del ’95, e… ci sono ancora.
Comunque ribadisco che l’argomento della discussione è la frammentazione di Android dal punto di vista di uno sviluppatore.
Fine OT.
@javaboy: l’NDK non l’ho mai usato, e me ne guardo bene. Come ho già detto, lo sviluppo è ben più rognoso, ci sono dei bug, e la documentazione è scarsa. Inoltre devi passare sempre dalla JVM, perché devi esporre la tua funzione / entry point usando le JNI, per poi venire “consumata” dall’applicazione Java (che fa sostanzialmente da launcher).
@Cesare Di Mauro?
??? eh??? nn mi pare proprio di aver sostenuto quello che dici tu! e nn mi pare di aver detto che nn ci sn problemi per gli sviluppatori. anche nel tuo articolo precede auspicavo API migliori per Android! il mio discorso sembrava chiaro ma va beh….
Beh, per me non lo era. Felice di sapere che la pensi così.
@Cesare
allora aspetto un articolo ad hoc.. mi raccomando; ci tengo molto al tuo parere soggettivo :)
Passerà ancora parecchio tempo, perché devo continuare a farmi le ossa con Android, e poi vorrei fare lo stesso con iOS.
Vorrei, insomma, essere nelle migliori condizioni per esporre il mio pensiero riguardo alle maggiori piattaforme mobile.
@antonio: mi confermi la tua fonte:
“perchè tutto il software è interpretato e le NDK compilano automaticamente per ARM e/o x86 in base a qualche flag di configurazione. “?
Nelle mio prove con c & ndk sembra che il progetto debba essere ricompilato specificatamente per quell’architettura
Il codice Java viene ricompilato dalla 2.2
@massimo: il codice Java è JIT-compiled dalla 2.2, ma sul device, quindi dal punto di vista del programmatore è come se fosse interpretato (non devi produrre object file per N architetture).
Il codice NDK, se installi sia l’NDK x86 che quello ARM, puoi compilarlo nelle due versioni soltanto settando un flag nel manifest. Trovi tutto nella documentazione dell’SDK.
cito dalla documentazione:
Quindi il codice viene compilato (se il programmatore lo desidera) in tutte le architetture supportate, senza alcuna modifica. Logicamente un programmatore accorto non inserirà pezzi di Assembly inline nel suo codice, e se lo fa sicuramente includerà anche un codepath di fallback in C/C++ delimitandolo opportunamente tramite compilazione condizionale (però a quel punto arrivo io e lo massacro di mazzate sulle gengive).
Mah..
Non sono uno sviluppatore Android, ma sinceramente non capisco tutti questi articoli di Cesare su famigerati problemi di frammentazione, stabilità delle API, “stupidità” degli ingegneri di Google su alcune scelte progettuali (vedi precedente articolo di Cesare, che si è appena affacciato ad Android ma si ritiene più competente dell’intero team di Google…), critiche su come chiamano le classi (“R” non ti piace, l’alias delle costanti pure…) ecc.
Innanzitutto, per quanto riguarda la “stabilità” delle API, Google dichiara chiaramente (http://developer.android.com/guide/appendix/api-levels.html) che:
” Updates to the framework API are designed so
that the new API remains compatible with earlier
versions of the API. ”
In pratica alle API vengono (ovviamente) aggiunte nuove funzionalità senza rompere la compatibilità con i livelli precedenti. Non capisco dove stiano i problemi di stabilità delle API di cui parli.. è quello che accade in qualsiasi sistema che venga mantenuto aggiornato, non esistono altre possibilità.
Google ha deciso di farti scegliere il livello a priori e non rendere disponibile l’app a chi non rispetta il requisito minimo (stesso discorso se il dispositivo non monta l’hardware richiesto).
L’alternativa è darti a disposizione tutto e poi delegare al programmatore la verifica che ogni chiamata alle API abbia successo o meno (a seconda del livello API disponibile e dell’hardware presente) creando ovviamente più difficoltà di sviluppo, possibilità di bug o comportamenti non previsti o che l’applicazioni risulti inutilizzabile.
Per quanto riguarda tutti i problemi relativi alle diverse risoluzioni, dispositivi hardware presenti o meno, quantità di RAM, ecc., esistevano altre soluzioni? (ricordando che i dispositivi fisici sono prodotti e distribuiti da altre aziende, quindi per forza il sistema dev’essere aperto e personalizzabile)
Windows “puro” (a livello di sdk win32) non fa praticamente nulla, non è neanche in grado di ridimensionare una TextBox quando ridimensioni il contenitore, e delega tutto allo sviluppatore (o al framework utilizzato); mentre i vari framework “moderni” offrono soluzioni più o meno comode, a volte non al livello di quelle presenti in Android (bella la finezza delle 9-patch!)
Concludo ricordando che in qualsiasi sistema informativo c’è sempre una scelta che va fatta (anche su PC, su iPhone, su Linux, ecc… presto anche su WP7):
– ti livelli verso il basso e copri una maggior fascia di utenza facendo un prodotto più scadente
– ti livelli verso l’alto, fai un prodotto “top” ma che alcuni utenti non potranno utilizzare a pieno
– fai un prodotto che si adatti a tutti i livelli e sistemi, investendoci sopra molto più tempo e denaro (=> in android puoi sempre rilasciare due versioni dell’app con diverso livello API, dispositivi hardware richiesti, utilizzo di RAM e CPU, ecc.)
Non credo ci sia molto da capire: riporto il frutto della mia esperienza e le mie impressioni. L’alternativa per te quale sarebbe? Magari non scrivere oppure farlo pontificando e tessendo loro su questa piattaforma? Se vuoi sentirti ripetere soltanto che tutto è bello, beh, ci sono siti più adatti. Qui, finché mi verrà concesso questo spazio, continuerò a riportare i miei… “Pensieri da coder”.
Riguardo a stabilità, etc., ho già scritto un articolo, per cui se vuoi continuare a parlarne puoi benissimo farlo là.
Qui si parla di frammentazione, e non mi sembra di aver detto delle assurdità: la situazione è oggettivamente quella esposta. C’è poco da girarci attorno. Se poi fai dei confronti con altre piattaforme, beh, dovresti sapere che la situazione è di gran lunga migliore. Questo lo ribadisco sempre come sviluppatore.
Infine proprio come sviluppatore, se permetti, dopo 29 anni di esperienza non mi ci vuole molto a comprendere la bontà o meno di uno strumento. Ma anche qui, se c’è qualcosa che non ti quadra di quello che ho detto, puoi benissimo farmi vedere dov’è che avrei sbagliato (sempre nell’apposito articolo: qui si parla d’altro), perché mi pare che ci sia troppa facilità a fare i confronti sulla base di “titoli nobiliari”, ma noto “stranamente” delle assenze quando poi si chiede di scendere nello specifico (tecnico) .
P.S. Sulla classe R ricordi male: non ne ho parlato io.
@Cesare
Gli articoli li pubblicate voi, giustamente decidete voi gli argomenti, noi prendiamo ciò che arriva. I pensieri da coder potevano essere inseriti intanto che facevi una mini-giuda tipo “I miei primi passi in Android” o creando direttamente una serie tipo “Sviluppare un gioco in Python” di Mirco Tracolli su AD. Oppure, con più umiltà, criticare altri ambienti o strumenti che conosci bene e su cui lavori da anni…
Il fatto è che non hai capito il problema della “frammentazione di Android”, anche se il titolo dell’articolo è questo.
Ed è per questo che hai scritto:
“Personalmente mi sfugge come si possa arginarla [la frammentazione] introducendo nuove API.”
Tu pensi alla frammentazione HARDWARE, che non è un problema visto che il sistema Android è nato così, anzi è un requisito visto che gli OEM al di fuori devono poter creare dispositivi diversi.
Infatti hai concentrato l’analisi sui livelli delle API e sulle capabilities dell’hardware… che non c’entrano niente con il problema della frammentazione di android.
E’ la frammentazione DI ANDROID STESSO CAUSATO DALLE PERSONALIZZAZIONI DEGLI OEM (Samsung, HTC, LG, Motorola, ecc.) – ovvero le modifiche ai sorgenti propri del sistema operativo, il problema di cui soffre Android; questa frammentazione comporta:
– inesistenza degli aggiornamenti alle ultime versioni (o attesa di mesi nelle migliori ipotesi), perdendo per strada patch di sicurezza, modifiche per la velocità e stabilità del sistema, nuove funzioni, ecc.
– pesantezza del sistema, lag, crash e altri problemi dovuti a programmi scritti non a regola d’arte e spesso “buttati” con fretta sul mercato
– features presenti su alcuni dispositivi e altri no
– programmi di default (anche quelli principali come dialer, rubrica, ecc.) completamente cambiati, a volte sostituiti pari, che possono creare problemi con le app esterne che li richiamano o utilizzano
– differenze nell’utilizzo dei terminali che creano qualche grattacapo agli utenti inesperti
e cose di questo tipo.
Questo ti spiega anche perchè Rubin nelle sue dichiarazioni diceva che introducendo nuovi livelli di API avrebbe RIDOTTO la frammentazione: nuove funzioni base utilizzabili da tutti == meno necessità di creare modifiche e personalizzazioni da parte degli OEM.
Se non ricordo male alcune personalizzazioni spinte addirittura Google voleva bandirle del tutto (personalizzi troppo -> il sistema risultate fa schifo come laggosità e stabilità -> io non ti do’ le google apps ne’ accesso al market).. e sono perfettamente d’accordo visto che come utente di CyanogenMod (basata su Android open source originale)+LauncherPro, la velocità di sistema con questa ROM surclassa qualsiasi altro telefono compreso iPhone4, mentre con ROM originale lo stesso telefono era PENOSO.
Sì, c’è sicuramente un’incomprensione di fondo, perché io ho parlato e parlo ANCHE della frammentazione hardware. oltre che della moltitudine di display, e infine delle API. Perché tutto concorre a rendermi la vita più difficile nel momento in cui devo sviluppare un’applicazione, e mi vengono in brividi a pensare su quante configurazioni dell’emulatore e quanti telefonini dovrò testarla per potermi sentire un po’ più tranquillo.
Tutto quello che hai riportato non fa che peggiorare la situazione dal mio punto vista, che ricordo essere quello di uno sviluppatore che deve averci a che fare con tutte queste problematiche, e non ti nascondo che ciò mi porta a un forte senso di disagio e frustrazione.
Perché, possiamo dire quello che vogliamo dei successi che miete sul mercato, ma quando devi sviluppare su Android non puoi infilare la testa sotto la sabbia e pensare soltanto al mercato in termini di percentuali assolute. Devi decidere quali API level utilizzare; quali risoluzioni supportare, e in che modo; di quali caratteristiche hardware hai bisogno.
Non sei su iOS, dove tutti i dispositivi possono essere aggiornati alla versione 4 (l’ULTIMA!), con variazioni praticamente insignificanti nelle API. E non devi pensare per forza a quanti schermi ci sono, perché al limite per le immagini metti la grafica dell’iPhone 4, che è esattamente il quadruplo dei predecessori, e ottieni la massima qualità per quest’ultimo e un’eccellente scaling per gli altri. Non devi nemmeno perdere tempo a vedere quante configurazioni hardware ci sono, e quanta memoria c’è: è tutto già ben noto e con poche variazioni.
Su Android non puoi nemmeno sapere quanta memoria minima è a disposizione (solo da una certa API level c’è specificato un minimo). E ho detto tutto, perché rappresenta la cartina al tornasole di una situazione drammatica per chi deve svilupparci.
Rubin può dire quello che vuole. Può aggiungere altre API perché pensa di risolvere il problema della frammentazione, ma queste novità non te le ritroverai in tutti i telefonini. Già adesso lo stesso compatibility package dà una mano, ma con tutti i limiti invalicabili dovuti al fatto di essere legati mani e piedi a una certa API Level che non puoi “scavalcare”.
Perché il problema è sempre quello: non puoi aggiornare; non hai questa garanzia. Per cui dovrò necessariamente scegliere la 7 perché non posso assolutamente ignorare quella quota di mercato per il business dell’azienda. E quindi continuare a ingollare rospi.
Infine sugli articoli e la rubrica in generale: se ho scelto quel titolo è perché rispecchia esattamente lo scopo per cui è nata. Ed è quello che ho fatto finora. Non ho organizzato corsi di programmazione o sviluppato progetti, pur avendolo potuto fare, perché i miei articoli hanno un taglio molto diverso. I pezzi di codice che ho riportato alcune volte sono stati rari ed esclusivamente funzionali all’argomento trattato.
Qui riporto esperienze e pensieri, appunto, a ruota libera. Non m’interessa nemmeno qualcosa tipo “i miei primi passi”, perché di roba del genere ne trovi pieno il web. Né lo farei per altre piattaforme come Windows Phone 7 (che pur conosco molto meglio) e solo perché mi ci trovo bene.
Né tanto meno ho intenzione di farlo per una sorta di legge di compensazione o di contrappasso, per cui se oggi critico Android domani devo necessariamente farlo con WP7 e pure con iOS. Son cose che personalmente reputo bambinate. Un domani ci saranno certamente articoli anche per altre piattaforme, ma semplicemente perché mi andrà di parlarne, ivi comprese le critiche se ci sarà da criticare (e ce n’è, ce n’è).
Però mettiamoci bene in testa che non scriverò che qualche volta m’è crashato Visual Studio mentre stavo lavorando a un nuovo widget/controllo per Windows Phone 7, soltanto per far contento qualche povero di spirito che non aspetta altro per appagare il suo io e poter dire: “anche gli altri sguazzano nei liquami”. Lo farò all’interno di un quadro programmatico che verte su un ben preciso argomento, perché penso che sia questo il modo di giusto di farlo.
Io mi trovo d’accordo sulla questione delle API e anche leggendo il precedente articolo di certo nn è stato fatto un eccellente lavoro! Spero migliorino la cosa.
Ma per quanto riguarda la frammentazione hardware continuo a pensare che non sia così problematica come cosa e che anzi è servita per diffondere la piattaforma! poi non si tratta di “accontentare” tutti ma di aver a disposizione il maggior numero di utenti! I telefoni con display da 320×240 e/o senza acceleratore sn un numero ridottissimo e piazzati su terminali di fascia bassa! Uno sviluppatore che decide di sviluppare tal programma può benissimo lasciar fuori questa fascia………in ogni caso avrà un bacino di utenza VASTISSIMO! se vuole ANCORA DI PIÙ allora dovrà fare un lavoro ulteriore! Sn scelte, non si può venire in contro a tutto e tutti!
Riguardo iOs certamente la situazione è molto più facile per lo sviluppatore ma ad esempio per i giochi se uno decide di sfruttare l’hardware dell’iphone4 e magari il giroscopio taglia fuori tutti gli altri device. Inoltre il primo iphone (uscito solo in america) nn ha ricevuto l’ultimo aggiornamento mentre il 3G è stato tagliato fuori dal game center.
In ogni caso la soluzione adottata da Apple è difficilmente replicabile da altri.
Microsoft in parte ci sta provando ma per ora cn scarsissimi risultati di vendita! I produttori continuano a preferire android! Lo sviluppatore avrà vita facile con WP ma se gli utenti rimangono pochi ci fai poco! Grazie a nokia la cosa sicuramente cambierà e a quel punto questo discorso potrebbe rivelarsi un punto a favore di windows phone!
Non è certo un aspetto da sottovalutare questo, basta vedere symbian che in passato era un inferno per i programmatori e aveva pessime API. Nokia ha capito troppo tardi l’importanza di questo aspetto e ne ha pagato le conseguenze (assieme ad altre scelte sbagliate).
@zephyr83
non credo che i terminali con schermi da 3240 x 240 siano poi così rari…dando una scorsa ai listini dei carrier le offerte più economiche (0€ + contratto o 9-10€ con contratto) che immagino essere anche le più diffuse prevedono telefoni con risoluzione QVGA (320X240) o HVGA (480 x 320). Non credo che per uno sviluppatore sia poi così saggio lasciarle perdere.
Sono troppi, e non si possono lasciar perdere. A meno che il progetto non abbia assolutamente bisogno di un display di dimensione almeno medie, ma capita raramente di poter escludere una fascia di mercato così consistente.
@Lorenzo
Invece sono pochi! la maggior parte partono da 320×480! Così come sono pochi quelli senza acceleratore grafico!!!
Cmq a quanto pare c’è chi lascia perdere fasce di mercato ben più consistenti! basta vede Mozilla che per la versione mobile di firefox ha escluso tutti i terminali con processore armv6 che sono molto di più di quelli cn display da 320×240!
Per i giochi discorso diverso, li è normale escludere diverse fasce e mi sembra il minimo!
Io mi chiedo, sinceramente, com’è possibile che un personaggio come Cesare scrive ancora su questo blog. Mi spiego: ad esempio qui c’è chi scrive di Apple. Non è che lì non ci siano flames, ma è diverso: che scrive, è abbastanza chiaro, usa e probabilmente adora i prodotti Apple, e ne parla bene, a volte magari esagerando e prendendosi del fanboy, ma va bene così perchè chi scrive ci spiega il perchè adora quel tal prodotto. C’è anche chi scrive di orizzonti open, magari a volte peccando di eccessivo ottimismo: è forse un crimine? Ne dubito… E poi c’è Cesare, che scrive praticamente solo articoli sul free software e sull’open source, su Linux e su Android, su sistemi che magari nemmeno utilizza, cercando in sostanza di spiegarci il perchè fanno cag@re nonostante tutti i giorni milioni di persone li utilizzino con soddisfazione. L’illustre autore ci scrive di come la situazione non sia “rosea”. A volte, lo fa effettivamente tirando fuori verità scomode, ma diventa chiaro che sia inadatto a farlo quando saltano fuori espressioni come l’indimenticata “bagno di sangue”.
Cesare, scrivi di quanto è superfighissimo Windows, di quanto ti piace l’OS mobile “inserire nome != Android”, ma perchè, PERCHÈ, devi continuare a parlar male di cose che detesti? Per caso con i suoi articoli la mitica Eleonora Presani, anzichè spiegarci cose interessanti, ci illustra il perchè i cattolici sono una massa di bigotti ignoranti e non capiscono un razzo? Non mi pare. Eppure questo è proprio ciò che accade quando a postare è il molto meno mitico Cesare… Che tristezza… :(
@Daniele: io, invece, mi chiedo sinceramente com’è possibile che un personaggio come te si senta leggittimato a venire su questo blog a scrivere commenti come il tuo precedente.
Mi spiego: ad esempio tra questi commenti c’è chi confuta le critiche che Cesare ha mosso alle API di Android. Non è che questi commenti non siano fortemente critici, però almeno chi li scrive lo fa criticando le posizioni espresse nell’articolo, non la persona che sostiene tali posizioni.
E anche se a volte alcune critiche portate peccano di un certo rigore nelle premesse quando partono da posizioni espresse nell’articolo (gli autori danno l’impressione di non aver compreso bene quanto scritto nell’articolo) almeno sono espresse sempre con quel minimo di rispetto che le fa rientrare nella categoria dei modi di esprimersi civili nei confronti di un’altra persona, che non conosci.
Si chiama attacco ad hominem, ed è una ben nota fallacia logica utilizzata da chi preferisce attaccare la persona piuttosto che i fatti e le argomentazioni da quest’ultima esposti (per antipatia, o perché non in grado di sostenerne una discussione).
@Daniele: nessuno ti costringe a leggere questi articoli. Se la cosa ti dà fastidio, posso assicurarti che su internet ci sono tanti posti in cui puoi sentirti ripetere ad libitum quello che ami.
Sì, ma solo uno in cui posso sentirmi ripetere ad libitum che tutto ciò che non è Microsoft (compagnia della quale apprezzo e uso svariati prodotti) fa schifo per partito preso, solo perchè non è Microsoft. Comunque non mi avete risposto: perchè anzichè scrivere bene di ciò che apprezzi e utilizzi perseveri nel parlar male di ciò che disprezzi (e, in alcuni casi, non utilizzi).
Ad ogni modo, la frecciatina con cui supponi che io voglia solo leggere commenti positivi nei confronti di ciò che tu supponi che io amo mi pare un comportamento ancora più fastidioso ed infantile del mio, e mi giustifica. La mia critica è infatti volutamente rivolta al critico, che non reputo all’altezza della situazione, e ai toni che utilizza, ma non al contenuto stesso della critica, come spiegato:
“A volte, lo fa effettivamente tirando fuori verità scomode, ma diventa chiaro che sia inadatto a farlo quando saltano fuori espressioni come l’indimenticata “bagno di sangue”.”
Sono ben disposto ad accettare critiche alle cose che apprezzo, quando queste sono costruttive e non semplici lagne scritte, magari, per ripicca. E, io, sono anche disposto ad accettare le critiche alla mia persona ed ai toni che ho utilizzato. Anche se mi preme far notare a banryu che sostenere che non conosco i “modi di esprimersi civili” è una critica,appunto, alla mia persona, e non alle posizioni che avevo espresso nel mio precedente post.
PS: Lo sfogo arriva in questo articolo per puro caso, e si rivolge alla persona in quanto autore di tutti i propri articoli, e non solo di questo in particolare, pensavo fosse chiaro.
Ecco, allora faresti meglio a dare un’occhiata a tutti i miei articoli: vedrai che ne troverai diversi che non parlano soltanto di critiche, ma di tante cose positive. E, incredibile a dirsi, ne troverai che parlano bene di prodotti non Microsoft, persino open source. Basta semplicemente… cercare.
Per il resto, dovresti spiegare tu che c’azzecca citare i “milioni di persone soddisfatte di Android”, quando l’articolo riporta l’esperienza e le impressioni di uno sviluppatore che è costretto a lavorarci…
@ Cesare Di Mauro : per quel che riguarda gli schermi HD è frutto del marketing, (come anche il retina per iPhone) già adesso il mio TV 46″ dovrei guardarlo da 1,6 metri di distanza per avere la percezione della dimensione di un pixel, figurati che già parlano di 4k e 8k (tenendo conto che oggi un Full HD equivale a 2k).
Imho credo che articoli troppo tecnici dovrebbero essere evitati su AP. Oppure si dovrebbe iniziare a moderare i commenti.
Come è possibile che si debbano leggere continuamente commenti del tipo “Non ho mai programmato in vita mia ma sicuramente l’autore con 30 anni di esperienza sta dicendo una stronzata”?
@Giallu: il problema non sono gli articoli troppo tecnici, il problema sono le persone, l’ego, e l’umiltà.
Sempre a proposito della frammentazione di Android: http://arstechnica.com/gadgets/2012/05/android-fragmentation-one-developer-encounters-3997-devices/