Los 10 errores más comunes que cometen los desarrolladores de Android: un tutorial de programación

Androide. ¿Qué es lo que no me gusta de esta plataforma? Es gratis, se puede personalizar, está creciendo rápidamente y está disponible no solo en su teléfono o tableta, sino también en su reloj inteligente, televisor y automóvil.

Con la última actualización de Lollipop, la programación de Android sigue mejorando. La plataforma ha madurado bastante desde el lanzamiento inicial de AOSP y ha puesto el listón de las expectativas del usuario bastante alto. ¡Mira lo bien que se ve el nuevo patrón de Material design!

Hay miles de dispositivos diferentes, con diferentes tamaños de pantalla, arquitecturas de chips, configuraciones de hardware y versiones de software. Desafortunadamente, la segmentación es el precio a pagar por la apertura, y hay miles de formas en que su aplicación puede fallar en diferentes dispositivos, incluso como programador avanzado de Android.

Independientemente de una segmentación tan grande, la mayoría de los errores se introducen debido a errores lógicos. ¡Estos errores se previenen fácilmente, siempre y cuando tengamos los conceptos básicos correctos!

Aquí hay un tutorial de programación de Android para abordar los 10 errores más comunes que cometen los desarrolladores de Android.

Error común #1: Desarrollar para iOS

Para mi gran placer, este error de Android es mucho menos común hoy en día (en parte porque los clientes comienzan a darse cuenta de que los días en que Apple establecía todos los estándares de diseño quedaron atrás). Pero aún así, de vez en cuando, vemos una aplicación que es un clon de iOS.

No me malinterpreten, ¡no soy un evangelista de la programación de Android! Respeto cada plataforma que mueve el mundo móvil un paso adelante. Pero estamos en 2014 y los usuarios han estado usando Android durante bastante tiempo y se han acostumbrado a la plataforma. ¡Presionarles los estándares de diseño de iOS es una estrategia terrible!

A menos que haya una muy buena razón para romper las pautas, no lo hagas. (Google hace esto todo el tiempo, pero nunca copiando y pegando).

Estos son algunos de los ejemplos más comunes de este error de Android:

1. No deberías estar haciendo pestañas estáticas, y no pertenecen en la parte inferior (te estoy señalando Instagram).
2. Los iconos de notificación del sistema no deben tener color.
3. Los íconos de aplicaciones no deben colocarse dentro de un rectángulo redondeado (a menos que ese sea su logotipo real, por ejemplo, Facebook).
4. Las pantallas de bienvenida son redundantes más allá de la configuración/introducción inicial. No los utilice en otros escenarios.
5. Las listas no deben tener signos de intercalación.

Estas son solo algunas de las muchas otras pequeñas cosas que pueden arruinar la experiencia del usuario.

Error común n.º 2: desarrollar para su dispositivo Android

A menos que esté creando una aplicación de quiosco/promoción para una sola tableta, es probable que su aplicación de Android no se vea bien en todos los dispositivos. Aquí hay algunos consejos de programación de Android para recordar:

• Los píxeles independientes de la densidad (dp) son diferentes de los píxeles normales (px).
• Los recursos se incluyen varias veces para tener en cuenta las diferentes densidades y orientaciones.
• Los dibujables de 9 parches se estiran para adaptarse a la pantalla.

Hay literalmente miles de escenarios posibles, pero después de un tiempo desarrollas un sentido para cubrirlos todos con un puñado de casos.

¿No tienes miles de dispositivos? No es un problema. El emulador de Android es muy bueno para replicar dispositivos físicos. Aún mejor, pruebe Genymotion, es ultrarrápido y viene con una gran cantidad de diferentes dispositivos preestablecidos populares.

Además, ¿has intentado rotar tu dispositivo? Todo el infierno puede desatarse...

Error común n.º 3: no usar intenciones

Las intenciones son uno de los componentes clave de Android. Es una forma de pasar datos entre diferentes partes de la aplicación o, mejor aún, diferentes aplicaciones en el sistema.

Supongamos que tiene una aplicación de galería que puede compartir un enlace de descarga a algunas imágenes a través de SMS. ¿Cuál de las dos opciones parece más lógica?

Opción 1:

• Solicita el permiso SEND_SMS.

   <uses-permission android:name="android.permission.SEND_SMS" />

• Escriba su propio código para enviar SMS utilizando SmsManager .
• Explique a sus usuarios por qué su aplicación de galería necesita acceso a servicios que pueden costar dinero y por qué tienen que otorgar este permiso para usar su aplicación.

Opcion 2:

• Inicie una intención de SMS y deje que una aplicación diseñada para SMS haga el trabajo

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

En caso de que tenga alguna duda, ¡la mejor solución es la opción 2!

