Offline-First Android Applications With NoSQL: Part 1

DZone 's Guide to

Offline-First Android Applications With NoSQL: Part 1

The first part of Nic Raboy's article on developing offline-first Android applications, and comparing NoSQL to SQLite.

· Mobile Zone ·
Free Resource

Android is a great platform with a ton of diversity. In this guide we’ll be looking at different development practices and how each might benefit you as a developer and those who use your apps. These development practices will tie together with different database technologies and techniques, leaving you with an awesome final product.

Offline-First vs. Mobile First vs. API First

There are many "first” practices circulating the Internet. We’re going to deep-dive into **offline-first** for this guide, what is it, and how it differs from the other “first” approaches?


No one can say their mobile devices are always connected to the internet. Maybe you’re on an airplane or driving through a tunnel. The internet connection for your device may be flakey or even non-existent in these scenarios.

So what happens if an application was designed to expect an internet connection? The application will be slow waiting for network responses, or even not function at all.

The **offline-first** approach means writing your mobile applications as if no internet connection will exist for any given user. When you’ve got a fully functional application that works perfect without an internet connection, then start adding network functionality.


Mobile devices come in all shapes and sizes. You not only have varying screen sizes, but you also have varying screen resolutions. In most of these scenarios, a mobile device screen, and resolution will never match that of a desktop or laptop computer.

So what happens if you design a website that looks great in a desktop web browser and try to load it in your mobile device? If not done correctly, this website will be hardly usable on
a mobile device because it was designed for desktop web browsers.

This is where the **mobile-first** approach was designed. Mobile-first is the practice of designing an application to look and function great on a mobile device (smaller screens) before moving onto desktop web browsers (larger screens).


Things that have access to the internet are growing at an extreme rate. Fifteen years ago you only had computers getting online, but now you have phones, watches, thermostats and plenty of other things, with more coming.

So how do you design applications when tomorrow you could have ten new devices or platforms trying to utilize them? You could make an application that works great on small and large screens, but tomorrow you may end up with a device that has no screen.

This is where the **API-first** approach comes into play. API rst is the practice if developing your API before you determine what platforms and devices will use it. Once you get an API going, adding a front end such as mobile or web should come easy regardless of device, screen size, or platform. This kind of practice is great when you need to allow access to your data from the outside world because you don’t know how their going to use it and it doesn’t truly matter.

Designing UX for the Modern Mobile Application

The best approach, as of today, when developing mobile applications that access remote data would be the **offline rst** approach. Users want to use mobile applications regardless of where they are or how limited their internet access may be. From a user perspective, if an application is stuck loading or is not functional because no stable internet exists, they are probably going to uninstall the application and leave a negative review in the app store. No one wants their application screens to hang waiting for a response. They want their screens to be responsive.

By having a local copy of the data available at all times, the application will remain usable, it will continue to be blazing fast, and your users will love you for it.

NoSQL vs. SQLite for Android

Out of the box Android allows you to store your data in a SQLite database, however, is that the best option for us when it comes to data management in a mobile app?

SQLite Databases

SQLite has been around for a while. If you’re unfamiliar with the technology, it is an embedded relational database that practices the tables, rows, and columns concept.

In Android, you can manage a SQLite database by extending the SQLiteOpenHelper class. A sample class for managing your SQLite data might look something like this:

public class Datasource extends SQLiteOpenHelper {

public void onCreate(SQLiteDatabase db) {
String createTableQuery = "CREATE TABLE person (" +
"lastname TEXT " +

public int insert(String firstname, String lastname)
SQLiteDatabase db = this.getWritableDatabase(); 
      ContentValues values = new ContentValues();
int rowId = 0;
values.put(“firstname”, firstname); 
      values.put(“lastname”, lastname);
rowId = (int) db.insert(“person”, null, values); db.close();
return rowId;

Of course the above code leaves much to be desired as it is not a complete class. However, it allows for proof of the following point.

What happens if you decide one day you want to add a new column to that table? You’re going to have to write some scripts and gracefully update your database.

Now let me throw a new, but similar scenario at you. What if you are syncing data from a remote API and the data structure changes in that API? How are you going to accommodate then? Are you going to monitor the API daily for changes so you can update your schema as necessary?

NoSQL Databases

NoSQL databases are different than what you’d find in a relational database like SQLite. In the case of a document database, each document of data has no schema. Let’s take the example of Couchbase, a NoSQL document database, for managing data in Android. A simple insert function might look something like the following:

public void insert(String firstname, String lastname) { 
  Map<String, Object> docContent = new HashMap<String,
docContent.put(“firstname”, firstname); 
  docContent.put(“lastname”, lastname); 
  Document document = couchbaseDatabase.
try {
    } catch (CouchbaseLiteException e) {
Log.e(TAG, “Cannot write document to database”, e);

We don’t have to worry about creating a table because like mentioned earlier there is no concept of tables or schemas. If the need to add a new data property comes up, it can just be added via another put statement. No need to restructure or upgrade your database to accommodate. The put function adds properties of data to particular documents.

Why NoSQL is Important in Modern Development

Twenty years ago relational databases made sense because the web was limited and people knew exactly what they wanted to store.

Now, data is inconsistent. The need to track certain data may be different tomorrow from what it is today. Having to make such manipulations to how data is stored on a daily basis can be cumbersome on large relational databases. Removing structure from the database makes it incredibly easy to store unstructured data and that is where NoSQL excels.

But how does NoSQL fit best for offline-first experiences? Find out in part 2 tomorrow!

android ,java ,mobile ,nosql

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}