La fragmentació d'Android és la major dificultat amb què es troben els desenvolupadors per llançar una aplicació a l'mercat. Android està molt lluny de ser una plataforma unificada, amb uns pocs dispositius tal com succeeix amb iOS.
Alguns números sobre la fragmentació
Per fer-nos una idea de com està Android de dividit, podem veure un cas real dús. Hi ha diverses empreses que publiquen aplicacions molt utilitzades, i recullen més endavant les dades dús. Una és OpenSignal, que recentment ha publicat el seu darrer estudi.
Els números són demolidors:
- 18.796 dispositius Android diferents vistos aquest any, davant 11.868 l'any passat (un 58% més).
- Samsung és el fabricant líder destacat amb un 43% dels dispositius. La resta se'l reparteixen més de 80 fabricants diferents.
- Hi ha actives 6 versions diferents de sistema operatiu amb un nombre d'usuaris prou important com per ser ignorat.
- També hi ha un nombre molt elevat de diferents resolucions i mides de pantalla. I per descomptat, amb diferents ràtios entre l'alt i l'ample.
A aquestes dades cal afegir diferents elements de maquinari, com un conjunt de sensors que pot variar d'un dispositiu a un altre, o un processador gràfic diferent que fa que els desenvolupadors de jocs en OpenGL hagin de cobrir-los tots.
En fi, un malson, que si no controlem adequadament ens pot costar més d'un disgust. No és estrany trobar projectes en Android en els quals després d'acabar la primera versió s'acaba gastant més temps a portar per als diferents models que en la pròpia primera versió. Pot arribar a ser molt frustrant.
Enfrontant-se a la fragmentació
Tot i que és una tasca complicada, si seguim una certa disciplina en el desenvolupament podrem aconseguir un bon resultat en un temps raonable. Per això, començarem amb un parell de consideracions prèvies.
Treballar amb la fragmentació des del principi
Crear primer una versió específica per a un mòbil en concret i després portar és un error freqüent. És habitual caure en la comoditat que suposa fixar-nos només en el dispositiu que tenim a mà, però si anem a treure la nostra aplicació per a un mercat ampli, deixar la fragmentació per al final ens obligarà a costosos canvis en el nostre projecte. Trigarem més temps i cometrem més errors. Per exemple, si no dissenyem les nostres vistes per ser flexibles i adaptar-se a diverses mides de pantalla, les haurem de refer després. Una cosa semblant al que passava amb la localització de recursos.
En aquest sentit, hi ha una sèrie de preguntes que ens podem fer abans de començar, i que ens ajudaran a tenir un mapa de camí.
- Quina versió de sistema operatiu vull suportar? ¿Només mòbils recents, o vull que el meu aplicació funcioni per als models més antics?
- ¿Vull suportar només mòbils, només pastilles, o tots dos?
- En quins països vull publicar la meva aplicació? Quins idiomes vull suportar?
Amb la primera pregunta podrem plantejar-nos què funcionalitat volem incloure en la nostra aplicació. Si suportem versions antigues haurem de triar entre sacrificar funcionalitat de les noves versions d'Android, o treure diferents versions de la nostra aplicació. La meva recomanació personal és la primera opció, llevat que es tinguin mitjans i desenvolupadors suficients per treballar amb dues versions diferents de el mateix producte.
Amb la segona, tindrem clar com haurem de desenvolupar les nostres vistes, sense perdre de vista les diferents versions dels nostres recursos gràfics. Finalment, a part de la localització dels textos, cal tenir en compte que depenent de el país on publiquem la nostra aplicació, hi haurà mòbils més antics o més moderns.
Assumir que no es poden cobrir tots els mòbils
Amb tanta fragmentació sempre quedaran casos «rars» que no ens valdrà la pena cobrir. Sempre hi haurà algun model que tingui algun problema gravant o reproduint el so, o executant un determinat format de vídeo ... o qualsevol altra possibilitat. El fet que Android sigui un sistema lliure permet que cada fabricant implementi el sistema operatiu al seu gust fins a cert punt, el que inevitablement causarà que tindrem models difícils de cobrir.
Aquí és imprescindible un bon pragmatisme. Cobrir uns pocs dispositius que utilitza un nombre molt reduït d'usuaris no és viable, ens portarà més temps que cobrir dispositius comuns. La millor estratègia consisteix a assegurar els dispositius amb més presència al mercat en aquest moment, el que al seu torn ens ajudarà a que gran part dels altres funcioni també. Després seguirem refinant la nostra aplicació fins aconseguir una cobertura raonablement bona -una aplicació ben desenvolupada supera fàcilment una coberta de el 80% -.
Amb tot això ja podem començar a treballar. Tot i que ja hem citat alguna tècnica útil, les repassarem ara en detall.
- Les nostres vistes sempre seran flexibles. Mai utilitzarem valors absoluts per les mides en píxels, i molt menys un AbsoluteLayout. Totes les nostres mesures seran en píxels dependents o dp, i farem servir proporcions i mesures relatives sempre que sigui possible.
- Testearemos les nostres vistes en diferents mides de pantalla. Per no haver de provar-los tots, una bona aproximació consisteix en provar un dispositiu dels més grans, un altre dels més petits, i un intermedi.
- Ens assegurarem tenir tots els recursos gràfics disponibles per a totes les densitats de pantalla, el que ens facilitarà el tenir vistes 100% flexibles.
- Ens assegurarem tenir els textos separats de el codi per donar suport a la internacionalització.
- Triarem la versió de sistema operatiu més baixa amb la qual treballarem i desenvoluparem només amb ella si és possible. Si no ho fos, crearem diferents versions per als diferents sistemes operatius, encara que com menys siguin millor. De vegades trobarem llibreries de tercers que implementen funcionalitats de versions recents sense haver de fer-les servir directament, és una alternativa interessant a considerar.
- Inevitablement testearemos. Al mercat hi ha empreses dedicades únicament a testeig, i amb preus bastant raonables podrem aconseguir un testeig automàtic per a una àmplia gamma de dispositius.
- I finalment no descartarem els informes d'error dels usuaris, que inevitablement ens arribaran. Amb ells segur que descobrirem detalls que se'ns van passar per alt.
