Skip to main content

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 googled this functionality (before deciding to write the code myself), I just found few code snippets such as this one, and I also realised that there is a company trying to monetize it through a pay-per-use web API. 

But why would you need to verify the user's phone number?
Well, because I think the phone number is probably the best user identifier you can use for your mobile app. 
I believe it is better than asking the user to create yet another user name (or email account) and password, or allow them to authenticate using Facebook or any other social network (not everybody has a Facebook account but obviously everybody who owns a phone has a SIM card, and  hence, a phone number).

Even the product owner of Skype admitted it to me while in a tech talk at the Microsoft offices in Prague, when I asked how come WhatsApp became much more popular than Skype on mobile devices when the latter had a huge advantage since it already had the biggest share of the interpersonal communication market on PC before smart phones became mainstream.
WhatsApp registration and login was (ans still is) much simpler than Skype's, because it uses the user's phone number as identifier.
How many Skype accounts do you have? Or better, how many Skype accounts have you created? I must have created half a dozen myself, most of the people just create a new account when they forget or lose their password.
But with the phone number is a different story, most of the people just have one phone number at a time.

And why do you need to use SMS?
Because the same way a computer connected to the internet does not know her public IP address, a mobile device does not know his telephone number, only the network operator knows it, so we need to use SMS to verify that the phone number entered by the user is really theirs.

So what does the code do
Well, better than explain it with words, just have look at the following diagram

But better, have a look to the code.
I followed the MVC model, so there are 3 main parent packages.
The model classes do not talk to any outer application classes.
The controller classes just talk to the model classes.  
The view classes just talk to the controller classes.  

The code seems to be working fine, but please note that I just pushed to the Github repository the files which I modified while coding this PoC app, so there are many files (mainly resource files) which are missing in the repo but they are simply the default files which you get when creating a new project using Android Studio.


  1. Its an incredible joy perusing your post. It's brimming with data I am searching for and I want to post a remark that "The substance of your post is marvelous" Great work.
    android app development courses in chennai


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

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