Storage in Android

Saving data to local storage for later use is common for mobile app development. It is also common scenario that developers struggle to decide which is the best option to save the data.  

There are two types of storage in mobile application development. One is temporary and another is persistent. The temporary data remains in memory while you use the application and as soon as the application is closed/page changed the data goes away. Example: List of enquiries fetched from the server which updates every time the page is opened.  

Persistent data remains in the memory even if you close the app. An example would be a token for authorization. 

There is great list of mobile databases but in limited time I have studied only few. So following are the client side storage method available to android developers: 

1.) Shared preferences: SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. Shared preferences have really fast read and write time complexity if used efficiently. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys. 

2.) Sqlite Database: Large amounts of same structured data should be stored in a SQLite database as databases are designed for this kind of data. As the data is structured and managed by the database, it can be queried to get a sub set of the data which matches certain criteria using a query language like SQL. This makes it possible to search in the data. Of course managing and searching large sets of data influences the performance so reading data from a database can be slower than reading data from SharedPreferences. With Sqlite you have to way to much boiler plate code to make it run. Writing rows to a database take more time then other databases available. Now most of the data we deal with is unstructured, designing database that can your requirement is another issue. Upgrading your data is another hurdle to overcome when using database. 

3.) SnappyDB: On this hunt of mobile databases I came across really lightweight Key Value based database like Shared Preferences which was Snappy Db. It is similar to Shared Preference but not optimized enough. Its an open source DB so one can update it according to your need. Snappy DB is slower then SharedPreferences in both reading and writing operations; 

4.) Couchbase Lite: This is a light version of the well known Couchbase db, they reduced the size of the binary by taking only part of Couchbase db which they thought could be suitable for mobile. One of the main feature of CB db is the ability to make “Views” of the data. View — is a kind of predefined query that is fetched with O(1). How it works — when a new object is inserted to the db it passes through the predefined view filter functions, if it passed all of them it’s added to the view. If you want to go all the way with this DB there is an option to sync it with Couchbase db on the server with no need to write any boilerplate code for that, this could be very useful depending on the data that you use in the app. 

5.) Level DB: LevelDB is an open-source library (written at Google) that implements a key-value store, where keys and values are byte arrays, and data is stored ordered by key (based on some, probably custom, comparison function). LevelDB supports atomic batch updates, forward and backward iteration over the contents of the store, snapshots (i.e. consistent read-only views of the entire store), caching, data integrity (using checksums), and automatic data compression (using the Snappy compression library). 

6.) Realm DB: Realm is a mobile platform and a replacement for SQLite & Core Data. According to the website, it has more than 100k active developers. Realm Mobile Database is much faster than an ORM, and often faster than raw SQLite due to zero-copy design. Some of the benefits of Realm are fast queries, safe threading, encryption of data and reactive architecture. Realm has comparable speed to shared preferences. Advantage of over sqlite is it provides its own ORM and you can store Objects in database which is really a great feature over all the database. Its client end DB is open source and free to use. Realm adds around 0.7MB in your App size. 

 Here is a comparison chart :

If you would like to know more about storage libraries refer here for article. 

At Emqube we focus on building high quality hybrid mobile apps. If you would like us to build an app for you, contact us at  https://wp.emqube.com/contact-us/customer-enquiry/