Google publicó hace tiempo una guía donde explicaba cómo debían hacerse las aplicaciones para Android de Ice Cream Sandwich en adelante. Es cierto que cada uno puede desarrollar como le venga en gana, o como mejor se adapte al propósito de la aplicación, pero se agradece que el teléfono tenga una armonía en cuanto a la interfaz se refiere. Es verdad que Android es de código abierto y aunque éso pueda suponer un aliciente muy potente, en algunos casos se convierte en un lastre muy pesado.
El desarrollo de aplicaciones intuitivas, simples, sencillas, funcionales y bonitas hace más sencillo el ecosistema tan complicado en que puede tornarse Android ciertas veces. Seguir la hoja de ruta correcta puede conducir a evitar usuarios descontentos y “enfadados”. Desde que escribo sobre Android he visto innumerables bugs y errores de aplicaciones. Y no sólo bugs, sino fallos de planteamiento que se podrían subsanar con un par de retoques simples. Por éso, hemos recopilado los cinco fallos más comunes en las aplicaciones Android y alguna que otra manera de subsanarlos.
1. Parece una app de iOS
Una gran cantidad de desarrolladores quieren portar aplicaciones de iOS a Android y aprovechar el mismo diseño. Un fallo garrafal. Las aplicaciones para Android tienen su propia sensación y toque que las distingue de iOS y demás plataformas. Una cosa que sirve para iOS no siempre sirve en Android. Aparte de que los usuarios suelen darse cuenta y claman al cielo cuando pasa éso.Como ya mencioné antes, Google publicó una guçia de diseño donde explica cómo deben ser las aplicaciones para Android. Es deber de todo desarrollador al menos leer y aprenderse algunas de las reglas que allí se exponen. Y aunque las reglas están hechas para romperse, hay otras maneras mejores que ésta.
2. Poco soporte para multiples dispositivos
¡Ooohh! La palabra prohibida y que tanto odiamos oir. ¡La fragmentación! Dejando a un lado el humor, la fragmentación en Android es un hecho tan real como la vida misma. Y aunque en los últimos tiempos se ha acortado la franja entre versiones, no es el único apartado que ayuda a la fragmentación. La gran variedad de dispositivos acrecienta el problema igual o más.
No es tan difícil. Android ofrece herramientas para poder combatir este problema. Algunas de las soluciones a usar son:
- Usar dp (densidad de píxeles independientes) o layout_weights para el diseño de la interfaz de usuario. Los dp se escalan automáticamente gracias al sistema de diseño para ser (aproximadamente) del mismo tamaño que el tamaño de la pantalla y dpi. Los layout_weights son útiles en regiones que son proporcionalmente las mismas, independientemente del tamaño de la pantalla (por ejemplo, si queremos que el panel de la izquierda ocupe un tercio del ancho de la pantalla en todos los dispositivos). Hay que tener en cuenta que los layout_weights fuerzan las rutinas de diseño para medir repetidamente sus vistas en la pantalla y pueden ser lentos.
- Utilizar los recursos de XML tanto como sea posible según la disposición de la pantallas. Se pueden proporcionar diseños alternativos para diferentes tamaños de pantalla para ser utilizados automáticamente en el tiempo de ejecución.
- Hay que tener cuidado si decidimos bloquear la orientación de la pantalla a vertical solamente. Muchos dispositivos Android con teclados deslizables cambiarán a orientación a horizontal cuando el teclado esté abierto. Si la aplicación se bloquea en portrait puede que el usuario quede descontento.
3. Cargar imágenes demasiados grandes
El manejo de imágenes de gran tamaño en Android es una tarea pendiente. Todavía no se ha encontrado la fórmula que permita cargar imágenes de gran tamaño (o muchas imágenes) sin repercutir en la memoria del terminal. El problema principal es que la cantidad de RAM disponible para los procesos individuales de Android es muy pequeño. El tamaño máximo de almacenamiento dinámico se incrementa cada vez más con cada nuevo dispositivo lanzado pero es difícil predecir si algún día se podrá ejercer sin problema esta acción como en un entorno de escritorio.Algunas soluciones pueden ser:
Asegurarnos de ajustar el callback en los objetos Drawable a null cuando terminemos con ellos.
No hacer imágenes a pantalla completa. Es mejor usar combinaciones de imágenes más pequeñas y un XML dibujable (si es posible).
4. No hay indicación visual al tocar botones
Este problema es fácil de resolver, pero se sufre bastante al verlo. La aplicación debe informar al usuario de que hay un botón presionado. Siempre.Android hace que sea fácil proporcionar diferentes estados para los elementos gráficos en la pantalla en función de si están presionados o no. La forma más sencilla de solucionar ésto es crear un StateListDrawable XML con selector de estados.
5. Bloqueando solicitudes en la interfaz
¿Alguna vez has visto una aplicación que se bloquea y deja de responder? ¿Has visto la ventana que dice que una aplicación no responde? Estas pequeñas cosas pueden ocurrir si se bloquea el UI-thread por mucho rato.
Si algo que se ejecute en ese hilo lleva demasiado tiempo (por ejemplo, las solicitudes de red o base de datos), el usuario puede experimentar un episodio de jankiness.
¿Cómo protegerse de ésto? Utilizar AsyncTasks y ThreadPoolExecutors para bloquear las llamadas a los subprocesos de trabajo es una opción. Cuando nuestras tareas en segundo plano se completen, podemos utilizar callbacks o ventanas con mensajes para enseñar los resultados del proceso en cuestión.
En general, son bastantes las aplicaciones que tienen alguno o varios de los fallos que aquí se detallan. Es importante tener en cuenta todos ellos. Y aunque me he quedado un poco por la superficie de los problemas, espero que el artículo ayude a mejorar el funcionamiento y la interfaz de alguna de las aplicaciones existentes o futuras.
Fuente: Venture Beat
via El Androide Libre
Comentarios
Publicar un comentario