See Android third-Party SDK architecture practice "reproduced" from Friends Alliance micro-community

See Android third-Party SDK architecture practice "reproduced" from Friends Alliance micro-community

"First write in front, I would like to reprint this article through the link, found that there is no relevant button." Surf the internet, all said that the blog Park does not have this function. I also have a period of time in the blog park, to encourage the original is necessary, but the appropriate reprint is also a valuable article to share the way, do not know later will not support it! ”

Original link: http://www.csdn.net/article/2015-05-08/2824648-micro-community Summary:The development of a third-party SDK takes into account a number of factors, such as stability, flexibility, and the ability to allow developers to freely customize the UI layer and replace the subsystem. This article takes the Friend Alliance Micro community as an example to explain in detail the design concept of architecture in developing the SDK.

Developing the Android third-party SDK is not difficult, but it is not easy to say, to develop a third-party SDK for many people, how to ensure stability, enhance the flexibility of the SDK, so that developers can freely customize the UI layer, replacement subsystem, this is a question worth thinking about. To solve this problem, the development of a third-party SDK must have a good application architecture. This article will share some of the architectural ideas I have in developing the Friends Alliance Micro Community SDK.

The Alliance's micro-community is a way to help developers quickly build a community in their apps (similar to Sina Weibo, Friends Circle), which is currently under beta.

Technology Architecture

From the project structure, the Friends Alliance micro-Community SDK can be divided into the following three layers simply.

• UI layer (open source). The UI layer is open to the user to be able to customize the UI effect of the micro-community so that the micro-Community SDK can be incorporated into the user's app naturally.

• The business logic layer. The business logic layer provides functionality such as data requests to the UI layer through a unified interface, such as obtaining a cached feed, a friend list, and so on, so the business logic layer is a data manipulation interface for the user through which the user can perform some data operations with the SDK core layer.

• Core layer. The core layer contains the core system abstraction of the Friend Alliance SDK, such as account system, push, database, network operation, etc., this layer is closed externally, the user can interact with the core layer through some interfaces. The abstraction of the core layer definition allows the user to easily customize the implementation of the abstract interface, and then inject the specific implementation into the micro-community, so that their subsystems replace the default implementation in the micro-community.

1, the SDK hierarchy is very clear, through the three levels of isolation, so that users can both customize the outermost UI effect, but also hides the business logic layer, the core layer of implementation details. The core layer defines the subsystem abstraction, which allows the user to inject their own implementation, ensuring the flexibility and extensibility of the entire micro-Community SDK.

Figure 1 Onion Structure diagram

Simply put, the user operates the SDK at the UI layer through a common interface exposed by the logical layer, fetching, storing data, and other related operations from the closed core system. As shown in Hierarchy 2.

Figure 2 Hierarchy Chart

Figure 1, Figure 2 shows that the SDK is the separation of responsibilities through different levels, is a more typical form of architecture. For the user, the most concern is the customizable. UI layer open source, can naturally be modified by code to achieve. Other custom users need to rely on injection to implement. The micro-Community SDK is internally dependent on abstraction and does not depend on the implementation, and the user can inject concrete implementations. This means that the user can implement their own subsystem according to our abstract interface, and then inject into the SDK, the SDK will use the implementation of the user injection, so as to achieve the effect of subsystem replacement, that is, we say the customization.

How does the Friend Alliance micro-community customization meet customization?

So how to achieve customization? Friends Alliance Micro Community SDK Internal definition of some abstractions, such as loginable, pushable, imageloader to represent the login system interface, push interface, picture loading interface, each interface has a sdkmanager to manage. For example, the management of the login subsystem is Loginsdkmanager, the user can add to the manager, remove the specific login system implementation, and then through the Usethis function to specify the use of a specific implementation (SDK Manager may have multiple implementations). The structure is shown in Figure 3.

Figure 3 Loginsdkmanager function

The SDK manager is a generic class, and type T represents the interface type, such as the loginable above. Generics allow us to abstract these common additions, removal implementations, and so on, to avoid duplication of code. The code looks like this:

Public abstract class Sdkmanager<t> {

Generic map

Private map<string, t> mimplmap = new hashmap<string, t> ();

The key of the implementation to use

Private String Mcurrentkey = "";

public void Addimpl (String key, T Impl) {

Mimplmap.put (Mcurrentkey, Impl);

}

public void Removeimpl (String key) {

Mimplmap.remove (Mcurrentkey);

}

public void Usethis (String key) {

Mcurrentkey = key;

}

Public T Getcurrentimpl () {

Return Mimplmap.get (Mcurrentkey);

}

}

