Categoría: Programación

Publicado el

La experiencia de desarrollar una App Android en mi tiempo libre

Después de volver de Ecuador en donde estuve trabajando intensamente en un proyecto que me absorbía casi todo el tiempo decidí tomarme un descanso. En ese tiempo pensé en empezar a aprender a desarrollar apps en Android así que me puse a hojear la documentación oficial respecto al diseño y posteriormente empecé a hacer los ejemplitos que había en la documentación técnica. Entonces me dije, ¿por qué no intentas poner en práctica todo lo que vayas aprendiendo en una aplicación que tenga una utilidad real?, y así es como nació Peak Hour.

La primera versión era realmente sencilla pero me sirvió por un lado para aprender los conceptos básicos de Android (Activities, ciclo de vida de las mismas, tantear el IDE que por entonces decidí empezar con Eclipse aunque poco después migré a Android Studio, notificaciones, etc) y por otro tantear el mercado de apps y concretamente la de gestión de Pico y Placa y transporte en general. Estuve jugando con el código un par de meses o tres y para principios de 2015 ya tenía algo que más o menos funcionaba, el problema era que desde que había empezado a trabajar en Planeta Huerto no me quedaba mucho tiempo libre por lo que no fue hasta febrero de 2015 que presenté la app a mis compañeros de Ecuador.

La primera sensación fue decepcionante, a pesar que cuando estuve en Ecuador era muy cotidiano preguntarse entre los compañeros a quién le tocaba Pico y Placa, cuando se la envié a la gente de allí casi nadie la instaló, creo que no les parecía muy útil y eso me hizo replantearme si valía la pena seguir mejorándola. Después de este chasco la tuve medio abandonada durante unos cuantos meses, 5 o 6, en los que sólo hice un par de arreglos y poco más. En esos meses aproveché para hacer un par de cursos MOOC que me ayudaron mucho a entender como está diseñado Android, aprender muchísimo sobre todo de los patrones de diseño que utiliza el sistema, y detectar los problemas que tenía mi app y ver los errores que había cometido durante mi primer abordaje. Ahí es cuando dije, vamos a hacerlo un poco mejor y así también afianzas las cosas que has aprendido en los cursos. También me planteé que si quiero que la app sea utilizada masivamente tiene que ser más flexible y soportar las reglas de más ciudades a parte de Quito y así es como surgieró la versión 0.2 en las que se añadió el soporte multi-vehículo y la versión 0.3 en la que rediseñé completamente el manejo de reglas para que fuera muy sencillo añadir nuevas ciudades.

Estos dos cambios han resultado ser fundamentales, a partir de ese momento empezamos a crecer horizontalmente o lo que es lo mismo, se empezó a utilizar la aplicación en muchos otros sitios como Colombia, Brasil, Bolivia o Costa Rica, pero sobre todo en Colombia que es actualmente el mercado principal de la app. Es muy gratificante pensar que algo que tu has creado le está siendo útil a casi 300 personas, y eso es lo que te impulsa a seguir adelante. Ya os digo yo que por el dinero no es, de momento la app da para tomarse un poleo al mes y poco más, pero saber que toda esa gente no olvida su Pico y Placa y que seguramente se ha salvado de alguna multa gracias a la app, la verdad es que te alegra el día.

 

¿Y qué pasará con la app en el futuro?, pues de momento tengo planificados un par de cambios que ya tengo medio implementados y dependiendo de como vaya la cosa y si tengo tiempo hay muchas ideas en una libreta que parece que va siendo hora de ir sacándolas.

 

Ya os iré contando.

Publicado el

Cómo nunca debería diseñarse una aplicación Android

He liberado el código fuente de Peak Hour 0.1 y lo pongo como ejemplo de cómo nunca debería diseñarse una aplicación Android. Para la versión 0.2 se rediseñó completamente la app pero eso ya lo veremos cuando vaya liberando las siguientes versiones.

La licencia de Peak Hour es GPL 3, podéis echarle un ojo al código en github. Os animo a que me hagáis preguntas tanto de la parte de diseño como de algún aspecto concreto del código, estaré encantado de responderos.

 

