Forem: Kwabena Bio Berko

Automatic SMS Verification With Android's SMS Retrieval API

Kwabena Bio Berko — Mon, 14 Dec 2020 14:07:31 +0000

We, as Android developers always strive to make our app's onboarding process of new users as friction-less as possible. One way to achieve such smooth, effortless on-boarding is to implement an Automatic SMS verification feature.

If you've used Uber or Whatsapp, you would have noticed that their SMS verification is automatic: The user need not manually type in the verification code. This makes their on-boarding feel seamless and kind of effortless on the part of the user. And the best part of this is that they do not request the user's SMS permission.😮 This is done using Google's SMS Retrieval API, and in this article, we will see how to achieve just that in our apps as well.

Before we begin, we need to import the following libraries:

Google Play Services Auth API - This library contains the SMS Retrieval API classes.
Apache Commons - This will be used to parse out the verification code from the SMS message.
EventBus - We will be using a BroadcastReceiver to listen for the retrieved SMS from the SMS Retrieval API. EventBus is a library that uses the publisher/subscriber pattern and will be used to simplify the communication between our BroadcastReceiver and our Activity classes.

Let's add them to our app's build.gradle file:

    implementation 'com.google.android.gms:play-services-auth:19.0.0'
    implementation 'org.apache.commons:commons-lang3:3.11'
    implementation 'org.greenrobot:eventbus:3.2.0'

Alright, we are set.

Our XML layout file is extremely simple. It contains a TextView in the middle of the screen. This view will be used to display the verification code we extract using the SMS Retrieval API.

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <TextView
        android:id="@+id/otp_text_view"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
        android:textColor="@android:color/black"
        android:textSize="30sp"
        android:gravity="center"
        android:text="Loading..."
        />

</RelativeLayout>

What we are going to do next is to get an instance of the SmsRetrieverClient object, call its startSmsRetriever instance method, and attach onSuccess and onFailure Listeners to the resulting Task. I'm going to wrap that portion of code in a method to easily reuse later:

private fun startSmsListener() {
    smsRetrieverClient.startSmsRetriever()
        .addOnSuccessListener {
            Toast.makeText(this@MainActivity, "Starting Sms Retriever", Toast.LENGTH_SHORT).show()
        }.addOnFailureListener { e ->
            e.printStackTrace()
            Toast.makeText(this@MainActivity, e.message, Toast.LENGTH_SHORT).show()
        }
}

Then we call that method immediately after onCreate:

MainActivity.kt

class MainActivity : AppCompatActivity() {
    private lateinit var smsRetrieverClient: SmsRetrieverClient
    private lateinit var otpTextView: TextView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        otpTextView = findViewById(R.id.otp_text_view)
        smsRetrieverClient = SmsRetriever.getClient(this)
        startSmsListener()
    }
...

At this point, when an SMS message is received on our device, the Play Services library we added earlier will broadcast an SmsRetriever.SMS_RETRIEVED_ACTION intent to our app. This intent contains the status of the background processing as well as the text of the SMS message.
Let's create a BroadcastReceiver class to handle this:

SmsBroadcastReceiver.kt

class SmsBroadcastReceiver : BroadcastReceiver() {

    companion object {
        val TAG = SmsBroadcastReceiver::class.java.simpleName
    }

    override fun onReceive(context: Context?, intent: Intent) {
        Log.d(TAG, "onReceive Called!")
        if (SmsRetriever.SMS_RETRIEVED_ACTION == intent.action) {
            val bundle = intent.extras
            if (bundle != null) {
                val status: Status = bundle[SmsRetriever.EXTRA_STATUS] as Status
                var isTimeout = false
                var smsMessage: String? = null
                when (status.statusCode) {
                    CommonStatusCodes.SUCCESS -> {
                        val message =
                            bundle[SmsRetriever.EXTRA_SMS_MESSAGE] as String
                        Log.d(TAG, message)
                        smsMessage = message
                    }
                    CommonStatusCodes.TIMEOUT -> {
                        Log.d(TAG, "Timeout")
                        isTimeout = true
                    }
                }
                EventBus.getDefault().post(SmsRetrievedEvent(isTimeout, smsMessage))
            }
        }
    }

}