The code is simple, which is to maintain a map,key within the SDK Manager is a string value specified by the user for the implementation, and value is the specific implementation. The user can remove the implementation through this key, and more commonly we need to call the Usethis (String key) interface to specify the use of a specific implementation.

We do not use Sdkmanager directly because it is an abstract generic class, so we define subclasses to manage different implementations, all of which are singleton classes, such as Loginsdkmanager, as shown in the code below.

Public final class Loginsdkmanager extends Sdkmanager<loginable> {

Single-instance objects

static Loginsdkmanager sinstance = new Loginsdkmanager ();

Private Loginsdkmanager () {

}

Get Singleton objects

public static Loginsdkmanager getinstance () {

return sinstance;

}

}

When the user needs to manage the login system, through Loginsdkmanager.getinstance () can obtain to the management login system of the SDK manager, at this time the user can pass Addimpl (String key, T Impl), The Usethis (String key) interface manages the login system, which allows for flexible use of user-defined subsystems.

Example

Here's an example to illustrate the problem. In the process of communicating with users, we find that the login module is the most user-defined subsystem with the highest probability. Typically, users may have their own account system or use a third-party login, the user does not need the Friend Alliance Micro Community SDK included in the login implementation, completely rely on their own account system or other third-party login SDK to implement a login system. Let's demonstrate the customization process by implementing a login system (like the custom principle of other subsystems). Before we get started, we need to understand the loginable of the abstract interface for login. The code looks like this:

Public interface Loginable {

public void login ();

public void logout ();

public boolean islogined ();

}

• Login (): Login function, the user needs to log in after the successful user information back to the Friends Alliance Micro Community SDK (the process can refer to the Friend Micro Community Integration document HTTP://DEV.UMENG.COM/WSQ/ANDROID/DETAIL-INTEGRATION#1) ；

• Logout (): Log out function, log off the user login can;

• Islogined (): Whether the user is logged on or not, returns true to indicate that they are logged in or not logged in.

Within the Micro Community SDK, a few simple interfaces are abstracted to define the function of the login module, and the user can customize their login system by implementing these functions, and finally inject the implementation into the SDK. For example, if you already have your own account system logic in your application, you can implement these functions by calling your account system logic in several functions of loginable, and if you use the Friends social component then you can do so with the login and logout function of the social component. For example, you can call the Umsocialservice object's dooauthverify (context context, Share_media platform, Umauthlistener Listener) in the login () function interface to implement login.

In a nutshell, you can customize a class that implements the Loginable interface by invoking your original login, logout, or login function in each function of the class to implement the corresponding function. After the login class is implemented, the implementation is injected into the SDK via Loginsdkmanager's Addimpl (string key, Loginable Impl), and finally through Loginsdkmanager usethis (string Key) function to specify the login implementation to use, this key is the key set in Addimpl (String key, Loginable impl).

The sample code for the custom login class is as follows:

/**

* Friends of the social components of the login implementation, here can be replaced by their own account system, third-party login, and so on, to achieve a number of interface functions.

*/

public class Socialloginimpl implements Loginable {

@Override

public void Login () {

The specific implementation of the login, you can call your own login code or the third-party SDK login function

}

@Override

public void logout () {

Log out of the specific implementation, you can call your own login code or the third-party SDK login function

}

@Override

public Boolean islogined () {

Detecting whether to log in

return TRUE/* code omitted */;

}

}

* * Inject Login Implementation:* *

Log in to System Manager

Loginsdkmanager loginmgr = Loginsdkmanager.getinstance ();

Key

String Clzkey = SocialLoginImpl.class.getName ();

Injection implementation

Loginmgr.addimpl (Clzkey, New Socialloginimpl ());

Specify the specific implementation to use

Loginmgr.usethis (Clzkey);

To make it simpler, the process is encapsulated in a function, and the code used is finally simplified to:

One line of code is done! This function encapsulates all of the above code.

Loginsdkmanager.getinstance (). Addanduse (New Socialloginimpl ());

With these steps, the login system is replaced. When a micro-community needs to log in, the micro-Community SDK will get the login implementation currently in use via Loginsdkmanager and then trigger the login () function, and your login code will be executed. After successful login, through the login () function callback Listener (This simple example does not give the listener, specifically can refer to the Friend Alliance Micro-Community using the existing account system) to transfer user information back to the league SDK, completed the entire login process.

At present, the Friends Alliance micro-Community SDK is still in the beta phase (application address: http://wsq.umeng.com/), but can be put into use. Some of the apps that have integrated the Friends Alliance Micro Community are online and running well. I hope this article can have a third-party Android SDK to help some students, so that the development of the pit less.

See Android third-Party SDK architecture practice "reproduced" from Friends Alliance micro-community