Este enfoque se puede aplicar a casi cualquier cosa. Compartir contenido, tomar fotos, grabar videos, elegir contactos, agregar eventos, abrir enlaces con aplicaciones nativas, etc.

A menos que haya una buena razón para hacer una implementación personalizada (p. ej., una cámara que aplica filtros), siempre use Intents para estos escenarios. Le ahorrará mucho tiempo de programación y eliminará AndroidManifest.xml de permisos innecesarios.

Error común #4: no usar fragmentos

Hace un tiempo en Honeycomb, Android introdujo el concepto de fragmentos . Piense en ellos como bloques de construcción separados con sus propios ciclos de vida (bastante complejos) que existen dentro de una Actividad. Ayudan mucho con la optimización para varias pantallas, su actividad principal los administra fácilmente, se pueden reutilizar, combinar y colocar a voluntad.

Lanzar una actividad separada para cada pantalla de la aplicación es terriblemente ineficiente, ya que el sistema intentará mantenerlos en la memoria el mayor tiempo posible. Matar a uno no liberará los recursos utilizados por los demás.

A menos que desee profundizar en el núcleo de Android y leer este artículo, que aboga contra el uso de fragmentos, debe usar fragmentos siempre que sea posible. Básicamente dice que los fragmentos y los cargadores de cursor tienen un buen propósito previsto, pero una implementación deficiente.

Error común #5: Bloquear el hilo principal

El hilo principal tiene un único propósito: mantener la interfaz de usuario receptiva.

Aunque la ciencia detrás de la medición de la velocidad de fotogramas que nuestros ojos/cerebro pueden percibir es compleja y está influenciada por muchos factores, una regla general es que cualquier cosa por debajo de 24 fps con un retraso superior a 100 ms no se percibirá como suave.

Esto quiere decir que las acciones del usuario tendrán un feedback retrasado, y la app de Android que hayas programado dejará de responder. Despojar al usuario de su control sobre la aplicación genera frustración, los usuarios frustrados tienden a dar comentarios muy negativos.

Peor aún, si el subproceso principal se bloquea durante un tiempo (5 segundos para actividades, 10 para receptores de transmisión), se producirá ANR.

Esto era tan común en Android 2.x, que en las versiones más nuevas, el sistema no le permite realizar llamadas de red en el hilo principal.

Para evitar bloquear el subproceso principal, utilice siempre subprocesos de trabajo/en segundo plano para: 1. llamadas de red 2. carga de mapa de bits 3. procesamiento de imágenes 4. consulta de base de datos 5. lectura/escritura SD

Error común n.º 6: reinventar la rueda

“Está bien, no usaré el hilo principal. Escribiré mi propio código que se comunica con mi servidor en un hilo de fondo”.

¡No! ¡Por favor, no hagas eso! Las llamadas de red, la carga de imágenes, el acceso a la base de datos, el análisis JSON y el inicio de sesión social son las cosas más comunes que hace en su aplicación. No solo la tuya, todas las aplicaciones que existen. Hay una mejor manera. ¿Recuerdas cómo Android ha madurado y crecido como plataforma? Aquí hay una lista rápida de ejemplos:

1. Usa gradle como un sistema de compilación.
2. Use Retrofit / Volley para llamadas de red.
3. Utilice Picasso para la carga de imágenes.
4. Utilice Gson/Jackson para el análisis de JSON.
5. Use implementaciones comunes para el inicio de sesión social.

Si necesita implementar algo, lo más probable es que ya esté escrito, probado y utilizado ampliamente. ¡Haz una investigación básica y lee algunos tutoriales de programación de Android antes de escribir tu propio código!

Error común #7: No asumir el éxito

Genial. Hemos aprendido que hay una mejor manera de manejar tareas de ejecución prolongada y estamos utilizando bibliotecas bien documentadas para ese propósito. Pero el usuario todavía tendrá que esperar. Es inevitable. Los paquetes no se envían, procesan y reciben al instante. Hay un retraso en el viaje de ida y vuelta, hay fallas en la red, los paquetes se pierden y los sueños se destruyen.

Pero todo esto es medible. Las llamadas de red exitosas son mucho más probables que las fallidas. Entonces, ¿por qué esperar la respuesta del servidor antes de manejar la solicitud exitosa? Es infinitamente mejor asumir el éxito y manejar el fracaso. Por lo tanto, cuando a un usuario le gusta una publicación, el recuento de Me gusta aumenta de inmediato y, en el caso improbable de que la llamada falle, se notifica al usuario.

En este mundo moderno se espera una retroalimentación inmediata. A la gente no le gusta esperar. Los niños no quieren sentarse en un salón de clases para obtener conocimientos que tienen una recompensa futura incierta. Las aplicaciones deben adaptarse a la psicología del usuario.

Error común n.º 8: no entender los mapas de bits

