I have an application which has a free and a paid flavor. I am starting to add additional features to the paid version. To this point, the flavor differences have been handled either by a boolean in the build gradle or a couple of different layouts in the flavor folders. The layout differences up to this point existed because advertising code was embedded in the layout xml. Going forward some of these will have unique items/content but most of the new stuff will have its own layouts.
Almost all the additional features will reside in specific classes for the paid flavor. However, I'm a bit perplexed with what to do with a few of my activity classes which begin with a menu of user choices and are for all intents common to both flavors. It seems there is no way, for instance, to use a click listener which references an R.id in one flavor of the layout but not the other. Thus the activity itself must be maintained in two versions.
It seems excessive and cumbersome to maintain two flavors of activity code just to deal with a few non-common lines. I was thinking the best way to handle my very specific instance is to make sure both layouts have all the R.id's necessary for the activity and to hide the unused ones. Not ideal, but less cumbersome than maintaining two versions of the activity.
Is there a better way to handle this in general?
Related
My company is making a 'clone' of its current app, which will mostly have the same functionality, but the UI will be quite different. Some screens only have different colors, while others require different layouts completely.
The app is currently split into multiple modules that can be used in both apps, making future maintenance easier. However, I'm struggling to find a good way of using different layouts for each app in fragments.
Ex: Fragment A has layout X in the first app. Fragment A needs layout Y in the second app, which will be somewhat different but will contain the same views with the same ids.
My current idea: create modules that only contain layout files. Add the modules as an app-level dependency and inject them into each fragment using dagger. This feels like a lot of work and also means that the modules containing the fragments have no reference to the ids in the layouts, making databinding and even findViewById() impossible, unless I also inject the ids. You can see how this becomes a huge problem very quickly.
Another idea: use different flavors in each module for colors and layouts. But this will make building the project quite complicated and it means that the 2 different apps will have to reference different flavors of each module's artifact.
Anyone out there with better ideas/solutions?
Use Flavours (a.k.a. "Build Variants") and create different Layout/Java folders.
/src
/main
/java
/..../ExampleClass.java (don't instantiate/use this Class directly but use Flavour's Extended versions)
/res
/layout/example.xml
/Flavour1 (used by both Debug and Release)
/Flavour1Debug
/java/.../ExtendedExampleClass.java
/Flavour1Release
/java/.../ExtendedExampleClass.java
/res/layout/example_modified1.xml
/Flavour2 (used by both Debug and Release)
/Flavour2Debug
/java/.../ExtendedExampleClass.java
/Flavour2Release
/java/.../ExtendedExampleClass.java
/res/layout/example_modified2.xml
In this way you can use same Class's (the "ExtendedExampleClass") Methods/Fields in all Flavours even if Layout/Resources are different.
Obliviously all Extended Class should expose same Method/Fields or in each Flavours you should create other Classes extensions that use dedicated Methods/Fields.
I am working on an Android app that has several different product flavors. Each flavor has a unique set of libraries it needs, but I don't have this information until runtime. Right now, all the features of the app are packaged into each product flavor, even if that flavor only uses a handful of them. What I would like to do is, at startup, determine which features can be accessed, and download the appropriate libraries it will need. Is there a way that I can determine at first startup which Fragments can be accessed by the Activity?
I'm currently developing an app which is actually available in Google Play and it has two different versions. One of them has full functionality and runs without any advertisement.The other one instead cannot access every feature and shows ads.
I'm managing these two versions with two different android studio projects and
two different repositories.
I just wanted to know how could I manage better the development of these two versions of the same app. I've read something about flavors in gradle but I don't really know if they could be useful in my case. Other thing I've thought about is that maybe I could just have one repository with a branch where I just have different files for those features which are not the same, remaining always the common files update.
So, which is the better way to deal with this situation? Any other ideas are welcomed.
Thanks in advance for your help
Gradle flavors are what you are looking for. With them you can have all the common code and resources in one place, so there is no need to copy it, and the code and resources that differ in another place. Flavors also provide a convenient way to build several versions of the app.
From what you describes it seems that both your versions of the app are almost the same, so in your case you simply need a boolean to differentiate between them:
if (FULL_VERSION) {
unlockFeature();
}
else {
showAd();
}
You could implement this by creating a class for each flavor, one with the constant set to true and one with constant set to false. A more object oriented design would be to have a class that unlocks the feature for one flavor and another that shows an ad for the other.
Note that flavors produce an APKs with different package names, so you can't have an in-app purchase that would unlock features and remove ads.
I am working on some application that has different type of users namely a mechanic and a customer.
Now I have two solutions
1 To make separate applications for both
Pro:
Modular application,manageable and lesser size .
Con:
Code redundancy like login pages for both apps.
2 To make a single application for both.
Pro:
One application caters so overhead saved.
Con:
Lot of thinking and flexible arch. In place is needed.
I am kinda confused ,if someone can guide me with this.It'll be great.
Some sort of examples and links would be superb.
Diagrams would also do.
I guess the most reasonable option would be to have:
A Library Project with the common parts (anything you want to reuse, basically), and
Two Application Projects for the distinct applications.
That way you can reuse the common parts (no duplication) and still keep the specific parts separate.
See Managing Projects in the Android documentation, this precise scenario is listed as one of the main use cases for library projects:
If you are developing multiple related applications that use some of
the same components, you move the redundant components out of their
respective application projects and create a single, reuseable set of
the same components in a library project.
I just finished watching Xavier Ducrohet presentation about gradle, and I am about to start using flavors. I want to understand what are their big advantage over libraries?
I know that android library can have it's own manifest / resources and of course sources, and so does flavors. But what else is there? Why should I use them?
Flavors and libraries aren't really comparable.
A library is typically a discrete piece of functionality that you can reuse across multiple projects. It might provide a piece of functionality that you use frequently or it might provide a custom View that you find yourself using in a lot of applications.
Product flavors are slightly different versions of the same application. The most common example is a paid vs. free app- with product flavors you can have a single codebase that generates both versions. Another more simplified example would be an app that is available in two colors- you might have a red product flavor and a blue product flavor. In this case the only difference might be a single color string in your resources.
Where I think the confusion is coming from is that you can use a library to accomplish the goals of the product flavor system. That is, you can take your common functionality and place it in a library project that you include in each of the versions of your application. This is a messy way to accomplish the goal of having two apps with only minor variation between them, and if this is your goal, you should use product flavors instead.
From the Gradle Plugin User Guide:
If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.