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.

Comments

Popular posts from this blog

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 ViewEvent SourcingCommand Query Respons…

Vert.x microservices: an (opinionated) application

First of all, sorry for the tautology in the title, a library can be either opinionated or un-opinionated (such as Vert.x is), but an application can only be opinionated.
However, I decided to include "opinionated" to help getting my point across even though is redundant.
The Motivation  I am a big fan of Vert.x and the official documentation is quite good, yet it is not straight-forward to understand how it works and how to use it.
There are a lot of blogs and articles describing Vert.x terminology and its concurrency model.
There are also tons of "Hello World" Vert.x applications on Github, and the rest seem to be just variations of the already typical "Web chat application using Vert.x".
On top of that, many of them are outdated (using AngularJS instead of Angular2+, for example).

The only two exceptions which I found are:
vertx-microservices-workshop: a demo application by the Vert.x development team.
ngrx-realtime-app: proof of concept application focu…

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, no need for …