How We Built the Android Manager App


Important UpdateSome of the voice features and functionality described in the below blog post are no longer offered by SendHub. In order to streamline the focus of our product to best support the business messaging needs of our customers we’re no longer supporting some of voice related features mentioned here. To learn more about our Business SMS solution, and the features included please visit

A while back we released the SendHub Manager App for Android which allowed managers to add and remove phone lines, and keep track of all their company usage. Today we’ve added the ability to log in to the SendHub app on any of your phone lines with the click of a button.

Until now, the SendHub Android app was used primarily by a single user at a time, with logouts and logins being relatively rare. User sessions were handled by simply downloading all of a user’s data when they logged in and clearing it when they logged out. This process was time consuming, data intensive, and not up to snuff for users who wanted to quickly log in and out of multiple accounts.

We hold all user information in a SQLite database, so given that we needed to persist data in order to keep session switches short we came up with two possible ways to handle this:

1. Add a userID column to all our tables and store all users information in the same table.

2. Create a new table for each user and switch between these at login/logout.

We went with option two for several reasons. First, we want to keep our queries fast, and using multiple databases means we will already have only the subsection of user data that we might need available at any time. Second, we want to keep the app to as small a storage footprint as possible and it is much easier to remove an entire database if it hasn’t been used in a while than to select specific data out of a larger database. More importantly, this was the option that required the least amount of change with our existing code. There is no need to rewrite queries or add new migrations; all we had to do was swap out the database as the user changed.

The basic implementation was straightforward: since we use a singleton for our database helper anyway, we simply added a bit of logic to getInstance() to make sure the correct database was returned.


The code above is a typical implementation of a singleton getter with two additional pieces. If there is no userId for the session we don’t create a database because no one is logged in. If there is a user ID, then we check if the current DatabaseHelper is attached to any database that does not match the user ID. If the IDs don’t match we simply close the old database and create a new DatabaseHelper with the correct user ID.

This is a quick way to add multiple user sessions to an app, but keep in mind it also requires code for cleaning up old databases and preventing long running processes from dumping data into another users database. Wanna check it out? Download the SendHub Manager App today and let us know how it’s working for you!

About The Author