Skip to main content

My first Android app is live

Versión en español

After several months of long after-work coding sessions at home (partially fuelled by too many Monster drinks), I have finished and published the version 1.0 of my first Android app.

But why would you make a mobile app?
Well, for sure my motivation is not money, I highly doubt that this app will ever make me rich, so far it has actually costed me money, although I have invested little money to be honest.
Thanks to open source software and commodity cloud computing, cash is not an obstacle in order to build and launch an app to the world (I may devote a whole post about it in the future).
What you need are some technical skills but more importantly: perseverance and willing to learn and experiment.
So my motivation was simple: I needed a challenge.
Do not get me wrong, my regular 9-to-5 job as back-end software developer still provides me with a lot of challenges, but I needed one outside the office.
Some people decide to start training for a marathon when they look for a challenge, but I decided to develop and Android application.
I though that it would help me to become a better software developer and I was right.
Every design or implementation decision I made, every new API I used, every data model I created and also every mistake I made was part of an enriching learning path.

So what is your app about?
It is about sharing tickets of the Spanish National lottery, here I explain it (in Spanish): video
Basically, the user buys a physical lottery ticket, then they enter the data (so far manually but I am working on adding another methods) into the app (the most important data is the lottery number and the date of the draw), then they create a virtual share from that number, and finally they send that share to someone from their contact list.
The day of the draw, both the sender and the receiver of the virtual participation will be notified by the application in case they won any prize.
Christmas lottery ("El Gordo") is huge in Spain, every Spanish person spends on average more than 60 euros in lottery tickets just for that one single draw (more than 3 tickets per person).
In addition to that, there are also ordinary draws twice a week (every Thursday and Saturday), and my app supports them too.
As you can imagine, the application targets the Spanish market, but since I do not like restrictions and also I had bad experiences myself when Google got wrong my country (actually, I may write a whole post about it), it is available for download in any country, so feel free to install it on your phone from the Play Store and play with it, you may even learn some Spanish :-)

Ok, enough chatting, throw in some tech stuff!
When I first discussed the idea of building a mobile app, I was advised to use Firebase.
They told me that it is a very fast an easy way to build your app, that it is not based in the classic client/server paradigm and that it abstracts out all the complexity related to data synchronisation.
It sounds good indeed, and I may give it a try some day, but for my first app I wanted to do it "old school" and Firebase does not support SQL.
I wanted to prove to myself that the same technologies which I use on my daily work to develop (financial) back-end applications were also valid for Android development.
Also, if I had chosen to go with Firebase, I would have made my app highly dependent on it.
I think it is much better to depend on open source technologies which are not tight to one particular vendor in order to avoid lock-in issues.
Even more, Android uses an embedded SQLite DB, so if I am forced to use SQL on the client side, why not use it on the server side too?

So these are the technologies I used at a glance:

That's all for my first post, I have a lot more to share though, so I hope you will come back for more posts.


  1. Remarkable post, the information you have mentioned is really knowledgeable and engaging for us, I really enjoyed reading it. Thanks for sharing. Top Development Agencies in India


Post a Comment

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

Cómo pedir cita previa en la DGT y desesperarse en el intento

El uso de la tecnología para la agilización de la administración española es simplemente bochornoso (y me quedo corto). Además todo el mundo lo sabe, sin ir más lejos, la última gran chapuza  informática en el Ministerio de Justicia va a costar al menos  60 millones  extra.  Pero como el dinero sale del bolsillo de los ciudadanos, pues aquí no pasa absolutamente nada y nadie asumirá ninguna responsabilidad. Esta es la triste realidad de la España actual. Pero es que hasta un trámite tan sencillo como pedir cita previa en una de las Jefaturas Provinciales de Tráfico desespera hasta al más templado. Y como quiero ser muy específico y una imagen vale más que mil palabras, a continuación voy a documentar todo el proceso que es de todo menos intuitivo. Todo empieza abriendo este enlace Y como podéis ver en la imagen previa, con la primera pantalla (vamos a obviar que la interfaz parece que ya haya cumplido la mayoría de edad, tiene pinta de ser de finales de los 90) llega la pri

Proof of Social Network Identity: a proof of concept

One of the main criticisms to blockchain technology is based on the huge consumption of electricity required by the biggest networks (e.g., Bitcoin and Ethereum). That huge electric power consumption  comes from using Proof of Work (PoW) algorithms to prevent " double spending " which is closely related to the " 51% attack ". Some other types of algorithm have been developed as an alternative to PoW, the more popular one being Proof of Stake (PoS), which basically implies that individuals with higher stake (i.e., more crypto money) have more power (i.e., are more trusted) than the rest. Hence, PoS, creates an entry barrier for those who want to become members of the blockchain network, since one needs to own a stake in order to join the network. The key to prevent " double spending / 51% attacks"  is to use something  in the block validation mechanism which is complicated or expensive enough for some malicious actor to replicate or to clone or