In the BroadcastReceiver's onReceive method, we first check the Status of the background processing done by the SMS Retrieval API. We also create an instance of a class called SmsRetrievedEvent. This is our event class that will be published by EventBus to our Subscriber.The SmsRetrievedEvent class is nothing but a simple Kotlin data class. Kindly read more here if you are totally new to EventBus.

SmsRetrievedEvent.kt

data class SmsRetrievedEvent(
    val isTimeout: Boolean,
    val smsMessage: String?
)

If the background processing was successful, we set the message property of the SmsRetrievedEvent class to the SMS message we've retrieved. Otherwise, we set timeout to true if a timeout occurred. We finally publish the event to any listening subscriber.

Note: Timeouts occurs if messages are not handled within 5 minutes after processing by the SMS Retreival API.

Let's not forget to register this BroadcastReceiver in our AndroidManifest file:

AndroidManifest.xml


<application>
        ...
        <receiver
            android:name=".SmsBroadcastReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="com.google.android.gms.auth.api.phone.SMS_RETRIEVED"/>
            </intent-filter>
        </receiver>
    </application>

Next, we are going to register, unregister as well as implement our subscriber in our MainActivity class. This method will be defined with the @Subscribe annotation and will be called when an event is published/posted.

Note: Always remember to unregister your subscribers to avoid memory leak issues.

MainActivity.kt

class MainActivity : AppCompatActivity() {
    private lateinit var smsRetrieverClient: SmsRetrieverClient
    private lateinit var otpTextView: TextView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        otpTextView = findViewById(R.id.otp_text_view)
        smsRetrieverClient = SmsRetriever.getClient(this)
        startSmsListener()
    }


    override fun onStart() {
        super.onStart()
        EventBus.getDefault().register(this)
    }

    override fun onStop() {
        EventBus.getDefault().unregister(this)
        super.onStop()
    }

    @Subscribe
    fun onEvent(event: SmsRetrievedEvent) {
    }

    private fun startSmsListener() {
        smsRetrieverClient.startSmsRetriever()
            .addOnSuccessListener {
                Toast.makeText(this@MainActivity, "Starting Sms Retriever", Toast.LENGTH_SHORT).show()
            }.addOnFailureListener { e ->
                e.printStackTrace()
                Toast.makeText(this@MainActivity, e.message, Toast.LENGTH_SHORT).show()
            }
    }
}

Finally, we parse out the 4 digit verification code from the message using the substringAfterLast method from the Apache Commons library, and display it in our TextView

...
@Subscribe
    fun onEvent(event: SmsRetrievedEvent) {
        Log.d("SMS EVENT", "RECEIVED SMS EVENT")
        Log.d("SMS EVENT - Timeout=", event.isTimeout.toString())
        Log.d("SMS EVENT - Message=", if(!event.isTimeout) event.smsMessage!! else "Timeout: No Message")

        val otp: String =
            StringUtils.substringAfterLast(event.smsMessage, "is").replace(":", "")
                .trim().substring(0, 4)
        Log.d("EVENT", otp)

        runOnUiThread {
            otpTextView.text = if (!event.isTimeout) otp else "Timeout :("
        }

        startSmsListener()
    }
...

One important thing to keep in the back of our minds:
The SMS Retreival API requires that SMS messages be in the following format:

Your verification code is 9872


FA+9qCX9VSu

The SMS message must end with an 11-character hash string that identifies your app(which is FA+9qCX9VSu in this case). Click here to see how to compute your app's hash.

At this point we can send the SMS message to our device, extract and send the 4 digit code to our server for verification.

Click here to see a sample project on GitHub.

Happy Coding, everyone!

Extend Express's Request Object with Typescript Declaration Merging.

