Android Database Solutions

Introduction

You are about to develop an Android application or you are estimating the cost of a possible one or any other reason that puts you in a position to choose a database solution for an Android application.
Following the clean approach, choosing the database should not be the first thing that you decide for your app architecture. The database solution should be chosen after you have a list off of features that the application will have. Also, you should have a clue of the duration in which the application will be supported. Having all of this things in mind, in the next few minutes, I will present you a flow that will help you to choose the database solution for your application. The flow that will be presented was created based on me and my friends' previous experience on developing Android applications. While reading this, make sure you have a critic reasoning and if you have any opinion regarding this, please leave me a comment below.

Do You Really Need A Database?

Choosing a database solution is a very important decision and taking it as late as possible will give you flexibility and you will probably make this decision, knowing more information about the application requirements. Also, make sure your application really needs a database solution, maybe your application only needs a small amount of data that can be saved on Shared Preferences or it is only using a small list of objects that can be stored in a HashMap and serialized. I will post a blog soon about the topic of having or not a database on your Android application but for now, let's assume that you decided that your app needs a database and now you need to decide on what solution you choose.

Popular Database Solutions

Before we dive in the flow of choosing a database solution, let's first take a look over some very popular database solutions that exist at the time of publishing this post.

No SQL Solutions

• Realm
• SnappyDb
• Couchbase

ORMs (Object Relational Mapping)

• greenDao
• DbFlow
• SugarOrm
• OrmLite

There are a lot of sites/blogs that can help you to use the above database solutions or to describe the advantages and disadvantages of each one of them and compare them with each other. So I will not do that.

In the next few minutes, I will present you a flow that can help you choose the database solution. There is no silver bullet when you are trying to find the best database solution for your application. However, based on my experience and the experience of my colleagues, I came up with this decision diagram.

If you are developing an application that needs to keep the data encrypted (like a health application), the flow diagram is smaller because you have less solutions that support encryption.

Description of Diagrams

If the diagrams from above did not make any sense to you, please have some patience and follow me while I will try to explain the reason behind this flow represented by the above diagrams.

The first thing that you need to take into consideration is the amount of time the application will be developed and supported. If you are going to build a small application with the development and supported time less then 6 months, then you need a very simple, nimble and fast database solution. Also, you will need to look over the relations between your model objects. If there aren't a lot of relations between objects and you can save them in list collections or mapped with a key, you can use SnappyDb. SnappyDb is a very fast and easy to use database engine so it fits very well in this case. However, if your application needs some advanced database features (like notify when database models are updated or automatically sync with a web service), you can use Realm or Couchbase.

Realm, at the moment, is the most advanced, supported and feature rich NoSql database engine. There are a lot of things that you can achieve very easily with realm so I encourage you to check-it out.

However, if there are a lot of relations between objects and you will find yourself very often in the situation where you need to query objects in a SQL like manner, then you have to think if you want something very simple and very easy to use and you don't care so much about the architecture, if so, then you could use something like SugarORM.

If not, if the architecture is important to you, then you should ask yourself if you like to experiment with some new database solutions or you want something very stable, if the experiment is an option to you, I encourage you to use DbFlow or Requery, however if this is not the case, you should use greenDao.

Most of the applications nowadays have the development plus supported time more than 6 months and it is recommended to have as a database solution something that is easy to maintain, something that does help you to create a more decoupled architecture ensuring testability.

Having established the fact that the application will last longer than 6 months, then you should ask yourself again if your application has lots of relations between objects. If so, then you can use greenDao, otherwise your option can be Realm.

GreenDao currently is the fastest Sqlite based database. Also, the way greenDao works can help you achieve a very scale-able, decoupled and easy to maintain architecture.

Encryption

If the application that you are developing has to save the data encrypted, then your options are limited. The only question that you should ask is if there are a lot of relations between objects. If so, then your options are greenDao or DbFlow. However, if this is not the case, and your objects can be manipulated in collection with very little relations between them, then your option is Realm.

Conclusion

Creating a good architecture is important, it is not an easy task and requires a great deal of attention and analysis, also acting early is very important. In one stage of architecting your application, you will think about saving data persistent. The idea here is to imagine the module for saving the data as an abstract entity that can be implemented later on. But when you are at the moment when you need a concrete database solution, then you can use the flow described earlier to help you choose the most appropriate one to your application database solution. And always remember that there is no silver bullet, not all database solutions out there can match your needs.

Thank you for your attention and please let me know what is your opinion about this by leaving a comment below.