#9 ~ Data Source in Fragment Navigation Pattern for Android Development

In android development, there are many things can be improved. There are plenty architecture, design pattern, can implements to boost either performance, extendible, robustness, testable, last but not least easy to maintain.

Today android development is not like i was land for a first day in android. Earlier android development was a bad day. We doesn’t have a good architecture at that time, god object, god activity are a common in that day. We use MVC for develop android application at that time. No Fragment at that time, no MVVM even MVP is not a big deal at that time. We don’t care about Clean Architecture. That day very bad day in Android Development. But, we still use a design pattern to do separate of concern code base.

Currently android development is a big deal. So, many plenty idea coming our from community, Like hottest Kotlin, Android Architecture Component, Single Activity Architecture, Conductor, Fragment Navigation Pattern (which i will explain in this article), Reactive Programming (RxJava), in other hand, I very like when watching Jake Wharton videos on Youtube. That guy very inspiring in my personal learning. And of course Square has plenty libraries to help developer around the globe to improve their development.

So many explanations around internet you can learning by. Such as Academy Realm, FragmentPodCast. Article on Medium, and of course, source code on Github. Any way, i really recommendation to develop android application using Kotlin, no doubt about this.

Fragment Navigation Pattern

First time i know fragment navigation pattern is from this article. But, the funny thing is i using a fragment navigation pattern before knowing this pattern exist, and i not following that article for my development bases. That just gave me a image of pattern itself.

I simple sentence, fragment navigation pattern is, you have single activity with multiple fragment. That opposite with Single Activity Architecture (i will explain it, in different article).

Cases For Fragment Navigation Pattern

A Picture worth thousand words. In above picture, i want to explain about our UI Architecture. In our case, we have many Child UI Component inside of Single View. This because we have dynamically UI Changes regarding response from API.

For example, we have 4 services. each service they have a service detail. In each service detail they have each UI Component. But, in this case to build a component, we use a same Parent View and Child UI Component.

Use Case

In this cases, will explain with representative of each service, such as:

  1. Service A will return UI Component B’, C’, D’, F’, H’
  2. Service B will return UI Component C’, D’, H’
  3. Service C will return UI Component A’, D’, F’, B’
  4. Service D will return UI Component B’, D’, F’, A’

Note: Order are really matter here.

Because we have dynamically changes, and UI Component ordered from API, we cant re-order UI Component in Android side. Each UI Component doesn't have a repository to grep data from either remote or network. Although UI Component doesn’t have business logic to grep data, but UI Component has a presenter to transform data which peek from Data Source.

You might be ask, “who has responsibility to have business logic to get data either from remote or local?”. Answer depend on you, in our cases, we dont use Activity as our parent to have business logic. Activity just act as Container the view (either it custom view or a fragment).

So, we added a layer top of Activity which a Fragment.

In our case, fragment act as a parent which has a use case (domain) and repository (data) to grep data from network and local.

This a presenter looks like,

We push data from fragment to presenter. Below is our datasource code. Remember to remove the data soon if you are not use anymore. we store data at runtime, this is not persistent data.

After we have a data from parent, child UI Component can peek data from their presenter, then transform it finally bind to the view.


With this approach we remove the HARD Way to store data and consume with Child UI Component. There are plenty way we was use, but those are not good enough, too many boilerplate and complexity. Using data source is the best way for us to distribute data.