https://kotlinlang.org logo
#android
Title
# android
r

rkeazor

06/08/2018, 11:15 AM
You probably should have used feature modules.
n

natiginfo

06/08/2018, 11:15 AM
Good idea. Does it work with library projects?
r

rkeazor

06/08/2018, 11:18 AM
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
n

natiginfo

06/08/2018, 11:18 AM
I will try now. Thanks!
@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
r

rkeazor

06/08/2018, 11:40 AM
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...
Maybe you should rethink the architecture of the lib your creating
n

natiginfo

06/08/2018, 11:47 AM
Well, I want to keep internals in another module, and public classes or interfaces in another module.
So, at the end internals module should be included to final compile .aar
r

rkeazor

06/08/2018, 12:00 PM
What lol. Nah dont do that. You can just make a class private lol
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 ..
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
Anyway this is past the scope of this chat, you can just slack me directly
Or stackoverflow it
m

Max Russek

06/09/2018, 6:11 AM
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 🙁
👍 1
r

rkeazor

06/09/2018, 7:12 AM
@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
m

Max Russek

06/09/2018, 7:31 AM
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.
👍 1
r

rkeazor

06/09/2018, 11:25 AM
@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,..
7 Views