https://youtu.be/JmzYjVeOQ_I

 

Cheli

Publicado el

Instalar App Android en Tarjeta SD Externa

https://youtu.be/TYUg4DkJboE

 

Recordar, los 3 valores posibles son:

 

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:installLocation="preferExternal|auto|internalOnly"
    ... >

preferExternal: Se instalará en la memoria SD externa excepto en el caso que no haya espacio suficiente disponible.

auto: Se instalará en la memoria interna o externa en función de varios factores de configuración de nuestro dispositivo.

internalOnly: Es la opción por defecto. Se indica explícitamente que la aplicación se instalará en la memoria interna.

 

Cheli

Publicado el

97 cosas que todo programador debería saber

Uno de esos maravillosos libros que,  parafraseando el título «Cualquier Programador debería leer». Estas son las 97:

Enlace a la traducción.

  1. Actúa con prudencia, por Seb Rose
  2. Adueñate (y Refactoriza) la compilación, por Steve Berczuk
  3. Antes de Refactorizar, por Rajith Attapattu
  4. Aplica los principios de la programación funcional, por Edward Garson
  5. Aprende a decir “Hola, Mundo”, por Thomas Guest
  6. Aprende a hacer estimaciones, por Giovanni Asproni
  7. Aprende un lenguaje extranjero, por Klaus Marquardt
  8. Aprende a usar las herramientas de línea de comandos, por Carroll Robinson
  9. Aprendiendo continuamente, por Clint Shank
  10. Automatiza el estándar de codificación, por Filip van Laenen
  11. Averigua qué haría el usuario (tú no eres el usuario), por Giles Colborne
  12. La belleza está en la simplicidad, por Jørn Ølmheim
  13. El camino al mejor rendimiento está lleno de sucias bombas de código, por Kirk Pepperdine
  14. Codificando con la razón, por Yechiel Kimchi
  15. Codifica en el lenguaje del dominio, por Dan North
  16. Codificación Ubuntu para tus amigos, por Aslam Khan
  17. El código es diseño, por Ryan Brush
  18. Comenta sólo lo que el código no dice, por Kevlin Henney
  19. Un comentario acerca de los comentarios, por Cal Evans
  20. ¿Cómo usar un Gestor de Errores?, por Matt Doar
  21. Conoce bien más de dos lenguajes de programación, por Russel Winder
  22. Conoce tu próximo Commit, por Dan Bergh Johnsson
  23. Conoce tu IDE, por Heinz Kabutz
  24. Conoce tus límites, por Greg Colvin
  25. La conveniencia no es una -bilidad, por Gregor Hohpe
  26. Cuando Programadores y Testers colaboran, por Janet Gregory
  27. Ten cuidado al compartir, por Udi Dahan
  28. Cumple tus ambiciones con Software Libre, por Richard Monson-Haefel
  29. Los grandes datos interconectados pertenecen a una base de datos, por Diomidis Spinellis
  30. Deja que tu proyecto hable por sí mismo, por Daniel Lindner
  31. El diseño del código sí importa, por Steve Freeman
  32. Distingue excepciones de Negocio de las excepciones Técnicas, por Dan Bergh Johnsson
  33. Dos cabezas son a menudo mejores que una, por Adrian Wible
  34. Dos fallos pueden hacer un acierto (y es difícil de arreglar), por Allan Kelly
  35. Lenguajes Específicos del Dominio (DSL), por Michael Hunger
  36. El mito del Gurú, por Ryan Brush
  37. El Programador Profesional, por Uncle Bob
  38. El trabajo duro no paga, por Olve Maudal
  39. Encapsula Comportamiento, no sólo Estado, por Einar Landre
  40. Escoge tus herramientas con cuidado, por Giovanni Asproni
  41. Escribe código como si tuvieras que mantenerlo por el resto de tu vida, por Yuriy Zubarev
  42. Escribe pequeñas funciones usando ejemplos, por Keith Braithwaite
  43. Escribe las pruebas para las personas, por Gerard Meszaros
  44. Evita errores, por Giles Colborne
  45. Haz lo invisible más visible, por Jon Jagger
  46. Haz mucha práctica deliberada, por Jon Jagger
  47. Las herramientas Unix son tus amigas, por Diomidis Spinellis
  48. Implementa rápido y con frecuencia, por Steve Berczuk
  49. Inicia con un Sí, por Alex Miller
  50. Instalame, por Marcus Baker
  51. Haz las Interfaces fáciles de usar correctamente y difíciles de usar incorrectamente, por Scott Meyers
  52. La comunicación entre procesos afecta el tiempo de respuesta de la aplicación, por Randy Stafford
  53. Lee el código, por Karianne Berg
  54. Lee las humanidades, por Keith Braithwaite
  55. El linker no es un programa mágico, por Walter Bright
  56. La longevidad de las soluciones provisionales, por Klaus Marquardt
  57. Mantén limpia la compilación, por Johannes Brodwall
  58. Mejora el código quitándolo, por Pete Goodliffe
  59. Mensaje al futuro, por Linda Rising
  60. No sólo aprendas el lenguaje, entiende su cultura, por Anders Norås
  61. No claves tu programa en la posición vertical, por Verity Stob
  62. No confíes en el “Aquí sucede la magia”, por AlanGriffiths
  63. ¡No ignores ese error!, por Pete Goodliffe
  64. No seas lindo con tus datos de prueba, por Rod Begbie
  65. No te repitas, por Steve Smith
  66. No tengas miedo de romper cosas, por Mike Lewis
  67. ¡No toques ese código!, por Cal Evans
  68. Los números de punto flotante no son reales, por Chuck Allison
  69. Oportunidades perdidas del Polimorfismo, por Kirk Pepperdine
  70. El paso de mensajes lleva a una mejor escalabilidad en sistemas paralelos, por Russel Winder
  71. Pensando en estados, por Niclas Nilsson
  72. Pon todo bajo Control de Versiones, por Diomidis Spinellis
  73. Da preferencia a tipos de Dominio Específico que los tipos primitivos, por Einar Landre
  74. Preocúpate por el código, por Pete Goodliffe
  75. El Principio de Responsabilidad Única, por Uncle Bob
  76. Programa en pareja y siente el flujo, por Gudny Hauknes, Ann Katrin Gagnat, y Kari Røssland
  77. Prueba el comportamiento requerido, no el comportamiento incidental, por Kevlin Henney
  78. Prueba precisa y concretamente, por Kevlin Henney
  79. Haz pruebas mientras duermes (y los fines de semana), por Rajith Attapattu
  80. Las pruebas son el rigor ingenieril del desarrollo de software, por Neal Ford
  81. Los registros detallados perturbarán tu sueño, por Johannes Brodwall
  82. La Regla Boy Scout, por Uncle Bob
  83. La regla de oro del diseño de API, por Michael Feathers
  84. Reinventa la rueda frecuentemente, por Jason P Sage
  85. Resiste la tentación del patrón Singleton, por Sam Saariste
  86. Retrocede y Automatiza, Automatiza, Automatiza, por Cay Horstmann
  87. Primero revisa tu código antes de buscar culpar a otros, por Allan Kelly
  88. Revisiones de código, por Mattias Karlsson
  89. La Simplicidad viene de la Reducción, por Paul W. Homer
  90. Sólo el código dice la verdad, por Peter Sommerlad
  91. Suelta el ratón y aléjate del teclado, por Cay Horstmann
  92. Noticias raras – Los testers son tus amigos, por Burk Hufnagel
  93. Toma ventaja de las herramientas de análisis de código, por Sarah Mount
  94. Tus clientes no quieren decir lo que dicen, por Nate Jackson
  95. Un binario, por Steve Freeman
  96. Usa el algoritmo y estructura de datos correcto, por JC van Winkel
  97. El WET dispersa los cuellos de botella en el rendimiento, por Kirk Pepperdine

 

Cheli