Modularization has become an essential part of Mobile Development at scale, however it isn’t simple. One of the goals of modularizing effectively is keeping modules independent and the module graph flat. Using plugin interfaces across the modules are one of the most effective techniques to achieve this and get the desired benefits. Let’s have a look at how to use it.

Pic by Tania MT with ❤

The problem

We often face a common scenario during modularization — a single module needs to depend on many other features and compose them together. Imagine application startup initializing different parts of the app — in this situation the startup code has to access many features.

The typical approach is to make our feature dependent on all the relevant modules to be able to reference the code. This might be okay if we depend on very few modules, however it causes several issues once the dependencies grow.

• Coupling: One feature depends on many others.
• Complexity: Aggregation of dependencies in one module.
• Modules graph: Once we have more of these aggregating features, the module graph starts to become much more complex and we can end up with a web of dependencies that’s hard to manage (why it matters).

The problem: the height of the graph grows and modules are tightly coupled.

Use cases for plugins

There are many situations in which you need many modules to contribute towards common logic, where plugins offer a solution. Some examples:

• App startup: Many modules need some form of initialization and need to hook into the Application.onCreate method or a different point in the lifecycle.
• Login or Logout: Different parts of the app need to be set up or cleaned up when the user logs in or out.
• Handling Push: Typically one module is the entry point for receiving push messages, however multiple modules may wish to receive different types of messages.
• Handling deep links: Similarly as push, one module serves as an entry point whilst many modules need to handle different deep links.
• Feature Toggles: A module might want to declare different toggles, however the app might have a single toggle endpoint for all modules.
• HTTP headers: Different modules want to setup common headers for the application.

Solution

The general solution involves a collection of plugins which are composed across modules, collected manually or via dependency injection such as Dagger. We will use a login plugin using Dagger as an example, however the same concept can be implemented via other approaches of passing dependencies.

Plugin pattern— login example.

1. A feature module defines a public plugin interface and expects to receive a collection of instances, implementing the interface.
   Let’s imagine a :login-api module offering an interface which will be used across many modules.

interface LoginPlugin {
  fun onLogin(user: User)
  fun onLogout()
}

2. The :login module consumes the plugins as a collection.

class LoginLogic @Inject constructor(
  val loginPlugins: @JvmSuppressWildcards Set<LoginPlugin>
) {
  ... 
  fun onLogin(user: User) {
    loginPlugins.forEach { plugin -> plugin.onLogin(user) }
  }

  fun onLogout() {
    loginPlugins.forEach { plugin -> plugin.onLogout() }
  }
  ...
}

3. Other modules depend on :login-api and implement their own plugins. For example the :user-theme module changes the theme based on user settings.

class UserThemePlugin @Inject constructor() : LoginPlugin {
    override fun onLogin(user: User) {
      setPreferredTheme(user.prefferedTheme)
    }

    override fun onLogout() {
      setDefaultTheme()
    }
  }

4. The last piece is connecting things together, which could be done using Dagger Multibingings. The :user-theme module uses the @IntoSet annotation to contribute to the Set<LoginPlugin>. All the modules with bindings are then composed within the :app module.

@Binds
@IntoSet
fun bindUserThemePlugin(plugin: UserThemePlugin): LoginPlugin

This article was previously published on proandroiddev.com