This post has been republished via RSS; it originally appeared at: Microsoft Mobile Engineering - Medium.
Scaling Teams Mobile Development — Applying the design pattern.
We have gone through the various components of contributor design pattern in part 1 of this series. In this post, we will take a look at an example app which implements this design pattern to make it more concrete.
Ready to get your hands dirty?
Setting the context for the example app
The example app that we will pick for this article is a template app created using the “Bottom Navigation Activity” option provided by Android studio. Go ahead and create new app using this template activity and run it to see how it will look.
We will build exactly the same app, but we will apply the contributor design pattern to it. We will pretend that each of the bottom navigation items are owned by partner teams who collaboratively build this app. We will model the BottomNavigationView area as a contribution site.
Contribution APIs
Let’s start by defining the API contracts for partner teams to work with. Let’s create a module in the project by the name contributor-api and add these interfaces.
This interface represents a generic Contribution. It will have an id and if the contribution is enabled or not. Partner teams can conditionally show or hide their contribution depending on its configurations.
Tip: In real scenarios, it can be extended to contain any common state or behavior, depending on the requirement
IBottomNavigationContribution is a contribution interface specific to bottom navigation item that the partner want to develop and present to the user. It abstracts the requirements from the site. In this example, site requires icon, text, order along with a fragment that can be shown when the user navigates to this contribution by tapping on it.
Tip: Order in contribution means coordination between partners, which is not good. In real scenarios, it can be centralized at the contribution manager level as well. For this example, we will keep it with contribution for simplicity.
Contributor API
Next comes the Contributor interface. We will add this to the same contributor-api module. This has a way to return contributions that it provides. Contributors can potentially return multiple types of contributions.
Tip: In real scenarios, then working with multiple contribution types, its not ideal to keep adding APIs for each contribution type. Generics can be used effectively to address this concern.
Implementing the Contributors
Using the APIs that we defined, partner team creates a module for the partner team that will work on Dashboard. Let’s call it dashboard-contributor. We need to populate this module with Contributor and Contribution implementations
We will not go into the details of DashboardFragment and DashboardViewModel that the fragment uses. Those are similar to the ones that were generated by Android studio sample app that we explored initially.
Similar to dashboard-contributor module, create modules for other partner teams namely home-contributor and notification-contributor modules.
Contribution Manager
We have the partner modules ready with contributors and contributions. Now we need a way to bring them together and query them. We will create a manager for this. We will also provide a way for contributors to register themselves in the system.
Tip: In real scenarios, while dealing with multiple contribution types, we can use generics effectively to have one API in contributor that can return different contribution types.
Tip: Reactiveness is another aspect here. Contributors can come and go dynamically. This can be handled by converting the return types into Flows at various levels and building the ability to emit contributors / contributions when they change.
The manger implementation reaches out to a registry which contains registered contributors, collect contributions from them, filters and orders them.
Let’s take a look at the registry.
IContributorRegistry is a simple interface which returns a bunch of contributors in the system. In the implementation it’s just hardcoded. This can be made more extensible. One option is to have a manifest for each contributor module and generate a registry out of it.
Integrating with app module
In the app module we have a MainActivity and a corresponding MainViewModel.
The view model integrates IContributionManager into the app and exposes them to the view layer. It also provides a way to query the fragment class from contribution.
MainActivity uses the view model to create menuItems that can be added to the bottom navigation view, using the icons and text exposed.
The layout is simple for the MainActivity. It just contains a BottomNavigationView and FragmentContainerView. The navigation view does not have a menu attached intentionally, because menu item will be generated dynamically using contributions returned. The fragment view is the one that loads fragments from the contributors.
That’s all. Now we have all the components of the contributor design pattern implemented.
We have seen how contributor design pattern can be implemented practice. Real world is more complicated than this example. But this should set you in track to think about your specific scenarios. The complete sample example can be found in the git repo here for more exploration. Happy coding!
Scaling Teams Mobile Development — Applying the design pattern. was originally published in Microsoft Mobile Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.