The magical magic of Android Studio Flavors

These two days found that Android Studio flavors used to be quite a force! Here to share with you:
flavors Chinese translation called "Taste", do not know exactly what the name is, its function is to allow you to have a number of different versions of the app, different versions of the code can not be the same, such as multi-channel packaging (gee!). So see the Chinese channel is very appropriate ah, haha), can have baidu,360 and so on!
I say this today is not multi-channel packaging, this piece to professional packaging GG, we are here to make the use of project development.

We divide the project into two flavors:

Mock: Analog, where all the data is running apps with well-written analog data

What do you do when you want to develop a new feature, but the server code is not yet ready to be written?
Silly wait, of cause not! We switched to the mock version to continue with the simulation data.

Prod: Real edition, where all the data is running apps with real data

When the server was developed, we have to switch to prod version to tune.

Light says no use, no picture no truth:
Here's my previous article on the project: Android MVP Advanced
Select item, right->open Module Settings open Preject Structure

Paste_image.png
Select Flavors Click "+" Name to fill in the mock and click "+" to add a prod point ok
Paste_image.png
Then watch our app's build.gradle add the following content

android {    ...    productFlavors {        prod {        }        mock {        }    }}

To this step, also did not see what is different. Look, the following changes are starting.
Select App-src Right-new->directory new folder mock

Paste_image.png
Then select the newly built mock folder and right-new->directory the new folder Java

Similarly create a new Prod.java folder, and the result is as follows:
Paste_image.png
Careful you will find the Java folder under the mock is blue, the Prod folder is not, why?
That's because the current default compilation is in mock this flavor
Click the Build Variants open window in the lower left corner to see the app module's current build variant is Mockdebug
You can try to change the mockdebug to Proddebug and back to the Project window, this time prod Java is blue.
Paste_image.png
Back, check Java under the mock, right-new->package create a new package identical to main, this is Cn.huangx.mvpsample3
Paste_image.png
Similarly, switching the build variant to Proddebug also creates a new package, and the result is as follows:
Paste_image.png
Select the built package name right-click New->java class to create a new Modelmanager
Paste_image.png
Then switch to the mock version of the same location also built a modelmanager of the same name.
Note here that the files built in the mock and prod must be the same, and if not in main.
because all the files in the mock version are in Main+mock, the prod version of all the files are in Main+prod .
The final draw is like this:
Paste_image.png
Switch to the mock version (to get used to, this one is often cut to cut) new model package, and under the package to create a new Fakeusermodel class, this is our simulation data class
Paste_image.png
Here's a look at the Fakeusermodel class content:

PublicClassFakeusermodelImplementsIusermodel {Handler Handler =New Handler ();/** * Login * *@param username User name *@param password Password *@param Callback Callback */@OverridePublicvoid login ( final string username, final String password, final Callback Callback) {handler.postdelayed (new Runnable () {//delay 200MS callback, analog network request  @Override public void run () { Span class= "Hljs-keyword" >if ( "Huangx". Equals (username) &&  "123456". Equals (password)) {callback.onsuccess ();} else {callback.onfailure ( "user name or password error (mock)");}}, 2000); }} 

The Fakeusermodel implements the Iusermodel interface, exactly like the Usermodel in Main, in order to differentiate onfailure information by adding (mock).
To understand this, Fakeusermodel is false, main in the Usermodel is called real data, this demo in order to demonstrate, the main does not use the real implementation, remember good!

Then there is the Modelmanager content in the mock:

public class ModelManager {    public static IUserModel provideUserModel() { return new FakeUserModel(); }}

Provides a static method Provideusermodel produces a fakeusermodel.

Switch to version prod, where the Modelmanager is:

public class ModelManager {    public static IUserModel provideUserModel() { return new UserModel(); }}

The Provideusermodel method here produces the real Iusermodel implementation.

The play comes, we go back to main Loginactivity's Oncreateloader method, replace the new Usermodel () with Modelmanager.provideusermodel ()

public Loader <LoginPresenter> oncreateloader ( int ID, Bundle args) {return new presenterloader ( This, new presenterfactory<loginpresenter> () { @Override Span class= "hljs-function" >public loginpresenter create () {return new loginpresenter ( Modelmanager.provideusermodel ()); } }); } 

It's time to happy this step:
Switch to prod version loginpresenter incoming parameters Iusermodel is the real-world Usermodel
Switch to mock version loginpresenter incoming parameter iusermodel is the Fakeusermodel of the simulated environment
The server is not good I cut a mock self, server good I cut prod with you, haha, mom no longer worry about I tune interface!

Code See here

Fairy Ghost
Links: https://www.jianshu.com/p/3ce164863d44
Source: Pinterest
The copyright of the book is owned by the author, and any form of reprint should be contacted by the author for authorization and attribution.

Android Studio Flavors Magical (GO)