问题
I have been doing some reading on Android flavours and how to use them in SO and other resources such as
1)Building Multiple Editions of an Android App with Gradle
2)Building multiple flavours of an Android app
based on these examples, android flavours are very useful for building multiple editions of the app. but my question is:
Is it a good practice to use flavours in scenarios that service provider and consumer roles have separate app like uber or it is better to build separate projects.
what are the main attributes we need to consider before using flavours?
回答1:
From Android docs:
Product flavors represent different versions of your app that you may release to users, such as free and paid versions of your app. You can customize product flavors to use different code and resources, while sharing and reusing the parts that are common to all versions of your app.
So, product flavors should be used to create customized versions of the same app. Different flavors may differ in some part of resources and functions but they are almost the same app.
For building different apps that are related to each other and share some part of code it is better to use modules. You'll have 2 application modules for apps and a library module which contains a common part of code. Application modules will depend on library module.
回答2:
Creating multiple environments is different from separate apps.
As I think, the best practice is to create multiple environments for each separated app.
Like instance, for many projects, they have 2 apps, one for User and another for Admin. So in that case, we create 4 environments for each app.
Building multiple environments will maximize productivity and reduce bugs that could reach the user. There are 4 common tiers that can be helpful
Development Optional. This is the working environment for individual developers or small teams. Working in isolation with the rest of the tiers, the developer(s) can try radical changes to the code without adversely affecting the rest of the development team.
Integration A common environment where all developers commit code changes. The goal of this environment is to combine and validate the work of the entire project team so it can be tested before being promoted to the Staging Environment. It is possible for Development and Integration to be the same environment (as in the case where the developer does not use a local copy of the source code).
Staging The staging tier is a environment that is as identical to the production environment as possible. The purpose of the Staging environment is to simulate as much of the Production environment as possible. The Staging environment can also double as a Demonstration/Training environment.
Production The production tier might include a single machine or a huge cluster comprising many machines.
A very common use-case that you can delete, edit anything you want in Development environment, but you can't do the same in Production, the only one way is migrating data.
Fortunately, Android Gradle support productFlavors to support us for that stuff.
But, yeah, if you just need one environment for Admin app, which accepts bugs happen frequently, you can define only one environment.
This is a very big topic, may be this answer can help you. This is the common flow for multiple environments
来源：https://stackoverflow.com/questions/45345255/when-to-use-android-flavours-vs-separate-projects