Kwabena Bio Berko — Wed, 29 Jan 2020 16:02:05 +0000

Express has been my go to server side node web framework for the past few years. Its fast, unopinionated and so easy to get up and running. I really love using it along with Typescript too, I should say. It enhances code quality and understand-ability. Refactoring your code in Typescript is also much more easier and faster. Plus, you get the added advantage of code completion and IntelliSense when using modern text editors like Visual Studio Code. 😋

One of the concepts of Typescript which I've recently began using is Declaration Merging.
Declaration Merging allows you to merge two or more distinct declaration or types declared with the same name into a single definition. This concept allows you to attach your own custom property onto another Typescript interface type. Lets take a look at a typical Express middleware.

The above code is an Express middleware that is used to ensure that a user is authenticated when he or she tries to access a protected resource. It decodes the user's token from the authorization property of the request headers and attaches the user to the Request object. But see that red squiggly line?
Thats because the property currentUser does not exist on Express's Request interface type. Let's fix that. 😃

The first thing we need to do is to create a new declaration file @types > express > index.d.ts in the root of our project.

You would notice this is the exact same file name and path in our node_modules/@types folder. For Typescript declaration merging to work, the file name and its path must match the original declaration file and path.

Next we need to make some few changes in the project's tsconfig.json file. Let's update the typeRoots value to the following:

...
"typeRoots": [
      "@types",
      "./node_modules/@types",
    ]                    
...

By default, the Typescript compiler looks for type definitions in the node_modules/@types folder. The above code instructs the compiler to look for type definitions in this folder as well as our custom @types folder in our project root.

It's now time to add our custom currentUser property to Express's Request interface type by modifying the index.d.ts file we created earlier:


import { UserModel } from "../../src/user/user.model";

declare global{
    namespace Express {
        interface Request {
            currentUser: UserModel
        }
    }
}

Lets take a look again at our middleware file and we immediately notice that the red squiggly line is gone! This is because the Typescript compiler now recognizes the currentUser property as a valid property on the Request type interface.

Happy Coding, everyone!

Implementing SQL- Like Cascades in Mongoose

Kwabena Bio Berko — Mon, 07 Jan 2019 23:02:43 +0000

I was very recently working on a hobby project: a role based access control application where I needed to implement cascade delete in some of the models.
The user model for instance, had a roles attribute which was an array of the ObjectId's of the role model:

const mongoose = require("mongoose");

const UserSchema = new mongoose.Schema({
  username: {
    type: String,
    unique: true,
    required: true
  },
  password: {
    type: String,
    required: true
  },
  roles: [
    {
      type: mongoose.Schema.Types.ObjectId,
      required: true,
      ref: "Role"
    }
  ]
});

Roles are dynamically created and assigned to users. The problem I was facing though, is that when a Role is deleted, it's ObjectId references in the user model were not also deleted, therefore becoming orphaned, hence breaking referential integrity.

To prevent this, I needed to implement cascade delete. In SQL, it's as simple as adding the ON DELETE CASCADE referential action when creating your users_roles table like so:

CREATE TABLE users_roles (
    user_id int unsigned not null, 
    role_id int unsigned not null, 
    PRIMARY KEY (user_id, role_id), 
    FOREIGN KEY (user_id) REFERENCES users (id) 
        ON DELETE CASCADE, 
    FOREIGN KEY(role_id) REFERENCES roles (id)
            ON DELETE CASCADE
);

But I was using mongodb and the mongoose ODM. How was I supposed to go about this? I was able to solve this by utilizing mongoose middlewares. As per their documentation, mongoose middlewares or hooks are functions that are passed control during execution of asynchronous functions. The post middleware or hook in particular is exactly what I needed as it would allow me to perform some actions immediately after a database operation completes:

const mongoose = require("mongoose");
const User = require("./user");

const RoleSchema = new mongoose.Schema({
  title: {
    type: String,
    required: true
  }
});

