Annyce Davis

ones and zeros

  • Home
  • Public Speaking
  • About Me
  • Courses
  • Life

Dagger Multibinding in Dynamic Feature Modules

June 14, 2019 by Annyce Davis Leave a Comment

We’re adding the use of dynamic feature modules to our app. This will help us to improve build speeds, conditionally include features and decouple our code. As noted previously, we make use of Dagger Multibinding and the Android Job library to handle our background tasks.

When we created our first feature module we ran into an issue when we attempted to move the associated Job classes. Let me walk you through the problem, the solution we settled on and then proposed next steps.

The Problem

Original structure of Jobs in the app module

Inside of the app module we have our JobManager. Its job is to schedule requests, like this:

When a request is received, the JobManager attempts to create a new instance of the desired Job. It does this by means of a JobCreator. The JobCreator holds a multi-bound map which it inspects in order to create a new Job, like this:

And finally, we have a Dagger Module that contains all of the Job bindings so that they can be grouped together in a multi-bound map:

Initially, we created a new Dagger Module for the Jobs that belonged to a particular feature. However, since we didn’t know how to inform the JobCreator about them, no Jobs were scheduled. We ended up leaving all of the Jobs inside of the main app module. Not ideal.

All of the Jobs are in the main app module

The Solution

After lots of digging and trying things out; we settled on the following solution:

  • Base Interface in the app module that feature modules could implement when they had Jobs to execute
  • Separate Dagger Modules and Components in feature modules for Jobs
  • The app module would use Reflection to create needed classes from feature modules

The first thing we needed to do was create an Interface to be implemented in each of the feature modules. This allows us to separate the Jobs and their bindings per feature module using Dagger. Further, by means of the JobCreatorProvider Interface, we can create new instances of JobCreator classes as needed from the main app module.

Here’s a sample implementation in the service module:

In order to get this to work, we needed two new Dagger classes in the service module: ServiceJobsModule and ServiceJobsComponent.

In the ServiceJobsModule you will see that we’ve defined the binding for a Job that lives only in the service module. We’ve also created a binding for our ServiceJobCreator.

Then in the ServiceJobsComponent class we just wire up our dependencies.

We’re almost ready to take advantage of this setup. The final step is to modify how we create our JobManager in the AppModule. We previously only called the addJobCreator method once. That’s because all of the Jobs were located in the same JobCreator‘s multi-bound map.

That’s no longer the case. Instead, we have multiple JobCreators potentially available to us from dynamic feature modules. This means that we will need to attempt creating those objects and adding them to our list of JobCreators. And then we can use the JobManager from anywhere in our project and it will know how to find the Job that needs to be executed.

Here’s a snippet from the final AppModule class where you can see how this all comes together:

The end result is that now we can store the Jobs in their respective modules instead of having them all inside of the main app module. Each feature module has it’s own JobCreator that knows how to create the enclosed Jobs.

Separate JobCreators in each module

Next Steps

Ideally, I don’t like that we have to have separate JobCreators in each module which does essentially the same thing. I would love to be able to only have the distinct Dagger JobsModules and then update the primary JobCreator‘s multi-bound map. I haven’t found a way to do that as of yet.

Resources

If you want to read more about working with dynamic feature modules I would recommend the following resources:

  • Patterns for accessing code from Dynamic Feature Modules
  • Implementing Dependency Inversion using Dagger components
  • Plaid Sample App Source Code

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)

Related

Filed Under: Android, Kotlin Tagged With: Android Job, Dagger, Dynamic Feature Module

Follow Me

What engineering leaders need to know from this year’s Google I/O

I didn't intentionally aim to create a rhyming title, but there you have it. Each year, I look forward to Google I/O like a kid going back to school. This year … [Read More...]

Talk: The Real MVP

You have an idea for a new app. You've secured buy-in from the business. What's next? The MVP. But what does it take to ship a new app these days? What are the … [Read More...]

Categories

  • Android (55)
  • Career (2)
  • Communication (4)
  • Flutter (1)
  • Git (4)
  • Gradle (4)
  • Grails (23)
  • Java (8)
  • JavaScript (6)
  • Kotlin (17)
  • Life (4)
  • Public Speaking (23)
  • RxJava (1)
  • Software Development (7)
  • Twitter (3)
  • Uncategorized (11)
  • Video Course (5)

Copyright © 2023 · Beautiful Pro Theme on Genesis Framework · WordPress · Log in

 

Loading Comments...