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.


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