RoleSchema.post("remove", document => {
  const roleId = document._id;
  User.find({ roles: { $in: [roleId] } }).then(users => {
    Promise.all(
      users.map(user =>
        User.findOneAndUpdate(
          user._id,
          { $pull: { roles: roleId } },
          { new: true }
        )
      )
    );
  });
});

module.exports = mongoose.model("Role", RoleSchema);

Let me briefly describe the code above. Immediately after deleting a particular role, I find all users that have that role id in their array of roles using mongodb's $in operator (mongoose allows you to use native mongodb operators in your queries).

....
User.find({ roles: { $in: [roleId] } })

Then for each user that satisfies that criteria, another operator, the $pull operator is used to "pull" or remove that specific role id from their array of roles.

....
User.findOneAndUpdate(
  user._id,
  { $pull: { roles: roleId } },
  { new: true }
)

This is the approach I used to implement cascade delete in mongoose to ensure referential integrity. I would love to hear of the other approaches you might use to solve a similar problem in mongoose.

Happy coding, everyone!

The API-First Approach To Building Softwares

Kwabena Bio Berko — Sat, 20 Oct 2018 16:50:34 +0000

Imagine this scenario. You and the company you work for built an awesome web application for a client which has been in use for almost 6 months. One day the client pays a visit and says that due to the popular demands from his customers, he wants you to develop a desktop and mobile client for it. The web app your company built though was a tightly coupled, server-side rendered MVC application. Whoopsies!

This is a very common and precarious situation most companies encounter more often than not. This is because of the rapid advancement of technology as well as the unpredictability of customer requirements. The most common solution that companies in this situation usually go for is by building a separate API for the existing application which usually brings about redundancy as well as doubling the amount and effort to build and maintain.

Granted, there may be situations where you have no choice. For instance, the app may have already been built using that architecture before you assumed control of it. In such cases, this solution works best. If you are building the application from scratch though, it might be wise to use API-First approach so as not to encounter the scenario described.

What then, is API-First approach?

It is an approach to building device agnostic software where API's act as the base interface to the entire application. In other words, API's are treated as first-class citizens and essentially become the only way to communicate and access data from the application. Anything not exposed by the API is practically non-existent to the developers building on top of it.
The most popular types of API's include but not limited to:

SOAP - Simple Object Access Protocol
REST - Representational State Transfer
RPC's - Remote Procedure Calls
GraphQL

Since API's only deal with data, they bring about flexibility because front-end developers are at liberty to display the data to the user any way they like. For example, the profile page in a mobile app client may be displayed differently to that on the desktop client even though they consume the same data. The data may be of the following data exchange formats:

XML - Extensible Markup Language
JSON - JavaScript Object Notation
Protobuf - Protocol Buffers

Benefits of API-First Approach

Reduces code redundancy
Promotes separation of concerns
Easier to extend
Brings about interoperability as multiple client apps consume the same data.
Easier to maintain
Easier to test and debug
Brings about flexibility
Encourages the use of microservices architecture

Since customer demands are highly unpredictable, using an API-First Approach might be your best bet as it usually does and will pay dividends in the future, saving you time, efforts and headaches.

Happy coding!

Test Emails in Your Node/Express Apps using Mailtrap.io

Kwabena Bio Berko — Mon, 16 Apr 2018 01:53:44 +0000

One feature usually present in almost all software applications is an emailing feature, as it's one of the surest ways to get in touch and communicate with your users. There are many email delivery services that make the development of such a feature a breeze, such as Sendgrid, Postmark, Mailgun and Sparkpost. My favourite is Sendgrid. :)

Anyhow, the most common problem when developing an email feature in the pre-production stage is spamming, since you will definitely be using real email addresses when using any of the email delivery services listed above. Hence its neccessary to do sandbox testing.

Enter Mailtrap. Mailtrap is a fake SMTP server developed by railsware and its very useful for pre-production testing. Ideally, you should do email testing with a service like mailtrap and switch to sendgrid and the likes when rolling to production.

