Android Database Solutions

Tags

, , , ,

How to choose your database

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 think 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 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 bellow.

 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 lets 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, lets first take a look over some very popular database solutions that exists at the moment of publishing this post.

No Sql solutions:

ORMs(Object Relational Mapping):

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 following 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.

choose-database-solution-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 supports encryption.

choose-database-solution-with-encryption-support-1

Diagrams description

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 than 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 advance 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, than 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, than you could use something like SugarORM.

If not,  if the architecture is important to you than 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 application now days 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, than you should ask yourself again if your application has  lots of relations between objects. If so, than 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, than your options are limited. The only question that you should ask is if there are a lot of relations between objects. If so, than 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 than 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 arhitecting 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, than you can use the flow described earlier to help you choose the most appropriate to your application database solution. And always remember that there is no silver bullet, not all the 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 bellow.

Social Mashup

Task:

Să se dezvolte un mash-up care – pornind de la termen sau set de termeni – oferă cele mai recente mesaje emise de utilizatorii unei aplicaţii sociale. Aceste mesaje conţin, desigur, acei termeni precizaţi. De asemenea, vor fi puse la dispoziţie resurse multimedia preluate pe baza tag-urilor din cadrul unor situri de partajare de imagini (de exemplu, Flickr ori Instagram) sau video (e.g., Vimeo). Folosind geo-location, vizualizarea rezultatelor poate fi realizată recurgând la servicii cartografice precum Google Earth/Maps, OpenStreetMap etc.

Calendar

Level 0 “Back-End”

For the connection with the data providers for mash-up we developed a server in Node.js The servers receives from a client a query and a provider key than ask the provider the query . After that it returns the result to the
client.

The server is a REST API that has the following description:

    • URL: http://whispering-oasis-5942.herokuapp.com/
    • METHOD: GET
    • PARAMETERS: provider -> id for data provider ‘social’ = //ask query on the social provider twitter
      ‘videos’ = //ask query on the video provider vimeo
      ‘photos’ = //ask query on the photos provider flickr
      query -> a string that will be asked to the data providers
    • RETURN: JSON encoded data

Ex:

URL: http://whispering-oasis-5942.herokuapp.com/?provider=social&query=basescu&lang=ro

Result:

jsonresult

Level 1 “Client1”

Some schetches of the first client

Untitledfsdfd

Untitled

Level 2 “Client 2”

Untitd

Untitsdfssgfsgled

Untisdfsftled

Architecture

ClassDiagram

Tutorial

Once you open the application you will see a page like this:

1
Description:

      • Top left Input Box Type query then press ENTER
      • Left Social Post Container , Here the app will show twitter post acording to the query

2

      • Top Right Language Combobox, Here you can change the Language of the query

4

      • Middle and Right Media Content , Images from Flickr , Videos from Vimeo

3

If you want to see the location of a post just click on the location pin

5

6

If you want to see a video click on the play icon from every video thumb

7

Untitsdfssgfsgled

8

Demo

Not Available .

Level 0 “Sketches”

The folowing images represent the first ideas about SOMA design

IMG_1612

IMG_1612

IMG_1609
First Mockup
Download

Level 1 “Question Option Criteria”

In the next step we used the QOC model to refine the design

      • QOC 1
        • Question

How the user will input the keywords?

        • Options:
          • A List of Possible Keywords grouped in Categories . User can choose more items from this list Gesture:Swipe,Tap
          • TextBox with AutoComplete and Hint List
        • Criterias:
          • Easy to interact
          • Intuitive
          • Based on something that the user already knows .
          • Fast
      • QOC 2
        • Question

How the application will desplay the result (Mashup from tweets,photo , video ,map,etc.)?

        • Options:
          • Row List

rowlist

          • Only Map

onlymap

          • Google Style 1

IMG_1609

          • Google Style 2

mockup3

        • Criterias:
          • Easy to find a result
          • Readable
          • Intuitive , based on something that the user already knows .
          • Easy to navigate
          • Maximum Information in Minimum Space
          • Feasible Implementation Cost
      • QOC 3
        • Question

The result will not fit in one page ,How the user will navigate through pages?

        • Options:
          • Dinamic List “Facebook style”

facebook style

          • Paginations

pagination
mockup3

        • Criterias:
          • Easy to navigate
          • Good user Interaction
          • Feasible Implementation Cost

Level 2 “Final Mockup”
mockup
mockup2
mockup3_3

Level 3 “Prototype – Quick Peek for the Final Version”
Soma

Personas

A simple definition of a web persona is: “a summary of the characteristics, needs, motivations and environment of a key type of web site user“.

You can find here 3 examples of personas for our application.
Presentation

Download Here

References