Mi primera aplicación Android

En ferebro de este año, en plenos estudios para los exámenes del primer cuatrimestre, me encontraba en el apogeo de una de mis crisis existenciales. Qué hago estudiando esto, estas asignaturas no me motivan, todos los días pasan iguales etc. etc. etc. A mí lo que me gustaba era programar, y pasarme el día entre servlets y JSP, si bien es programar, no era la gran aventura que estaba esperando. Así que me apunte a uno de estos cursos online para aprender a desarrollar para Android. Como las señoras mayores que se pasan el día en el bingo cuando sus hijos han abandonado la casa. Ni que decir tiene que lo dejé. Lo pesado del sistema de evaluación y la falta de guías que indicasen claramente qué es lo que se esperaba me desmotivaron a la mitad de las lecciones.

Captura de pantalla 2014-07-08 00.13.15

Hablando del tema con Rubén, me dijo que la mejor manera de aprender es hacer. Me propuso un proyecto que tenía aparcado, una aplicación Android para un restaurante familiar, y ahí que fui, sabiendo mucho de Java y poco de Android y sus… peculiaridades, por ser benévolo.

En un principio consistía en un cliente muy ligero de Google Cloud Messaging que avisase cuando se publicase en la Web el menú del día, para descargar el PDF en el dispositivo. La primera versión estable, ya disponible en Google Play, permite hacer login con Facebook y Google+, ver dentro de la aplicación el menú del día, los menús especiales (en fechas señaladas), la carta (con navegación por pestañas combinadas con el NavigationDrawer al estilo de Google Play, Google Play Music…), los horarios de apertura y cierre, saber si en este momento el local está abierto y hasta qué hora (o si está cerrado y cuándo abre) y escoger qué eventos quieres que te notifique la aplicación. Y lo que falta por llegar en futuras actualizaciones.

Ahora toca descansar el cerebro unos pocos días. Calmar los nervios de la puesta en producción, apartar de la mente las imágenes de los clientes encontrándose Forzar Cierre por todas partes y asumir que por muchas pruebas que se hagan, algún fallo siempre se cuela. Echar la vista atrás para ver qué he aprendido, y coger carrerilla para lo que queda por aprender.

Estos meses he aprendido que…

  • JSON para intercambiar datos es sencillo y limpio. Las API REST, también.
  • El orden de las sentencias altera el producto si de versiones de Android hablamos. Algo que funciona perfectamente bien en KitKat puede ser un desastre sin precedentes en Jelly Bean simplemente porque dos sentencias están en el orden opuesto.
  • Google debería dar datos de uso de versión de Android no solo globales, sino regionales. Puede ser un factor determinante a la hora de enfocar el desarrollo, de poco me sirve saber que en el mundo versiones anteriores a Ice Cream Sandwich tienen un 14% de cuota si en mi país esa cuota se eleva al 30, 40 o 50%.
  • El manifest se va relajando con el tiempo. Lo descubrí tras tirar una tarde en conseguir que las notificaciones de Google Cloud Messaging que sí funcionaban en Jelly Bean y KitKat funcionasen en Ice Cream Sandwich.
  • Eclipse es malo. No hay vuelta de hoja. No hay defensa posible. Terminar dominándolo es más una cuestión de práctica a la hora de apagar incendios, pero siempre se te quemarán unos cuántos árboles al hacer según qué tareas.
  • Si no te gusta el comportamiento o apariencia de algo, hereda y sobreescribe.
  • Facebook no piensa en las aplicaciones de sus desarrolladores. Facebook solo piensa en sí mismo. Si no te gusta el botón de stock, o buscas librerías de terceros o pasas por el aro.
  • Actualiza el SDK cuando no tengas nada importante que hacer. La superclase de esto es: si funciona, no lo toques.
  • El proceso de diseño es mucho más iterativo de lo que te da la sensación en los proyectos de la Universidad. Ningún trabajo de los hechos allí ha tenido, ni de lejos, una carga parecida a esta. Revisitar el mismo código una y otra vez añadiendo, quitando, documentando y acortando. Revisitar los mismos layouts con distintas resoluciones de pantalla centrando, moviendo, volviendo a mover, cambiando los colores, cambiando los márgenes, cambiando los tamaños de letra…
  • Los diagramas de clases, y, en general, UML, están bien una vez tienes escrito el código. Sirven de mapa de cara a conocerlo. Pero empezar por un diagrama muy detallado puede hacer que el código sea menos flexible a cambios… o que te toque cambiar mil veces el diagrama. La superclase de esto es: diseña – programa – rediseña. Modifica el dibujo. No te cases con nada.
  • Los detalles son importantes. Bueno, eso ya lo sabía. Lo que no sabía es qué cantidad ingente de cosas son susceptibles de convertirse en un detalle importante. Incluso a qué nivel de despliegue del NavigationDrawer tiene que aparecer y desaparecer un icono. Incluso la palabra con la que indicas que el local está cerrado. Incluso la relación de tamaños del precio de un producto respecto a su nombre. Incluso el orden en una carta de las raciones respecto a las hamburguesas y los platos combinados.
  • No te ocupes tú mismo de nada que no sea estrictamente necesario (a no ser que lo hagas por diversión). Las probabilidades de que mucha gente antes que tú se haya topado con el mismo problema… y haya hecho una librería y la haya subido a GitHub son muy altas.
  • De StackOverflow mana todo el conocimiento. Al principio, es la Biblia. Con el tiempo, cada vez tendrás que consultarlo menos. Pero no te independizarás nunca. Y eso es bueno, porque…
  • …se aprende haciendo. Es la manera más rápida, creativa y dura. Y nunca dejarás de aprender.

2 comentarios en “Mi primera aplicación Android

    • Muchas gracias, Raz. Para mí es importante el reconocimiento de uno de los programadores TOP que conozco. Por cierto, para saber cómo distribuir más o menos mi aplicación, me fijé en el Scrobbler de Last.fm que tienes en GitHub :)

Deja un comentario