Smart Data Loading in Open Event Android Orga App
In any API centric native application like the Open Event organizer app (Github Repo), there is a need to access data through network, cache it for later use in a database, and retrieve data selectively from both sources, network and disk. Most of Android Applications use SQLite (including countless wrapper libraries on top of it) or Realm to manage their database, and Retrofit has become a de facto standard for consuming a REST API. But there is no standard way to manage the bridge between these two for smart data loading. Most applications directly make calls to DB or API service to selectively load their data and display it on the UI, but this breaks fluidity and cohesion between these two data sources. After all, both of these sources manage the same kind of data. Suppose you wanted to load your data from a single source without having to worry from where it is coming, it’d require a smart model or repository which checks which kind of data you want to load, check if it is available in the DB, load it from there if it is. And if it not, call the API service to load the data and also save it in the DB there itself. These smart models are self contained, meaning they handle the loading logic and also handle edge cases and errors and take actions for themselves about storing and retrieving the data. This makes presentation or UI layer free of data aspects of the application and also remove unnecessary handling code unrelated to UI. From the starting of Open Event Android Orga Application planning, we proposed to create an efficient MVP based design with clear separation of concerns. With use of RxJava, we have created a single source repository pattern, which automatically handles connection, reload and database and network management. This blog post will discuss the implementation of the AbstractObservableBuilder class which manages from which source to load the data intelligently Feature Set So, first, let’s discuss what features should our AbstractObservableBuilder class should have: Should take two inputs - disk source and network source Should handle force reload from server Should handle network connection logic Should load from disk observable if data is present Should load from network observable if data is not present is disk observable This constitutes the most basic data operations done on any API based Android application. Now, let’s talk about the implementation Implementation Since our class will be of generic type, we will used variable T to denote it. Firstly, we have 4 declarations globally private IUtilModel utilModel; private boolean reload; private Observable<T> diskObservable; private Observable<T> networkObservable; UtilModel tells us if the device is connected to internet or not reload tells if the request should bypass database and fetch from network source only diskObservable is the database source of the item to be fetched networkObservable is the network source of the same item Next is a very simple implementation of the builder pattern methods which will be…