In this short example, I will show you how i do sandbox email testing in Node. If you want to follow along, kindly download or clone the project from github. Open up the project in your terminal, and install the required npm packages using npm install. Once installed, cd into the start folder and open the app.js file in your favorite editor. If you haven't done so already, head on over to the mailtrap website and create a free account. Once done navigate to the inbox and you should see both your SMTP and POP3 credentials.

We are going to use the nodemailer module to send our email. Lets create a nodemailer SMTP transporter and configure it for use.

  //Start Here
  const transporter = nodemailer.createTransport({
    host: "smtp.mailtrap.io",
    port: 2525,
    auth: {
        user: "MAILTRAP_SMTP_USERNAME",
        pass: "MAILTRAP_SMTP_PASSWORD"
    }
  });

Now, let's setup our message options:

  const mailOptions= {
    from: '"Test Server" <test@example.com>',
    to: req.body.email,
    subject: "Email Test",
    text: "This is an email test using Mailtrap.io"
  };

Then we send our message using the sendMail() method of our transporter object:



  transporter.sendMail(mailOptions, (err, info) => {
    if(err){
        console.log(err);
        return next(err);
    }
    console.log("Info: ", info);
    res.json({
      message: "Email successfully sent."
    });
  });

Let us test to see if this works. Fire up the server by typing node app.js. Now lets send a POST request to http://localhost:8001/email. I am going to use cURL for this. You can use Postman or any REST client of your choice.


