Skip to main content

Mi primera aplicación para Android


English version

Después de varios meses de largas sesiones escribiendo código en casa después del trabajo (reconozco que también tomando más bebidas energéticas de lo recomendable), por fin terminé y he publicado la versión 1.0 de mi primera aplicación para teléfonos Android.


Mi motivación

El primer motivo que se le suele venir a la gente a la cabeza para hacer cualquier cosa es el dinero, pero en este caso esa no es la razón.
Dudo mucho que esta aplicación me convierta en millonario, de hecho, de momento me está costando dinero, aunque para ser sincero, he tenido que invertir muy poco efectivo de momento.

Gracias a las aplicaciones de código abierto y a la standarización de la computación en la nube, el dinero no es un obstáculo para crear y publicar una aplicación (de hecho, puede que algún día dedique una entrada en este mismo blog a este tema).
Lo que se necesita es ciertas habilidades técnicas pero lo más importante es perseverancia y ganas de aprender y experimentar.

Así que mi motivación era simple: necesitaba un reto.

Permitidme aclarar que mi trabajo diario en la oficina como programador de aplicaciones back-end me proporciona cantidad de retos, pero necesitaba un reto fuera de la oficina.

Hay a quien le da por empezar a entrenarse para correr una maratón, pero en vez de eso, yo decidí desarrollar una aplicación para Android.

Pensé que me ayudaría a mejorar como programador, y ciertamente así está sucediendo.

Cada decisión que tomo (ya sea de diseño o de implementación), cada nueva API que tengo que usar, cada modelo de datos que creo y también cada error que cometo, forma parte de un enriquecedor proceso de aprendizaje.


Entonces, ¿en qué consiste la aplicación? 
La aplicación permite compartir décimos de la Lotería Nacional, en este vídeo lo explico detalladamente: vídeo
La idea se me ocurrió escuchando como mi padre llamaba por teléfono cada Navidad a sus hermanos que viven en distintas ciudades para decirles que quería compartir con ellos la mitad de un décimo (10 euros actualmente) para el sorteo de El Gordo. Entonces mi tío, al otro lado del hilo teléfonico, tenía que apuntar el número y el importe de la "participación" que mi padre le estaba dando en una hoja de papel. A cambio mi tío compartía la mitad de un décimo para el mismo sorteo, comprado por él, con mi padre, y en este caso, mi padre es el que apuntaba el número en un papel.

Pensé que este sistema "analógico" tenía bastantes inconvenientes:
- Los papeles con el número apuntado son fáciles de perder
- El día del sorteo se ha de comprobar manualmente y uno a uno si los números han sido agraciados.

Me di cuenta que una aplicación podría hacer todo este proceso mucho más sencillo y fiable.
La aplicación ya está disponible en la Play Store, así que si quieres, instálatela en tu teléfono Android (lo siento pero no hay versión para iPhone de momento), es totalmente gratuita y no contiene publicidad.

Características técnicas
Cuando comenté la idea de crear una aplicación para Android con algunos compañeros, me recomendaron utilizar Firebase.
Me dijeron que permite crear aplicaciones de manera rápida y sencilla, que no se basa en el tradicional paradigma cliente/servidor y que reduce la complejidad al proporcionar una abstracción de los detalles relacionados con la sincronización de los datos.
La verdad que suena muy bien, y seguramente le daré una oportunidad en el futuro, pero quería realizar mi primera aplicación a la manera "tradicional", y Firebase ni siquiera permite el uso de SQL.

Quería demostarme a mí mismo que la misma tecnología que uso diariamente para desarrollar aplicaciones financieras que corren en enormes servidores, podía ser utilizada también para aplicaciones que corren en pequeños dispositivos móviles.

Además de esto, si me hubiese decidido por utilizar Firebase, mi aplicación sería altamente dependiente de esta tecnología.
Pienso que es mejor utilizar tecnologías de código abierto que no te atan a un proveedor específico.

Y aún más, el caso es que Android utiliza una base de datos embebida de tipo SQLite, por lo tanto, si tengo que usar necesariamente SQL en el cliente, ¿por qué no usar SQL en el servidor también?

Así que éstas son los principales componentes y librerías utilizadas en la aplicación:


Pues esto es todo lo que quería contar en mi primera entrada del blog en español, aún me quedan muchas cosas que contar, así que espero seguir escribiendo regularmente.

Comments

Popular posts from this blog

Kafka + WebSockets + Angular: event-driven microservices all the way to the frontend

In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client

A Java dev journey to full-stack: first chapter

The Motivation I am an experienced Java developer and (surprise!) I like Java. I know it is not perfect but it works just fine for me (I enjoy type-safety and I do not consider verbosity a disadvantage, quite the opposite). I also know that some people dislike Java, which is also fine. But recently I decided to step out of my confort zone as developer, my goal isn't to be one of the "cool kids" neither trying to monetize a new skill in the job market. I have a quite practical motivation: I want to be able to build more (different) stuff. That's exactly the same reason why I learnt Android development by myself a couple of years ago. Web applications are ubiquitous, even more than native mobile apps, and thanks to cloud computing, one can easily and inexpensively release their idea/app to the World Wide Web. I already did some Web development in the past, in the bad old days of JSP and JSF, but the process was slow and painful. Nowadays the Web landscape h

Using Apache Kafka to implement event-driven microservices

When talking about microservices architecture, most people think of a network of stateless services which communicate through HTTP (one may call it RESTful or not, depending on how much of a nitpicker one is). But there is another way, which may be more suitable depending on the use case at hand. I am talking about event-driven microservices, where in addition to the classic request-response pattern, services publish messages which represent events (facts) and subscribe to topics (or queues depending on the terminology used) to receive events/messages. To fully understand and embrace this new software design paradigm is not straight-forward but it is totally worth it (at least looking into it). There are several interconnected concepts which need to be explored in order to discover the advantages of event-driven design and the evolutionary path which led to it, for example: Log (including log-structured storage engine and write-ahead log) Materialized View Event Sourcing C o