Fragmentación en Android

guia-basica-programacion-android-6

La fragmentación de Android es la mayor dificultad con la que se encuentran los desarrolladores para lanzar una aplicación al mercado. Android está muy lejos de ser una plataforma unificada, con unos pocos dispositivos tal como sucede con iOS.

Algunos números sobre la fragmentación

Para hacernos una idea de cómo está Android de dividido, podemos ver un caso real de uso. Existen varias empresas que publican aplicaciones muy utilizadas, y recogen más adelante los datos de uso. Una de ellas es OpenSignal, que recientemente ha publicado su último estudio.

Los números son demoledores:

  • 18.796 dispositivos Android diferentes vistos este año, frente a 11.868 el año pasado (un 58% más).
  • Samsung es el fabricante líder destacado con un 43% de los dispositivos. El resto se lo reparten más de 80 fabricantes diferentes.
  • Hay activas 6 versiones diferentes del sistema operativo con un número de usuarios lo bastante importante como para ser ignorado.
  • También hay un número muy elevado de diferentes resoluciones y tamaños de pantalla. Y por supuesto, con diferentes ratios entre el alto y el ancho.

A estos datos hay que añadir diferentes elementos de hardware, como un conjunto de sensores que puede variar de un dispositivo a otro, o un procesador gráfico diferente que hace que los desarrolladores de juegos en OpenGL tengan que cubrirlos todos.

En fin, una pesadilla, que si no controlamos adecuadamente nos puede costar más de un disgusto. No es raro encontrar proyectos en Android en los que tras acabar la primera versión se acaba gastando más tiempo en portar para los diferentes modelos que en la propia primera versión. Puede llegar a ser muy frustrante.

Enfrentándose a la fragmentación

Aunque es una tarea complicada, si seguimos una cierta disciplina en el desarrollo podremos conseguir un buen resultado en un tiempo razonable. Para eso, empezaremos con un par de consideraciones previas.

Trabajar con la fragmentación desde el principio

Crear primero una versión específica para un móvil en concreto y luego portar es un error frecuente. Es habitual caer en la comodidad que supone fijarnos sólo en el dispositivo que tenemos a mano, pero si vamos a sacar nuestra aplicación para un mercado amplio, dejar la fragmentación para el final nos obligará a costosos cambios en nuestro proyecto. Tardaremos más tiempo y cometeremos más errores. Por ejemplo, si no diseñamos nuestras vistas para ser flexibles y adaptarse a varios tamaños de pantalla, las tendremos que rehacer luego. Algo parecido a lo que pasaba con la localización de recursos.

En este sentido, hay una serie de preguntas que podemos hacernos antes de empezar, y que nos ayudarán a tener un mapa del camino.

  • ¿Qué versión del sistema operativo quiero soportar? ¿Sólo móviles recientes, o quiero que mi aplicación funcione para los modelos más antiguos?
  • ¿Quiero soportar sólo móviles, sólo tabletas, o ambos?
  • ¿En qué países quiero publicar mi aplicación? ¿Qué idiomas quiero soportar?

Con la primera pregunta podremos plantearnos qué funcionalidad queremos incluir en nuestra aplicación. Si soportamos versiones antiguas tendremos que elegir entre sacrificar funcionalidad de las nuevas versiones de Android, o sacar diferentes versiones de nuestra aplicación. Mi recomendación personal es la primera opción, a menos que se tengan medios y desarrolladores suficientes para trabajar con dos versiones diferentes del mismo producto.

Con la segunda, tendremos claro cómo tendremos que desarrollar nuestras vistas, sin perder de vista las diferentes versiones de nuestros recursos gráficos. Por último, aparte de la localización de los textos, hay que tener en cuenta que dependiendo del país donde publiquemos nuestra aplicación, habrá móviles más antiguos o más modernos.

Asumir que no se pueden cubrir todos los móviles

Con tanta fragmentación siempre quedarán casos «raros» que no nos merecerá la pena cubrir. Siempre habrá algún modelo que tenga algún problema grabando o reproduciendo el sonido, o ejecutando un determinado formato de vídeo… o cualquier otra posibilidad. El hecho de que Android sea un sistema libre permite que cada fabricante implemente el sistema operativo a su gusto hasta cierto punto, lo que inevitablemente causará que tendremos modelos difíciles de cubrir.

Aquí es imprescindible un buen pragmatismo. Cubrir unos pocos dispositivos que utiliza un número muy reducido de usuarios no es viable, nos llevará más tiempo que cubrir dispositivos comunes. La mejor estrategia consiste en asegurar los dispositivos con más presencia en el mercado en ese momento, lo que a su vez nos ayudará a que gran parte de los demás funcione también. Luego seguiremos refinando nuestra aplicación hasta conseguir una cobertura razonablemente buena -una aplicación bien desarrollada supera fácilmente una cobertura del 80%- .

Con todo esto ya podemos empezar a trabajar. Aunque ya hemos citado alguna técnica útil, las repasaremos ahora en detalle.

  • Nuestras vistas siempre serán flexibles. Nunca utilizaremos valores absolutos para los tamaños en píxeles, y mucho menos un AbsoluteLayout. Todas nuestras medidas serán en píxeles dependientes o dp, y usaremos proporciones y medidas relativas siempre que sea posible.
  • Testearemos nuestras vistas en diferentes tamaños de pantalla. Para no tener que probarlos todos, una buena aproximación consiste en probar un dispositivo de los más grandes, otro de los más pequeños, y uno intermedio.
  • Nos aseguraremos de tener todos los recursos gráficos disponibles para todas las densidades de pantalla, lo que nos facilitará el tener vistas 100% flexibles.
  • Nos aseguraremos de tener los textos separados del código para dar soporte a la internacionalización.
  • Elegiremos la versión del sistema operativo más baja con la que trabajaremos y desarrollaremos sólo con ella si es posible. Si no lo fuese, crearemos diferentes versiones para los diferentes sistemas operativos, aunque cuantos menos sean mejor. A veces encontraremos librerías de terceros que implementan funcionalidades de versiones recientes sin tener que usarlas directamente, es una alternativa interesante a considerar.
  • Inevitablemente testearemos. En el mercado existen empresas dedicadas únicamente a testeo, y con precios bastante razonables podremos conseguir un testeo automático para una amplia gama de dispositivos.
  • Y por último no descartaremos los reportes de error de los usuarios, que inevitablemente nos llegarán. Con ellos seguro que descubriremos detalles que se nos pasaron por alto.

Te interesa:
Cómo eliminar virus en Android
Síguenos en Google News

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Actualidad Blog
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.