First time user of kotlin-inject-anvil, it’s been ...

# kotlin-inject

[Alexandre Gressier]

First time user of kotlin-inject-anvil, it’s been awesome so far! I do have a question: what is the correct approach regarding multi-module projects?

[Alexandre Gressier]

Let’s say I have the following dependency chain between modules:
:network:http ← :network:graphql ← :data ← :app
With the following components:

// :network:http
@ContributesTo(AppScope::class)
@SingleIn(AppScope::class)
interface NetworkHttpComponent {
    @Provides
    fun provideHttpClient(): HttpClient = HttpClient()
}
// :network:graphql
@ContributesTo(AppScope::class)
@SingleIn(AppScope::class)
interface CoreNetworkGraphqlComponent {
    @Provides
    fun graphqlClient(httpClient: HttpClient): ApolloClient =
        ApolloClient.Builder()
            .serverUrl("<http://example.com/graphql>")
            .ktorClient(httpClient)
            .build()
}
// :data
interface AuthRepository {
    fun getWelcomeMessage(): Flow<String>
}
@Inject
@SingleIn(AppScope::class)
@ContributesBinding(AppScope::class)
class DefaultAuthRepository(val graphqlClient: ApolloClient) : AuthRepository {
    override fun getWelcomeMessage(): Flow<String> = {…}
}
// :app
@MergeComponent(AppScope::class)
@SingleIn(AppScope::class)
abstract class AppComponent() {…}

Since :app uses @MergeComponent, it only works if every module depend on eachother via api() instead of implementation() . So that’s definitely not correct.
Looking at the generated code in :app, it makes sense to need api() right now because every single dependency appears in it:

public class InjectKotlinInjectAppComponent(
  appDelegate: Application,
) : KotlinInjectAppComponent(appDelegate),
    ScopedComponent {
  override val _scoped: LazyMap = LazyMap()

  override val viewModelFactory: ViewModelProvider.Factory
    get() = _scoped.get("@ForScope(scope=AppScope)" + "androidx.lifecycle.ViewModelProvider.Factory") {
      provideViewModelFactory(
        viewModelFactory = KotlinInjectViewModelFactory(
          viewModelMap = mapOf(
            provideOnboardingViewModel(
              factory = {
                OnboardingViewModel(
                  authRepository = provideDefaultAuthRepositoryAuthRepository(
                    defaultAuthRepository = _scoped.get("com.example.`data`.DefaultAuthRepository") {
                      DefaultAuthRepository(
                        graphqlClient = graphqlClient(
                          httpClient = provideHttpClient()
                        )
                      // ...

I took a look at the sample app, but since there’s only one :lib module it does not help here. There’s probably something simple that I am missing, but since I don’t know much about Anvil in the first place I’m at loss. Do I need other scopes than AppScope? Any help will be appreciated!

[blakelee]

This is how I've been using it. Even at Square we included every module in our app module with api rather than implementation.

[blakelee]

I have mine split into two primary types though, impl modules and public modules. Impl includes the anvil bindings and public are just the interfaces that I include in whatever modules that need those dependencies

[blakelee]

I'm loosely following this in addition to what I learned at Square https://github.com/android/nowinandroid/blob/main/docs%2FModularizationLearningJourney.md

[Alexandre Gressier]

That’s super insightful, thank you. Indeed, I was wondering how you limit the api surface of your modules then, and api/impl split might be the way.

[Alexandre Gressier]

I heavily inspire myself from NowInAndroid too (but multiplatform), and since you don't necessarily have this issue with Dagger/Hilt I was wondering if I was missing something from understanding Anvil. Thanks 🙂

[blakelee]

I need to write an article about what I learned at Square but my setup is even more robust. A given feature module might look like this

:feature:feature-name:public
:feature:feature-name:impl
:feature:feature-name:impl-robots
:feature:feature-name:test
:feature:feature-name:demo
:feature:feature-name:fake

public can be included in other feature modules and is just the exposed api for other modules to use. No anvil here and it’s usually just plain old kotlin objects. public only imports other public
impl provides the actual implementations for public
impl-robots test robots for app, demo apps, and whatever other modules want to use functionality
test testing utils for other modules (not the tests themselves)
demo an isolated demo app useful for just testing a specific features. I might have just one feature tested through this. Having a demo app means I don’t need to do a whole bunch of other things to get to the screen I want to test. I can just load it up directly in the demo app with whatever conditions I want
fake fakes that can be used for testing. goes great in demo apps or the main app tests. These are the fake implementations of the public module

There’s a few more we used but for a project that isn’t 4500 modules or whatever Square is at now, a few will suffice.

A lot of this might be unnecessary depending on the setup, but having a public and impl module at minimum has saved me a ton of headache.

[blakelee]

The impl modules are all included in my top level app and I just need to include public everywhere.

[Alexandre Gressier]

Thank you for taking the time to write this up—I'm learning a lot. It definitely makes sense for large-scale projects, and it might even be beneficial for a smaller project like mine. I suppose build times benefit from this separation either way, so it might be worth the extra setup anyway.

[blakelee]

With having all of these modules it would probably be good to setup some gradle convention plugins. I ended up making my own gradle extensions and gradle plugins which was very very difficult to do with the available information on the internet. It’s a little off topic for this thread but you can dm me if you want more info.

[ralf]

Hot off the press: https://amzn.github.io/app-platform/ take a look at the sample too. It covers this module structure (I’m the author of the module structure at Square and brought he same to Amazon now) and uses kotlin-inject-anvil. The sample in this project is larger and shows all of this in practice.

[Alexandre Gressier]

That’s truly a blessing—I skimmed through it, and I couldn’t have imagined anything better. Thank you too! (even "App Platform" it self, loved reading the comparison with Circuit but that's off-topic too)

[Alexandre Gressier]

So turned out that the App Platform sample is exactly what I needed to better understand why splitting modules into public/imp is truly beneficial for DI. One thing I cannot wrap my head around though is “that no other module but the final application module is allowed to depend on :impl modules”. Why is the :app module allowed to have :impl at all? Is it solely for generating the object graph? Can’t sub object graphs be generated into submodules and then merged? Why is it not needed in Dagger/Hilt in NowInAndroid for example?

[blakelee]

Yeah they will get merged but if an impl module isn't included in the app module then nothing is depending on it... It's the same if I just make any other module and don't include it anywhere. There would be unused source code. If I don't include a demo module in the app module (don't do this btw) then it just remains a standalone demo app.

One other thing. Impl modules can also be included in demo apps. Usually I use fakes but there's nothing wrong with impl

[Alexandre Gressier]

Okay it clicked! And it actually makes perfect sense. I was thinking too much about :impl as transitive somehow (which is wrong), and not the fact that yeah they would actually be leftovers otherwise

[Elijah Dangerfield]

I have a very similar setup for my KMP project thats using kotlin-inject-anvil. Each feature is split into api and impl.

I am having a problem tho. I have 2 different feature impl modules binding into a set. The app module is supposed to grab that set and use it to build the nav graph.

That works for Android but breaks for iOS 😕

No idea why but the KotlinInjectAppComponentMerged is empty for iOS

[blakelee]

Here’s what my iOS component looks like if you’re interested

/**
 * The final iOS app component. Note that [uiApplication] is an iOS specific type and classes living
 * in the iOS source folder can therefore inject [UIApplication].
 *
 * [rootScopeProvider] is provided in the [IosAppComponent] and can be injected.
 */
@MergeComponent(AppScope::class)
@SingleIn(AppScope::class)
abstract class IosAppComponent(
  @get:Provides val uiApplication: UIApplication,
  @get:Provides val rootScopeProvider: RootScopeProvider
) : AppComponent {
  abstract val deepLinkHandler: IosDeepLinkHandler
}

/**
 * Factory function to instantiate the component. This is necessary, because `iosMain` is a shared
 * source folder and generated components live in the x64, arm64 and simulatorArm64 source folders.
 */
@Suppress("NO_ACTUAL_FOR_EXPECT")
@MergeComponent.CreateComponent
expect fun KClass<IosAppComponent>.createComponent(
  uiApplication: UIApplication,
  rootScopeProvider: RootScopeProvider,
): IosAppComponent

/** This function is called from Swift to create a new component instance. */
@Suppress("unused")
fun createIosAppComponent(
  application: UIApplication,
  rootScopeProvider: RootScopeProvider,
): AppComponent {
  return IosAppComponent::class.createComponent(application, rootScopeProvider)
}

fun getIosAppComponent(rootScopeProvider: RootScopeProvider): IosAppComponent {
  return rootScopeProvider.rootScope.diComponent()
}

[Elijah Dangerfield]

@blakelee Thanks for chiming in! I really appreciate the help 🙂

Right now I dont have a separate iOS vs Android component. This is all via commonMain . Im pretty new to KMP but that should be okay right?

EX:

app
-> commonMain
---> MyComponent

feature1
-> commonMain
---> MyImpl1

feature2
-> commonMain
---> MyImpl2

So each feature is binding into the set in its commonMain and the component I have is created in commonMain too

[Elijah Dangerfield]

Maybe I should make an iOS one that inherits from the commonMain one? Even if it doesnt add anything to it?

[blakelee]

I might be wrong, but I vaguely remember having some issues with commonMain and had to create an iOS source set just to create an iOS component for it to work.

Even if your iOS app component looks like this I think it should start generating that method

abstract class IosAppComponent : AppComponent

I know there’s been some updates since then, but the docs were slightly wrong but there was a workaround

[Elijah Dangerfield]

ooooooh, okay ill try that and report back. Thanks a ton!

[Elijah Dangerfield]

RIP, didnt seem to work:

Works perfectly for android but for iOS I still get Cannot find an @Inject constructor or provider for: Set<com.dangerfield.ante.libraries.navigation.FeatureEntryPoint>


commonMain:

interface AppComponent {
    val featureEntryPoints: Set<FeatureEntryPoint>
}

expect fun createAppComponent(): AppComponent

iosMain:

@MergeComponent(AppScope::class)
@SingleIn(AppScope::class)
abstract class IosAppComponent : AppComponent

@Suppress("NO_ACTUAL_FOR_EXPECT")
@MergeComponent.CreateComponent
expect fun KClass<IosAppComponent>.createiOSComponent(): IosAppComponent

actual fun createAppComponent(): AppComponent {
    return IosAppComponent::class.createiOSComponent()
}

androidMain:

@MergeComponent(AppScope::class)
@SingleIn(AppScope::class)
abstract class AndroidAppComponent : AppComponent

actual fun createAppComponent(): AppComponent {
    return AndroidAppComponent::class.create()
}

[Elijah Dangerfield]

looking at the generated files I can see that InjectKotlinInjectIosAppComponent doesnt have a override val featureEntryPoints like the Android one does:

[blakelee]

Hmm that is strange. Have you tried a clean and build?

[Elijah Dangerfield]

many times 😕

[blakelee]

I’m assuming the set should not be empty on iOS as well? What happens if you try adding any other injectable value also? I wanna see if it’s adding other fields and just skipping that one for some reason

[blakelee]

I have a similar AppComponent but I’m doing something like this

@SingleIn(AppScope::class)
interface AppComponent {
  /** All [Scoped] instances part of the app scope. */
  @ForScope(AppScope::class)
  val appScopedInstances: Set<Scoped>

  @Provides
  @IntoSet
  @ForScope(AppScope::class)
  fun provideEmptyScoped(): Scoped = Scoped.NO_OP
}

[Elijah Dangerfield]

hmmm. Well this makes me think ive configured my project incorrectly. Cause it seems obvious this should work right?

[Elijah Dangerfield]

Or maybe im misunderstanding kotlin-inject?

[blakelee]

Let me move to the thread that you made