curl -X POST -H "Content-Type:application/json" -d "{"""email""":"""johndoe@gmail.com"""}" http://localhost:8001/email

Hopefully, you get a response like the one below, which should mean the code worked:


{"message":"Email successfully sent."}

Let's check to see if this is the case by checking our mailtrap inbox.

As you can see, Mailtrap allows you to easily test sending emails, as was described above. The Node.js app used in this example makes use of Nodemailer to send emails, but there are other transport options and email packages out there. If you are looking for Nodemailer alternatives, kindly check out this article: Sending Emails with Node.js. This article goes in depth about some email-oriented packages like Email.js and how to use Gmail to send messages from your Node.js app.

Happy Coding!

Sugar ORM: An easier way to work with SQLite Databases in Android.

Kwabena Bio Berko — Wed, 15 Nov 2017 19:34:17 +0000

If you have been working with the Android SQLite database for some time now, you would have noticed something: Setting it up requires a considerable amount of time and loads and loads of boilerplate code.

I recently discovered Sugar ORM, an awesome library that makes it super simple and less time consuming to work with the SQLite database.

In case you didnt already know, an ORM (Object-Relational Mapper) allows you to represent your data as objects and then persist those objects in a relational database, automatically handling the conversion of data for you.

To install Sugar ORM via gradle, simply add this line to your module level gradle dependencies and sync your project:

compile 'com.github.satyan:sugar:1.5'

The current version at the time of this writing is version 1.5.

Sugar ORM requires minimal configuration of your Manifest file. You have to specify SugarApp as your application class by changing the android name attribute in your application tag. You also need to include some meta data about your database such as your database name, version, query log and domain package name. Your manifest file should look something like this:

 <application
        android:name="com.orm.SugarApp"
        android:allowBackup="true"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
        <meta-data android:name="DATABASE" android:value="sugar_example.db" />
        <meta-data android:name="VERSION" android:value="1" />
        <meta-data android:name="QUERY_LOG" android:value="true" />
        <meta-data android:name="DOMAIN_PACKAGE_NAME" android:value="com.kwabenaberko" />
    </application>

When using the sugar ORM, all data models or classes that you want to persist need to extend SugarRecord and also have at least an empty default constructor like so:

import com.orm.SugarRecord;

public class Developer extends SugarRecord{
    private String firstname;
    private String lastname;
    private String favouriteLanguage;

    public Developer(){

    }

    public Developer(String firstname, String lastname, String favouriteLanguage){
        this.firstname = firstname;
        this.lastname = lastname;
        this.favouriteLanguage = favouriteLanguage;
    }

    public String getFirstname() {
        return firstname;
    }

    public void setFirstname(String firstname) {
        this.firstname = firstname;
    }

    public String getLastname() {
        return lastname;
    }

    public void setLastname(String lastname) {
        this.lastname = lastname;
    }

    public String getFavouriteLanguage() {
        return favouriteLanguage;
    }

    public void setFavouriteLanguage(String favouriteLanguage) {
        this.favouriteLanguage = favouriteLanguage;
    }
}

Once everything is set up, we can begin performing operations on our model.

Inserting a new record

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Developer developer = new Developer("Kwabena", "Berko", "JavaScript");
        developer.save();
    }
}

When inserting a new record, Sugar ORM automatically adds an auto-increment id field for you.

Selecting an existing record by its id

 Developer developer = Developer.findById(Developer.class, 1); // 1 is the record's id.
 Log.v("RESULTS", developer.getId() + 
                ", " + developer.getFirstname() +
                ", " + developer.getLastname() +
                ", " + developer.getFavouriteLanguage()
 );

Updating an existing record

Developer developer = Developer.findById(Developer.class, 1);
developer.setFavouriteLanguage("Golang");
developer.save();

Selecting all records

List<Developer> developers = Developer.listAll(Developer.class);
for(Developer developer : developers){
    Log.v("RESULTS", developer.getId() +
            ", " + developer.getFirstname() +
            ", " + developer.getLastname() +
            ", " + developer.getFavouriteLanguage()
    );
}

Deleting an existing record

Developer developer = Developer.findById(Developer.class, 1);
developer.delete();

Happy Coding!

Backend or Frontend First?

Kwabena Bio Berko — Sun, 22 Oct 2017 11:41:03 +0000

Do you prefer to build your frontend or backend first? Any advantages? Any disadvantages?

Async Iteration in Nodejs

Kwabena Bio Berko — Tue, 17 Oct 2017 22:52:38 +0000

Node.js is an amazing JavaScript run-time environment, no doubt. Its non-blocking IO model makes applications built with it amazingly fast and highly efficient. But sometimes its non-blocking nature provides some interesting challenges when performing asynchronous iterations.

Lets say we have an array of user ids, and we want to loop through the array and query our users collection(or table) for more information such as their first name, last name and email address. In the end we want to return another array of objects containing these data.

One approach we may use will be as follows:


const getUserDetails = (userIds, callback) => {

    let userInfoArr = [];

    for(let i = 0; i < userIds.length; i++){
        User.findById(userIds[i], (err, user) => {
            if(err){
                return next(err);
            }

            userInfoArr.push({
                firstName: user.firstName,
                lastName: user.lastName,
                email: user.email
            });
        })
    }

    callback(userInfoArr);
}

getUserDetails(ids, (users) => {
    console.log(users);
})

You might think this will work and that we successfully get back the array of users that we wanted, but when we log the resulting users array to the console, we get an empty array. Why is that?

Well, as we already know, node is asynchronous: it doesn't sit around and wait for the result of an execution and instead goes back only when the result is available.
So the reason we are getting an empty array is that at the point where we logged the resulting array, the execution of our code was not complete.

This means we have to wait for the execution to be complete before we return our results. One way that has worked for me is by introducing a new counter variable.
In every iteration, the value of the counter is increased and then checked to see if its equal to the length of the array we are iterating over. If the counter is equal to the array's length, then we assume the execution has completed and we return the resulting array, like so:



const getUserDetails = (userIds, callback) => {

    let userInfoArr = [];
    let counter = 0;

    for(let i = 0; i < userIds.length; i++){
        User.findById(userIds[i], (err, user) => {
            if(err){
                return next(err);
            }

            userInfoArr.push({
                firstName: user.firstName,
                lastName: user.lastName,
                email: user.email
            });

            counter++;

            if(counter == userIds.length){
                return callback(userInfoArr);
            }
        })
    }
}

getUserDetails(ids, (users) => {
    console.log(users);
});

Happy coding!