Android's routing framework for Modular development: Launch

1. Overview

More and more I don't want to write code recently, especially some repetitive code, for example, because every time we start an activity, we get used to writing in the activity:

public static void launch(Activity activity) {    Intent intent = new Intent();    intent.setClass(activity, xxxActivity.class);    activity.startActivity();}

I've had two years of experience in Android development, and I'm just saying that there are a number of ways to help us generate similar code:

• By customizing the activity template in Android Studio, you can automatically populate the launch method when you generate an activity class. Android Project templating that dramatically improves Android development efficiency
• Customize the launch code block with Live Templates via the shortcut keys for Android Studio: You don't necessarily know the powerful code blocks in Android studio
• Cute compile-time annotations.

This article focus on the compilation of the framework of annotations, after all, is to be in line with the times!

Hundred Cattle Information Technology Bainiu.ltd organized and published in the blog Park

2. Requirements Analysis

My requirements are simple to start with annotations instead of intent code to launch the Activity, let annotations help us generate launch methods, and be able to use them in component development.
The requirements are clear, so start thinking directly:
All launch methods are very similar, the difference is the end of the jump xxxactivity, then we want to construct a corresponding relationship: by configuring the annotation Launchann to assign a string alias to each Activity, I find this alias, I knew the real Activity of the match. So where I need to start xxxactivity, I can start this xxxactivity by calling an alias, so that startup doesn't depend on xxxactivity, but just an alias string.

3. Development process

Create a three module:

• iocAnnotation: Java lib with compile-time annotations only
• iocCompiler: Can only be Java Lib, not Android Lib (Generate AAR), because we use the Abstractprocessor in the Android environment is not found.
• iocApi: Android Lib, is used directly to the user, the inside will use a little reflection.

The development Note Framework can be consulted on how Android writes projects based on compile-time annotations. Note the point:

• Why do you want three module: Because Ioccompiler is only used when compiling, so in the run time is not used, so we can not pack into the official apk, so in the Gradle file introduced in the way is: Annotationprocessor.
• Ioccompiler has two comments on Abstractprocessor: 1 is done directly in the implementation class through the annotations provided by Google Autoservice, 2 is under the resources meta-inf/services/ Javax.anotation.processing.processor, if there are more than one processor, separate the commas directly.

Define annotations:

@Target(ElementType.TYPE)@Retention(RetentionPolicy.CLASS)public @interface LaunchAnn {    String value();}

Annotations use:

@LaunchAnn("RuntimeActivity")public class RuntimeActivity extends Activity {}

Open activity:

public void onClick(View view) {    Launch.launch("RuntimeActivity", this);}

In the Cakeprocessor (Abstractprocessor implementation Class) in Ioccompiler, a fixed Launchutil tool class is generated. By traversing which classes used the Launchann annotation, and then the value of Launchann ("Runtimeactivity") as the key, the class corresponding to the full path (package name + class name) as value into the Launchutil tool class Map so that I can get the full path to the corresponding class directly through the value values of the annotation Launchann.
The function of IOCAPI is to provide the interface that the user invokes (the content call in the onclick), the launchutil contains the map information corresponding to the annotation, so the key point is to be able to parse the contents of the Launchutil.
Since Iocapi and Ioccompiler do not have a half-dime connection, how can they get to the Launchutil class? This still took me some time, and finally, by defining a Launchinjector interface in Iocapi, the interface to get the class's getpackagename via the key value is implemented. Of course our Launchutil tool is also implemented with Launchinject this interface, so through the reflection Launchutil, directly formed a Launchinjector object, through Getpackagename method, you can get the Class of the Activity that needs to jump.
I feel the introduction of the almost, do not understand the code to see themselves.

4. Adaptive Component Solution

Actually initially just want to be a lazy developer, so I don't have to write launch every time, but the development to finally found that there are a lot of places to learn in front.
because of its own learning component development, so I want to write the annotations into the component. There are 4 module:modulebase, Modulea, Moduleb, and apps. The name can be seen Modulebase is the basic package, Modulea and Moduleb are functional module packages, the final Total Package app module.
Because each module is used launch, so we can find in the compilation of annotations, each Lib will have a launchutil, when the merger will be conflicting (cue class repetition), so we need to tailor different class names for different modules, My side is bound by the module, for example: launchutil$ $moduleA. java. In this way, multiple launcutil classes can coexist.
Now that there are multiple launcutil, how do we summarize all the map information in the Launchutil to get a general map information? This thing I thought for a long, long time, the process experienced two implementations, the first of which proved no, and finally chose the second. Why do you say the first one, because I feel it is still necessary to record:

• first, why not annotate the launchutil generated by annotations, and then get all of the launchutil at compile time to obtain the map, and finally generate a new Launchutilmerge class? My first thought was this, in the generated launchutil, an annotation was also implemented: Mergelaunch annotations, and then generate a mergeprocessor to find mergelaunch corresponding Launchutil class, get each class in the Map, get a total map into the launchutilmerge.
  Imagine this is nice, but in the development process, it is found that because the process of compiling is: Compile Modulea, Moduleb into AAR package, then the app relies on the AAR package and then compiles, and the classes in AAR are in. Class form, then Modulea.aar Launchutil in the app module is a launcutil.class, even if you have mergelaunch compile-time annotations, you can not find Modulea.arr launchutil, because he is a. class file , compile-time annotations are only valid for. java files. In the case of assembly, compilation annotations are for Java classes, so there are compile-time annotations in jar packages and AAR packages that are not available. The result is that Launchutilmerge finally found only the Launchutil in the app module, so the resulting map information is obviously not complete. Analysis to the end, I also gave up, very determined to give up!
• The second, in the first non-solution case, the hand base APK anti-compilation look, actually found that after packaging each module corresponding to the Launchutil is actually in Dex, so there is no way, through the class name to find the corresponding launchutil it? In order to handle the launchutil, I put them under a folder: "Seu.com.util" so that I can just find all the classes under this folder, and now the problem is to find all the corresponding classes by the specified package name.
  Search on the Internet, there really is in the Android environment, through dexfile this class to find the corresponding class name in Dex corresponding to the full path: Android to get the name of all classes in the specified package, ha ha, so I found all the launchutil corresponding to the full path name, Finally, all the classes found by reflection, get the map in each class, merge into a summarized map, including all Launchuann registered Activity corresponding class information, in Iocapi under the Launch class. This way you can start Activit y by passing in a string. 5. Summary of the previous compilation notes for the old driver is actually relatively simple, the development process table is relatively fixed. For the adaptation of component development process, in fact, is a relatively new thing. Because see Ali ARouter is suitable for component development, so oneself is also a bit of bright. Finally, there is a reference to the demo, I hope we have a lot of communication and learning. For a better way to get all the launchutil, welcome to the exchange.
  Deficiencies in existence:
• Just looking for all the classes in Dex, some apk has a lot of Dex files, so make sure all the launchutil are found, need to find all the Dex, this piece is not processed for the time being. After the class is split into multiple Dex there is a study to come back to this piece.
• The project is more suitable for individual learning promotion: Https://github.com/dndxxiangyu/AndroidLearn

Spiced Fish cc
Links: http://www.jianshu.com/p/af2b83af02e1
Source: Pinterest
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

Android's routing framework for Modular development: Launch