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

Shared Ledger Simulator

I have been interested in the shared/distributed ledger technology (a.k.a. block chain, a.k.a. the magic behind cryptocurrencies) for more than a year already but recently I had finally put real time and effort into it.

And since I believe that the best way to understand something is to get your hands dirty, that is what I have done, after I got a grasp of the core principles (or that is what I thought back then), I decided to code my own shared ledger simulator.

Initially, I also considered to look into the main existing code bases (e.g., the source code of the main/official Bitcoin client/miner or Ethereum's) since they are open source, but seeing code like thisput me off... That file is 3229 lines big!!! Plus it is written in C++.
Do not get me wrong, I truly believe Satoshi Nakamoto (i.e., whoever hides behind that name) is a genius and also a great software developer, but he/she/they for sure did not have readability as their main priority.

I also noticed that some other people h…

Ejemplo de uso de una Open Banking API para encontrar las transacciones de mayor cuantía

Advertencia y disculpas previas: ésta es una de las primeras veces que escribo sobre programación en mi lengua materna (castellano/español) porque el 99% de lo que sé lo he aprendido (y practicado) en inglés, por lo tanto, me disculpo de antemano si los términos técnicos empleados no son los correctos o si utilizo términos directamente en inglés para los cuales existe una versión en español.

Las entidades financieras cada vez se parecen más a empresas tecnológicas y hay quien asegura que el futuro de la banca está en las Open Banking APIs

Pero... ¿para qué sirve una Open Banking API? 
Las Open Banking APIs permiten crear aplicationes basadas principalmente en los datos que posee la entidad suministradora de la API (normalmente un banco).

¿Y quién puede crear esas aplicationes? Entidades o incluso desarrolladores de software individuales que no tienen por qué tener ninguna relación especial con la entidad financiera. Es decir, cualquiera con unos conocimientos intermedios (iba a decir &quo…

Complete (working) code to verify an Android app user phone number through SMS

Update from Thursday September 14th 2017: 
The very same day I posted this (the day before yesterday), I realized that it looked like Google had just made it effectively obsolete


I thought that at least I could claim that I chose a very demanded functionality to blog about, since Google decided to add a new API to provide this very same service.
Even the names are quite similar, I called it "SMS Verifier" and they call it "SMS Retriever".
But after looking into this new Google Services API, I found out that it requires to use a paid third-party service such as Twilio... very disappointing!
So my original post (which follows below) is still relevant after all, since it allows you to verify the user's phone number for free.

Original post: Tuesday September 12th 2017
It was about time for me to give back to the open source community, so I have just pushed the complete (working) code to verify the user's phone number from within an Android app to Github.

When I goo…