Posted by Yuuki.
Qi Bin's blog address:
http://blog.csdn.net/qibin0506
Okay, let’s enter today’s topic. A few months ago, I was fortunate enough to participate in the MDCC mobile developer conference organized by CSDN [clickable]. After one day, I learned about modular development. After coming back, I have been thinking about modules. Some of the advantages of transformation, let alone anything else, providing a pluggable development method is enough for us to be excited for a while~
Then I started to try some small demos and found that the biggest problem in modular development is the communication between components. For example: in the modular architecture, the mall and the personal center are two independent modules. In the development phase, the personal center How do I want to jump to a certain page of the mall? Here we need to introduce a concept of routing. Anyone who has done web development knows that URL routing in most web frameworks is also a very important part of the framework. If you The concept of routing is not very clear, you can take a look at my article first
URL routing design for go web development ( http://blog.csdn.net/qibin0506/article/details/52614290 )
To understand the concept of routing, here is a brief explanation of routing is to play a role in forwarding.
A picture to experience the role of routing, because I do not have UML tools locally, new ones are still being downloaded... 900M+, my internet speed It's a bit unbearable. So I chose KolourPaint to manually draw a magical picture to experience it first.
1 Motivation to implement a routing by yourself
What about our Android development? If we modularize the project and communicate or jump between the two components, the way we generally build Intents will no longer be used. It is very simple, because it is not found in module A. Go to class C in module B. This requires us to customize the routing rules and make a jump around the corner. To put it bluntly, it is to give your class an alias, we don’t use it to refer to it. In fact, I am going to implement it myself I googled some solutions for a route. These solutions can be roughly divided into two types.
-
Completely implement routing by yourself, completely encapsulate jump parameters
- Jump using implicit intent
I have summarized these two methods. I personally think that the first method is too much encapsulated, and even some frameworks are RESTFul like. Such encapsulation is that the learning cost is too high, and the second is that the old project is too troublesome to change. The two ways? Using implicit intent is a good choice, and Android native support, this is also a choice when everyone is trying to modularize development, but this method only supports Activity, Service, BroadcastReceiver, the scalability is too poor Based on the above factors, I still decided to implement a router myself, referring to the limitations above, our router has the following two characteristics.
-
It's easy to get started, and the goal is to implement Activity, Service, BroadcastReceiver calls with a single line of code in the native way.
- With strong scalability, developers can add their own routing implementations at will, not just limited to Activity, Service, BroadcastReceiver.
2 Experience it
Before understanding the specific implementation code, let's first understand how the new route is used, and whether it meets the above two points. First, we first create three modulers, namely the shell app, the mall module shoplib, and the bbs module bbslib. app module This is our shell, we need to use the app module to package, and the app also relies on shoplib and bbslib, so we can 
register the route in the app application. Here are two routes registered, namely ShopActivity of the mall module And the BBSActivity of the bbs module, they are all registered through the static method router method of the Router class, two parameters, the first parameter is the routing address (also can be understood as an alias), and the second parameter corresponds to the class. Registered , The next step is how to use it, let's take a look at how to jump to the BBS module in the mall module.
The main code is in the click event. We call the Router.invoke method. The first parameter is the current Activity, and the second parameter is the route we registered earlier. It is well understood here. The key is to look at its return value. Here is a direct return of an Intent, which is the best~ Returning an Intent means that the code below is no different from our original method! This is in line with the simple purpose of getting started.
As for the second goal, high scalability, you can implement the Rule interface to customize the routing Rule, and then call the Router.addRule(String scheme, Rule rule) method to register the routing rules. The definition of the Rule interface is as follows,
To explain, the first is the two paradigms of the Rule interface.The first T is the type of routing we registered, such as the Activity type used earlier, and the second V is the return value type of the invoke method, such as the Intent type used earlier. As for the custom code, I'm sorry here~, no demo is provided~~~ You can try to customize it.
3 routing code that implements
Then we began to enter the code that implements aspects - to be in the code before, or the first to understand the structure of a picture of this Router.
With the above picture, let's look at the code. First, let's look at the Router class. After all, we are dealing with Router when we use it.
Ha, the code of Router is very simple, it mainly acts as a static proxy, the main code is still in RouterInternal, let's take a look at the structure of RouterInternal.
First of all, RouterInternal is a singleton. A mRules variable is used to store our routing rules. In the construction, we have registered three default routing rules. These three routing rules can be known as Activity, Service and BroadcastReceiver without even thinking about it. Let's look at other methods next.
The addRule method is the implementation of adding routing rules, here we are directly adding to the HashMap of mRules.
The function of getRule is to get the rules based on the pattern. This is a private method, so you don't need to care about it when you use it. Its principle is very simple, which is to match the scheme according to your pattern to get the corresponding Rule.
This router method is our implementation of adding routing. First, we obtain the corresponding Rule according to the uri of the route, and then call the router method of the Rule. As for how the Rule.router method is implemented, we will see later~
The invoke method is the code executed when we call. The return value T is the type specified in the returned Rule paradigm, such as the previous Intent. In
summary, we find that RouterInternal is actually a class that manages Rule, and the specific call is still Implemented in each Rule. As mentioned above, Rule is an interface. It has two paradigms, corresponding to the return value type of invoke and the type of the class we want to route. Let's take a look at the default How several routing rules are implemented.
For the call of Activity, Service, BroadcastReceiver, to summarize, they are actually the returned Intent type, so we can first build a Base type that specifies the return value is Intent.
Not much to say about the router method, we still add key-value pairs to the Map. In the invoke method, we use the pattern in the parameter to return from the mIntentRules target class, and then construct an Intent to return. The last throwException is an abstract method that is used to call the non-router It can be found that most of the implementations are implemented here. For Activity, inherit this BaseIntentRule, and specify the type of routing class to be Activity, and implement the throwException method.
ActivityRule first inherits BaseIntentRule and specifies that the paradigm is Activity. The implemented throwException method is also very simple, that is, an ActivityNotRouteException exception is thrown. For this exception, you can find it in the source code download section at the end of the article~ After reading the implementation of ActivityRule, In fact, the implementation of the other two default rules are the same~ Let's look at the code for yourself.
In fact, it is very simple to implement a route. The principle is to define an alias for the class we want to route, and then call it through the alias where it is called. And when encapsulating, try to conform to the current user's usage habits, don't over-encapsulate and ignore The user's feelings.
Ok, this article is here, the code in the article can be found in a small demo of modular development at https://github.com/qibin0506/Module2Module~
If you have a good article and want to share it with everyone, you are welcome to submit it, and you can directly submit the article link to me.
Welcome to press and hold the picture -> identify the QR code in the picture or scan and follow my official account:
