La aplicación era pequeña y se trataba de una migración forzada de un desarrollo que ya había hecho para Windows Mobile y que, debido a que ya es imposible encontrar móviles con Windows Mobile, hubo que hacer su equivalente para Android, de modo que esta fue mi primera aplicación para Android, al margen del clásico Hello World y el Been there, Done that! del Teach Yourself Android Application Development in 24 Hours.
Lecciones aprendidas
Pues bien, resulta que para Android se desarrolla con Java pero no tiene nada que ver con las aplicaciones hechas en JavaME ni JavaSE; así que la experiencia previa haciendo MIDlets o aplicaciones de escritorio con Java no me valió de mucho. De modo que casi partí de cero y como tuve mis tropiezos, en pro de evitar tenerlos otra vez, dejo aquí algunas recomendaciones para acortar el proceso de adaptación:
- Desarrolla la aplicación usando un dispositivo real.
- No intentes hacerlo todo con el diseñador porque no siempre se puede, de vez en cuando hay que editar el XML manualmente.
- Aunque la aplicación se vaya a ejecutar en una versión anterior de Android, es recomendable utilizar el diseñador de interfaces de las últimas versiones.
- Intenta sustituir los Web Services y SOAP por REST y JSON.
Ejecuta siempre la aplicación usando un dispositivo real.
Los primeros días perdí horas de espera porque el simulador del SDK de Android es desesperantemente lento, incluso más lento que el de Windows Mobile (que ya es mucho decir), y como al principio se invierte mucho tiempo en hacer y probar pequeños cambios, la espera ocupa un por ciento muy importante del tiempo de desarrollo. Cuando finalmente pude depurar la aplicación directamente en un móvil, concluí que el dinero que pueda costar un móvil con Android se recupera con creces en el tiempo invertido para hacer la aplicación.
No intentes hacerlo todo con el diseñador porque no siempre se puede, de vez en cuando hay que editar el XML manualmente.
Esto es un hecho que me costó asumir pero eso es lo que hay: el diseñador del plugin de Android para Eclipse (ADT) es imperfecto y terminaremos más rápido si modificamos manualmente algunas cosas directamente en el XML que si tratamos de hacer la misma tarea con el diseñador. Un caso típico de esto es reorganizar elementos dentro de la interfaz: es mucho más rápido irse al XML, cortarlo y pegarlo donde quieres, que tratar de hacerlo con el diseñador.
 | |
