Essential Guide For Designing Your Android App Architecture: MVP: Part 3 (Dialog, ViewPager, and Adapters)
I am extremely happy that the MVP architecture that we built in part 1 and part 2 together in this article series was very well received and the project repository itself got polished since its release, through your inputs and pull requests.
During the course of this development, many of you inquired about the implementation of Dialogs and Adapter based views in this architecture. So, I am writing this article to explain the place-holding for these.
In case you have not read the earlier resources then I would highly recommend reading those before going along this article. Here are the links for the resources:
https://github.com/janishar/android-mvp-architecture
In this article, we will extend the architecture with the addition of a rating dialog and feed Activity.
Beauty lies in precision.
Let’s list down all the features and use cases first:
RateUs Dialog
- The rating dialog will display 5 starts for selection to the user as per his app experience.
- If stars < 5 then we modify the dialog to reveal a feedback form asking the improvements.
- If stars = 5 then we will modify the dialog to show play-store rating option to take the user there to add review.
- The rating information will be send to the app’s backend server.
Note: The rating dialog is non-required featured from the user’s end but is highly valuable from the developer’s end. So, the app has to be very subtle to enforce this.
I recommend using large spaced intervals between two consecutive programmatically rating dialog display.
Feed Activity
- This activity will display two tabs.
- Tab 1: Blog feed cards.
- Tab 2: OpenSource feed cards.
Blog Feed Tab
- It will fetch the blog data from server API.
- The blog data will be populated as cards in the RecyclerView.
OpenSource Feed Tab
- It will fetch the repositories data from server API.
- The repositories data will be populated as cards in the RecyclerView.
Now that we have defined our features list and use-cases, let’s sketch the architecture for their realization.
I won’t be adding the entire class code snippet here because it obstruct the focus because of the length. So, what we will do instead is that, we will open the MVP project in the next tab and switch between them.
Sketch:
We will add below-mentioned base classes
(see inside com.mindorks.framework.mvp.ui.base
package in the project)
- BaseDialog: This handles most of the boiler plate and adds common functionality for the actual dialogs that will be built upon them.
- DialogMvpView: This interface defines the APIs for the Presenter classes to interact with the Dialogs.
- BaseViewHolder: It defines the framework for RecyclerView binding and auto clearing the views when the ViewHolder is recycled.
public abstract class BaseDialog extends DialogFragment implements DialogMvpView
A note for the architecture: All the relevant features should be grouped together I call is encapsulating the features, making them independent from each other.
- The dialog access is made available through the Drawer.
- The implementation is similar to any MVP view component that we saw in part 2 of the article.
Switch to the next tab on your browser and study it’s implementation in the project repo thoroughly.
A note for the Dialog
Sometimes there may be a case for many small dialogs, then we could create a common mvpview, mvppresenter and presenter to share between them.
- This package contains the FeedActivity and its MVP components along this FeedPagerAdapter, blog package and opensource package.
- blog: This package contains BlogFragment and it’s MVP components and BlogAdapter for RecyclerView.
- opensource: This package contains OpenSourceFragment and it’s MVP components and OpenSourceAdapter for RecyclerView.
- The FragmentStatePagerAdapter creates BlogFragment and OpenSourceFragment.
Never instantiate any class in any Adapter or else where using new
operator instead provide them through modules as a dependency.
OpenSourceAdapter and BlogAdapter is an implementation of RecyclerView.Adapter<BaseViewHolder>
. In the case where no data is available then an empty view is shown that displays forced retry for the user and is removed when the data appears.
The pagination for API data and network state handling is left as an exercise.
Go through the project now to study the code. Focus on the branching and also how view is defined in XML as well as programmatically.