Repository layer using Room and Dagger 2 — Android

Saurabh Pant
AndroidPub
Published in
4 min readSep 23, 2017

System should be distributed to layers and each layer should have unique responsibility.

We all have been using SQLite database in our android applications to store data locally. But creating, managing database and then accessing it all over the application is a bit cumbersome. Handling the proper opening and closing of Cursor and database object is also a trauma.

I escaped from the above hell by creating a Repository layer in the application using Room (architecture component and data persistence by Google) and Dagger 2( dependency injection library maintained by Google).

Here is a detailed view of how it looks like to see behind the Repository wall.

Repository behind the scenes

As you can see, all the presenters have a dependency of Repository and they can perform any database related operation with Repository object only. This becomes a single entry point in the database in whole app.

Let’s go a little deeper in it and understand how it actually works.

Starting from the inner most access which is our tables of database. In this example, we’ve two types of tables namely FeedDish and UserDish. We’ve created this using Room.

Feed dish data table created using Room
User dish data table created using Room

We have created respected DAO (Data access object) for each of the tables and have created their objects in AppDatabase.

All of the above implementation is done by using Room library from architecture component.

This was the base of our database. Now we move on to its accessibility.

Now, there are some basic queries that we carry out on our database. These queries would accept and return the Objects of respected class as per request. We want these queries to be such that any of the DataSource type can access them and process them. So make it a generic Interface.

In this example, we’ve two types of data (feed and user) which we want to retrieve from database. So we created two types of DataSources namely LocalFeedData and LocalUserData which are a implementation of DataSource.

Now, these two data sources need to perform queries in database and so they require a dependency of AppDatabase which we provide using Dagger.

AppDatabase is injected via Dagger

We now have our data sources ready to perform queries in database. It is worth noting here that the AppDatabase dependency we injected here is a single instance in whole app which is provided and managed by Dagger. This is how Dagger simplifies dependency injections.

Till now we’ve seen the concrete accessibility to database via data sources. Now we need a channel via which we’ll let our presenters talk to data sources. Hence, we create a Repository Interface.

To access our Repository, we creates its implementation class RepositoryImpl.

Finally we have our Repository layer ready with dependency of all the data sources. These dependencies are provided by Dagger. Dagger maintains a single instance of these data sources and provides whenever required.

So, now we can provide our Repository dependency to any presenter and let it ask for local data of either feed or user.

public class WishlistPresenterImpl implements WishlistPresenter {

Repository repository;
private Context context;

@Inject
public WishlistPresenterImpl(Context context, Repository repository) {
this.context = context;
this.repository = repository;
}

That’s it. Access the repository without managing its sources. Make database related changes directly inside the data sources and don’t bother about the rest.

Hope it’ll help you in some way.

Any criticism is appreciated :).

Happy Coding!

--

--

Saurabh Pant
AndroidPub

App Architect (Native & Flutter) | Mentor | Instructor @Droidcon | Youtube @_zaqua | Writer @Flutter Community