Reputation: 11309
I am planning to split my app, feature-wise into a set of independent modules. Many of the features (modules in my new design) share the image assets and string constants.
If I add the reusable assets in the main/app module then they would be compiled into the APK even if I don't include the modules using them. If I add the reusable assets to all the modules, then I face all the problems that come with redundancy.
What is the correct approach of splitting app into modules ? End-goal of my design is to enable/disable any feature during the build phase (through build.gradle).
Upvotes: 1
Views: 299
Reputation: 1006624
Let's assume that we have App A, and Libraries L1, L2, and L3. L1 and L2 share some common resources and/or assets. From a production standpoint, only one copy of those common resources and/or assets would be included anyway, but redundancy is bad from the standpoint of development (e.g., ensuring you change both copies).
So, I'd create a Resource Module Mfoo that contains those common resources and/or assets. Have L1 and L2 depend upon Mfoo. Have different product flavors(?) of A depend upon various mixes of L1, L2, and L3. Only one copy of Mfoo will be used, as Gradle will net out the transitive dependencies. This is no different than, say, L1 and L2 both depending on support-v13
.
Of course, depending upon how many libraries you have and the mix of shared stuff, you could get into Michael Bay-level combinatorial 'splosions here.
Upvotes: 2