| El mismo layout visto en el diseñador para Android 3.0 y 2.1 |
El motor del diseñador de versiones más nuevas se mejora continuamente pero los de versiones anteriores parecen que solo son mantenidos, de modo que una misma interfaz puede verse de forma muy dispar si usas una versión del diseñador u otra y, por regla general, se verá mejor en las últimas versiónes del diseñador que en una versión anterior.
Por ejemplo, un layout para una aplicación que se ejecutará en Android 2.1 se parece más al resultado obtenido en un móvil con 2.1 si se visualiza en el diseñador de la versión 3.0 que en el diseñador de la versión 2.1.
Intenta sustituir los Web Services y SOAP por REST y JSON
Al igual que en JavaME, en Android no hay herramientas que faciliten el trabajo con Web Services, de modo que implementar un proxy para consumir un Web Service puede ser una tarea bastante engorrosa. Sin embargo, si se tiene control sobre los servicios y pude implementarse una versión con la que se intercambien datos mediante JSON, vale la pena extender el servicio con esta funcionalidad porque el desarrollo en Android se simplificará muchísimo. Baste decir que ni en Teach Yourself Android Application Development in 24 Hours ni en Android Wireless Application Development dedican ni un solo apartado a SOAP y las comunicaciones con Servicios Web y, en su lugar, cada vez que se trata el tema de comunicarse con un servicio de datos siempre lo hacen con interfaces REST y aunque se toca el tema del parseado de XML devuelto por algún servicio me quedó bastante claro que si está en nuestras manos probablemente sea mucho más fácil adaptar los servicios para consumirlos por REST e intercambiar datos en JSON, que desarrollar un cliente en Android que consuma el Web Service con SOAP como medio de intercambio.
¿Y entonces qué?
Pues, al final y a pesar de los contratiempos por ser un novato, desarrollar para Android fue muy divertido. Aunque las herramientas de desarrollo aún tienen sus pequeños detalles de estabilidad están muy completas y me han dejado claro por qué Microsoft ha tenido que lanzar a coste cero una edición de Visual Studio para desarrollar para Windows Phone. Por otra parte, al margen de los IDEs, hay que decir que el SDK de Android está muy bien concebido con lo que hacer una aplicación multiidioma y que se adapte bien a dispositivos con distintas dimensiones es más simple y coherente que en JavaME o Windows Mobile.
¿Entonces?... ¡Bienvenido, Android!
Totalmente de acuerdo contigo en todos los aspectos, de mi experiencia que es igual de corta, puedo decir que probar los desarrollos sobre un movil real se hace indispensable sobre todo, si como fue mi caso, debes usar rasgos que son tipicos de los moviles actuales (entiendase GPS, Sensores como el de orientacion y el acelerometro, entre otros) que son extremadamente dificiles de simular por el emulador, aunque me consta que existen algunos intentos por hacerlo. Mi idea es que para ser un buen desarrollador debes poder empatizar con el rol del usuario y esto no lo logras sino es probando la app directamente en el movil y viendo que falla y que es mejorable. Respecto al tema de los diseñadores, he escuchado de alguna otra aplicacion de ayuda en el diseño de la interfaz como www.droiddraw.org aunque hasta ahora no lo he probado y me ha tocado como a ti, meter mano en el XML. Incluso veo el tema de diseño de la interfaz un poco mas automatizable, o sea, me parece que se tarda mucho en definir un control en el XML y tenerlo operativo en JAVA para realizar acciones. Creo que vendria bien una generacion de codigo un poco mas inteligente por parte del entorno en este caso. De todas formas esta tarea la tengo marcada en el TODO.
ResponderEliminar¡Felicidades campeón! ¡Vas a millón!
ResponderEliminarje,je,je muy bueno el artículo, recien veo tu blog, ando metido con libgdx(liberia opengl, para hacer games 2d y 3d para android) ahora mismo y haciendo mis primeras cosas para android, leo tu blog y me parece escucharte hablar con los artículos que he leído, muy bueno
ResponderEliminar@neounanue, gracias dobles: por el comentario y porque el dato de ligtgdx. No conocía nada parecido y ahora que le he dado un vistazo estoy convencido de que sería una muy buena base para hacer cosas con algunos efectos gráficos interesantes. A @JulioEnrique le habría venido muy bien esta librería en un proyecto "doméstico" que estuvo haciendo hace un tiempo.
ResponderEliminar¿Qué puedes contarnos de tu experiencia con libgdx: curva de aprendizaje, velocidad de desarrollo, ventajas respecto a otras librerías?
Hola que tal, deberías contar más tu experiencia con web services, he estado investigando y para versiones actuales de android se complica más la conexión a dichos servicios, por ejemplo yo sigo atorado ahí y no e encontrado información que resuelva mi problema, es muy poca la información, nadie muestra un tutorial desde como hacer el web services ya sea con soap o rest como montarlo con iis, tomcat,cassini, etc.Y finalmente como consumirlo, si se necesitan async task, proxy en el emulador de android y todas esas cuestiones técnicas que parecen no tener mucha importancia pero que al final por esos pequeños detalles no funciona la aplicación, espero encontrar mi solución para publicar mi trabajo, saludos
ResponderEliminarLa verdad es que hace tiempo tengo pendiente escribir más sobre el tema porque aunque REST "parezca" ser la opción más lógica (porque es con la que se ilustra la mayoría de las veces los ejemplos de consumo de servicios en Android) SOAP no es una tecnología para dejar de lado porque en el entorno empresarial está -y seguirá estando- muy afianzada.
Eliminar¡Muchas gracias por tu sugerencia!