Hi everyone. I have a multi-module project where I...

# android

[shock 11]

Hi everyone. I have a multi-module project where I have two modules basically. One called core:presentation and the other called featurelistui. I created a BaseViewModel-like Implementation in the core:presentation module. It is basically an 'Open' class that extends the ViewModel class and an interface. I have a viewModel in the featurelistui that Implements this BaseViewModel-like Open class in the core:presentation module. When I try to run the project, this is the error that I encounter.

Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath: class com.mvitemplate.feature.list.ui.ListScreenTestViewModel, unresolved supertypes: com.mvitemplate.core.presentation.mvi.FlowTestClassViewModel Adding -Xextended-compiler-checks argument might provide additional information.

[shock 11]

Then this is my code.
In the core module, this is what I have

interface BaseViewModelTestClass {
    val value: String
    fun emit(test: String)
}


open class FlowTestClassViewModel(

): ViewModel(),  BaseViewModelTestClass {

    override val value: String
        get() = ""

    override fun emit(test: String) {

    }
}

[shock 11]

And then in my feature:list module, this is how I use the class

@HiltViewModel
class ListScreenTestViewModel @Inject constructor():
    FlowTestClassViewModel() {

}

[shock 11]

And yes I have already added a dependency to the core module in the build.gradle.kts of the feature list ui module. I have also made the two build.gradle.kts of both modules to share the dependencies that I think are relevant although, not all of them

[agrosner]

Probably need to declare the dependency for core in. The app build gradle. Or make the core dependency in the ui module an api dependency

[shock 11]

Okay let me try these suggestions

[shock 11]

Thanks! Both suggestions actually worked, but I chose to go with the first one

[shock 11]

But why did this work if I may ask?

[agrosner]

Implementation dependencies do not expose the classes to transitive modules . So if you have A, B implementation A, while C includes B. C cannot see the classes in A. You have to either depend on A directly in C, or expose A via B.

Good rule of thumb is, if the dependency leaks into public api of the B module, declare A as an API dependency when using dagger or DI tools to prevent this error. It seems strange to me to include feature modules but then also have to bring all of the features dependencies in the app module directly just because of it

[shock 11]

Oh this explanation makes a lot of sense

[shock 11]

So the A module here is my app module, because I actually am instantiating the ViewModel in my app module, my app module doesn't know what is going on the core:presentation module(which is where the BaseViewModel lives) but is calling the feature module. So to make it known like you said, we should expose it via the api keyword and not Implementation or just add it directly, which is what I did. So the transitive module here is my app module right?

[shock 11]

I am actually explaining this based on my project setup in line with your explanation. And you are right, it does seem strange to add feature module dependencies with the api keyword, that was why I chose to go with the first solution