¡A los usuarios les encanta el contenido! Especialmente cuando el contenido está bien formateado y se ve bien. Las imágenes, por ejemplo, son un contenido extremadamente agradable, principalmente debido a su propiedad de transmitir mil palabras por imagen. También consumen mucha memoria. ¡Mucha memoria!

Antes de que una imagen se muestre en la pantalla, debe cargarse en la memoria. Dado que los mapas de bits son la forma más común de hacer esto, proporcionaremos una guía de programación de Android para todo el proceso:

Supongamos que desea mostrar una imagen en su pantalla que acaba de tomar con su cámara. La memoria total necesaria para esto se calcula con la siguiente fórmula: memory_needed_in_bytes = 4 * image_width * image_height;

¿Por qué 4? Bueno, la configuración de mapa de bits más común/recomendada es ARGB_8888 . Eso significa que por cada píxel que dibujamos, necesitamos mantener 8 bits (1 byte) para el canal alfa, rojo, greed y azul en la memoria, para mostrarlo correctamente. Hay alternativas, como la configuración RGB_565 que requiere la mitad de la memoria que ARGB_8888 , pero pierde la transparencia y la precisión del color (aunque quizás agregue un tinte verde).

Supongamos que tiene un dispositivo nuevo con pantalla Full HD y cámara de 12 MP. La imagen que acaba de tomar tiene un tamaño de 4000x3000 píxeles y la memoria total necesaria para mostrarla es: 4 bytes * 4000 * 3000 = 48 MB

¿¡48 megabytes de RAM solo para una sola imagen!? ¡Eso es mucho!

Ahora tomemos en consideración la resolución de la pantalla. Está intentando mostrar una imagen de 4000x3000 en una pantalla que tiene 1920x1080 píxeles, en el peor de los casos (mostrar la imagen a pantalla completa) no debe asignar más de 4 * 1920 * 1080 = 8.3 MB de memoria.

Siga siempre los consejos de programación de Android para mostrar mapas de bits de manera eficiente:

1. Mide la vista en la que estás mostrando tus imágenes.
2. Escale/recorte la imagen grande en consecuencia.
3. Muestra solo lo que se puede mostrar.

Error común n.° 9: Usar la jerarquía de vista profunda

Los diseños tienen una presentación XML en Android. Para dibujar contenido, el XML debe analizarse, la pantalla debe medirse y todos los elementos deben colocarse en consecuencia. Es un proceso que requiere recursos y tiempo y que debe optimizarse.

Así es como funciona ListView (y más recientemente RecyclerView).

Si un diseño se ha inflado una vez, el sistema lo reutiliza. Pero aún así, inflar el diseño debe ocurrir en algún momento.

Digamos que quieres hacer una cuadrícula de 3x3 con imágenes. Una forma de hacerlo es un LinearLayout vertical que contiene 3 LinearLayout con el mismo peso, cada uno de ellos con 3 ImageViews con el mismo peso.

¿Qué conseguimos con este enfoque? Una advertencia de que "los pesos anidados son malos para el rendimiento".

Hay un dicho en el mundo de la programación de Android que acabo de inventar: “Con poco esfuerzo se puede aplanar toda la jerarquía” .

En este caso, RelativeLayout o GridLayout reemplazarán de manera eficiente los LinearLayouts anidados.

Error común n.º 10: no establecer minSdkVersion en 14

Bueno, esto no es un error, pero es una mala práctica.

Android 2.x fue un gran hito en el desarrollo de esta plataforma, pero algunas cosas deben dejarse atrás. La compatibilidad con dispositivos más antiguos agrega más complejidad al mantenimiento del código y limita el proceso de desarrollo.

Los números son claros, los usuarios han avanzado, los desarrolladores no deberían quedarse atrás.

Soy consciente de que esto no se aplica a algunos mercados grandes con dispositivos antiguos (p. ej., India), y establecer minSdkVersion en 14, en la aplicación de Facebook, significa dejar a un par de millones de usuarios sin su red social favorita. Pero, si está comenzando de nuevo y está tratando de crear una experiencia hermosa para sus usuarios, considere eliminar el pasado. Los usuarios que no tienen los recursos, o sienten la necesidad de actualizar su dispositivo/SO, no tendrán el incentivo para probar una versión superior de su aplicación de Android y, en última instancia, gastar dinero en ella.

Envolver

Android es una plataforma poderosa que evoluciona rápidamente. Puede que no sea razonable esperar que los usuarios mantengan el ritmo, pero es fundamental que los desarrolladores de Android lo hagan.

Saber que Android no está solo en nuestros teléfonos o tabletas es aún más importante. Está en nuestras muñecas, en nuestras salas de estar, en nuestras cocinas y en nuestros automóviles. Tener los conceptos básicos correctos es de suma importancia antes de comenzar a expandirnos.