Introducing DroidData (Preliminary)

  1. 1. query/update data and display in view
  2. 2. DroidData
  3. 3. efficiency concern and violation of pattern
  4. 4. conclusion

There are already lots of discussions about the architecture of a quality android application, such as EffectiveAndroidUI, Android-CleanArchitecture, which use some common patterns like MVC, MVP or MVVM. However, what we are going to talk about in this post is not which one of these architectures is the best, but some kind solution while implementing these architectures.

query/update data and display in view

We all meet this kind of use case while using a MVP/MVVM pattern as the diagram shows:
Old Way

  1. View requests/updates data to Presenter/ViewModel
  2. Presenter/ViewModel requests/updates data to ModelDao(the Business Logic)
  3. ModelDao retrieves data(in the form of Model) from Database/Web/Remote and returns to Presenter
    or ModelDao updates data to Database/Web/Remote and returns result to Presenter
  4. Presenter updates View with retrieved data or the result
  5. if we use a RecyclerView, Presenter will need update Adapter to update RecyclerView

As we can see, Presenter part acts as two roles: manipulates data with ModelDao and displays data to View.
Coding often becomes trivial when we implementing the displaying part and complicated when we updating different views with the same data source.
Taking an Excel app for example, displaying all the records requires code like EditText.setText() to bind data with a RecyclerView. Also modifying record requires code to find that specific record in RecyclerView or the corresponding record in detail view, and update them.
(Show a diagram here)

We can skip EditText.setText() part by taking the advantage of Google’s Data Binding library.
But what if we go further and more aggressive and directly bind Database with view through some way, then all the Presenter has to do is updating the Database. Presenter doesn’t need to care when the record is changed or which one of record is changed.
That is where the DroidData based on.


DroidData uses Data Binding(bind data to view), ContentProvider(a native android library providing mechanisms to query data and notify data changes), GreenDao(a light & fast ORM solution for manipulating data in SQLite Databases) to accomplish above goal.
Old Way

  1. View requests/updates data to Presenter/ViewModel
  2. Presenter/ViewModel requests/updates data to ModelDao(the Business Logic)
  3. ModelDao determines if need retrieve data from Web/Remote and saves data to Database;
    ModelDao updates data to Database or updates data to Web/Remote then saves result to Database
  4. ModelDao asynchronously notifies ModelObservable/ContentProvider that data source has changed
  5. ModelObservable/ContentProvider notifies View/RecyclerView, and View/RecyclerView gets refreshed with new data

The step4 and step5 are auto triggered with the generated code by DroidData. This will make our code more

efficiency concern and violation of pattern

All the notifications are triggered by the native ContentProvider.Also, DroidData provides a DDCursorRecyclerAdapter to bind database with view by Cursor, and ModelObservable map is stored with WeakReference.

It seems that DroidData violated the MV* pattern to some extent, because we connect View and Model directly. From another point of view, we actually connect View with ContentProvider which can also be considered as Presenter. Furthermore, DroidData makes test more straightforward. We can test the Presenter without the View.