You probably should have used feature modules.

# android

[rkeazor]

You probably should have used feature modules.

[natiginfo]

Good idea. Does it work with library projects?

[rkeazor]

Never tried it with library projects. If your doing it in a lib project it shouldn't matter ... You should be able to create the separate modules and still have the same package name prefix com.modules

[natiginfo]

I will try now. Thanks!

[natiginfo]

@rkeazor I tried it. I set module-one, module-two as feature module. And using implementation project, I added them to library project. However, after compilation, still classes of module-one and module-two are not available on final .aar

[rkeazor]

Lol I dont know what your really trying to accomplish. If things have to be dependent of each , than they shouldn't be separated into modules...

[rkeazor]

Maybe you should rethink the architecture of the lib your creating

[natiginfo]

Well, I want to keep internals in another module, and public classes or interfaces in another module.

[natiginfo]

So, at the end internals module should be included to final compile .aar

[rkeazor]

What lol. Nah dont do that. You can just make a class private lol

[rkeazor]

Like modules normally follow a theme , and cant both the private class and its public interface. So a networking module would contain everything you need to know about networking both the private classes and the public interfaces ..

[rkeazor]

It's crazy to have a internals in a separate module. Because you will always have to have them included in the module with the interfaces lol... modules should only be modules if they can work independently

[rkeazor]

Anyway this is past the scope of this chat, you can just slack me directly

[rkeazor]

Or stackoverflow it

[Max Russek]

I think that this is a really important thing actually. At my work, feature teams used to deliver features as aars to a umbrella app that would compose them. However, since you can’t compose multiple aars into one aar, this meant that individual feature teams couldn’t use modules to separate out their features into modules, which enforces separation of concerns, and allows you to abstract at a level higher than the class or package. Anyway, to answer your question, we looked and looked for a solution and they were all hacky and gross 🙁

[rkeazor]

@Max RussekThe thing is feature modules can have a common base, but the features themselves shouldn’t know about each other. it defeats the purpose of separating them out in the first place

[Max Russek]

The problem is when a feature module should be broken into multiple parts for maintainability. Suppose I have a feature that has both a UI facing component but also communicates with a unique backend service. It would be great to be able to split the feature into two modules, one that contains the UI components, and one that contains domain and data layer components for that feature / service, but so that I could consume both of them, in an intermediate module, that provides the full feature to the consumer.

[rkeazor]

@Max Russek so many layers of abstraction. If your only thing is to separate ui from data layer, than your architecture should be responsible for that. Both MVP and MVVM do separation. . Now if the domain layer needs to be reused by other features, than you can always put it into a separate library module,..