Hi Mark :)

hello, Leora!

how can I help you today?

Hi, we have a project with several library modules (that we own) and I would like to propagate the buildTypes I have to the children

I have not done much with that, sorry

But everytime I try and comment out the buildTypes that are copy/pasted across all modules it throws erros

oh...just saw your reply

what sort of errors?

that it doesn't find the variant X in child blah blah

I have seen people asking about that in Stack Overflow, but I have not encountered it personally, and I do not recall what the solution was

note that solutions have probably changed a few times in recent years, as Google keep changing how this aspect of Gradle works

and in the build Variants box on the left in AS, it lists all the modules with the option to set build variants on each one, which we really don't need

yeah I didn't see any solution on SO

I am sorry that I can not really help you on this

Well at least this confirms that I checked your book thoroughly before bothering you ;)

Maybe you can suggest a good (human readable) reference for this?

off the top of my head, no

if I ran into the problem, I'd be in the same position as you, in terms of searching around for options

Ok thanks Mark, have a great one :)

you too!

I wonder if I can leave the buildTypes 'titles' and but leave what's inside them empty in the libs...

maybe it will take from the main all the specifics inside the brackets

by "inside the brackets", you mean that you are configuring the build type?

yes

you could always define constants and use those, both in the app module and the library modules

for example, applicationIdSuffix ext.titlesSuffix

where you define ext.titlesSuffix up in the top-level build.gradle file, or some other common location

true

but i would like not to write the pinters in EVERY modules gradle

perhaps there is a way using "apply from:" to handle this

I haven't tried that inside a particular closure, such as a build type

hmmm

but apply from: "../common.gradle" basically serves as the Gradle equivalent of #include in C/C++

well thanks. I'll continue tinkering and waiting for build times [snooze]

pulling in whatever you have in common.gradle (or whatever you choose to name it)

yeah it IS common hhhhh

all right thank you!

Hey Mark, Good Morning!

hello, Anshul!

how can I help you today?

I come with some app architecture related question today. I want to know if it is possible to break an existing app into 3 different play store apps with different user flows but keep the same codebase. How can I go about achieving this?

in terms of the three different apps part, you can use product flavors for that

at least, if the "different user flows" are not *too* different

IOW, it unclear me how "different user flows" and "keep the same codebase" can work together

(sorry, that should be "it is unclear to me"...)

if your changes are minor, product flavors can handle it

otherwise, put the common code into a library module, and have three separate app modules for the different apps

Hmm, but that won't necessarily lead to 3 different play store listings, would it? Its different in terms that the app names would be different as well as logos and description, but underneath the codebase would be the same with some minor changes in user flows

"but that won't necessarily lead to 3 different play store listings, would it?" -- well, you have to actually create the listings yourself

but each product flavor can have its own applicationId value

along with different resources, different manifest entries, different assets, and even replacement editions of Java/Kotlin classes

Ah, I did not know that. My limited knowledge told me that product flavors are, for example, free/premium, but in the end, they are the same app...

your scenario is no different than free/premium

free/premium would also involve multiple Play Store listings, if you set them up using product flavors

(versus having just one app that uses in-app purchases to enable premium features)

Hmm, I did not know that either. So, in order to achieve that, I would have to extract the code out of the monolithic /app module and divide it into different modules? with each different play store listings in different modules -> leading to different package names, but the common code shared between them an be in, say a /core library module? Am I going in the right direction?

well, again, it depends on what you want to change

you wrote: "Its different in terms that the app names would be different as well as logos and description, but underneath the codebase would be the same with some minor changes in user flows"

for that, you may be able to get away with product flavors

assign each its own applicationId (so you have unique values for the Play Store)

assign each its own string resource values for any text

assign each its own drawable resource values for any logos

how you handle "some minor changes in user flows" depends on the nature of those changes

if it is something that could be handled by simple flags, define BuildConfig constants in your product flavors in Gradle, and your Java/Kotlin code can branch based on those constants

if you need to do a bit more than that, you might be able to get away with having 1+ Java/Kotlin classes defined in the product flavors' source sets, instead of main, so you can have different implementations per flavor

for substantial changes, though, I suspect having a common library module, with per-app modules using it, will be a simpler solution

Hmm, well, for one, the features are the same, but the order in which users get those features in the app are different, for example, some users might get the feature early on when they log in, and the same feature, other users can get at later stages.

I can't say whether or not using product flavors or separate app modules would be the better choice for that

I think the question also ties into making the app more modular and testable as well (but this is more of a side effect), instead of just one /app module. I was thinking if I have to split in 3 different play store listings, might as well, make the app more modular and apply test coverage as well

"modular" != "modules in Gradle" :-)

IOW, I don't see how any of this will make testing easier, though I can see how it will make testing harder

Ah, that is GTK. :) I have not done any testing on the code as of now, and after reading up on clean architecture and knowing what we can achieve having different modules in gradle for different layers of the app, I thought, in my silly head, that this can achieve both purposes that I want. Different apps, more modular/interface laced codebase leading to easier testing

having a modular codebase helps with testing

but it is unlikely that splitting code into modules will help with testing

despite our ability to invent new nouns, we tend to overuse things like "module" :-(

Ah, so you are saying that I can achieve the same thing within the /app module but having different "modules/packages" within the /app to achieve the desired result?

using different Java packages can help enforce a modular codebase

it's not a requirement

Note to self, read up on product flavors :)

Hmm, the current condition of the app, it's a dependency hell, not at all easily testable. There are so many God activities doing so much of work, I want to steer the app in the direction of a known app architecture, such as MVVM, along with incorporating the use of Jetpack and some standard libraries like Dagger2/RxJava2, but my limited knowledge halts the progress. You can say, I am not sound for taking architecture level decisions for the app, but I would definitely like to give this a try

that sounds fine... but having multiple Gradle modules are not necessary to achieve that

having multiple Gradle modules for your three-apps-on-the-Play-Store requirement might be appropriate (if you decided you need more than product flavors)

IMHO, the three-apps-on-the-Play-Store work is independent of the make-the-code-more-modular-and-testable work

Ah, thank you for telling me that!

I would definitely look into this more before I come bothering you again with questions :)

you are welcome to bother me with questions -- that's the point behind the office hours!

Haha, thank you for all your help, Mark! I appreciate it.

You have a good day!

you too!

note that the transcript of this chat will be posted to https://commonsware.com/office-hours/ shortly

the next chat is Saturday at 4pm US Eastern