Technical Architecture of Community SDK in Android applications

Technical Architecture of Community SDK in Android applications
Analysis of the technical architecture of the Community SDK in Android applications what is the microcommunity in the app?

Figure 1	Figure 2 snowball finance application community

1. Taking umeng micro-community as an Example

In short, umeng's micro-community is a product that helps developers quickly build a community (similar to Sina Weibo and friends circle) in their applications. In many applications, developers often need a community where users interact with developers, users often choose various interaction methods such as likes, comments, attention, forwarding, and posting in the community. However, developing a social system is not that easy. Complex user relationships, message flows, and server architecture are all tricky issues. More importantly, everyone is working repeatedly! Every developer needs these features to build such a highly cost-effective social system from the very beginning. Umeng has launched the umeng microcommunity SDK (internal testing stage) to solve these problems. It allows you to quickly build a community by integrating the SDK, this greatly improves productivity and user activity.

1.1 features of umeng micro-community: open-source UI; can be embedded into existing applications as sdks; can generate independent apps with one click; can be customized by core components such as Account System and image loading; advanced anti-spam, automatically clear junk information;

3. Figure 4 shows the integration effect of cloud map TV.

Figure 3	Figure 4

Ii. Technical Architecture

In terms of project structure, umeng microcommunity SDK can be divided into the following three layers:

UI Layer (Open Source)
The UI Layer is open to the outside, so that users can customize the UI Effect of umeng micro-community, so that the micro-Community SDK can be naturally integrated into the user's App.

Business logic layer
The business logic layer provides data request and other functions to the UI Layer through a unified interface, such as obtaining cached feed and friend lists, therefore, the business logic layer is a data operation interface for users. Through this interface, users can perform data operations with the SDK core layer.

Core Layer
The core layer contains the core System Abstraction of umeng SDK, such as account system, push, database, and network operations. This layer is closed to the outside, and users can interact with the core layer through some interfaces. The abstraction defined at the core layer allows users to easily implement customization, that is, implementing abstract interfaces on their own, and then injecting specific implementations into the umeng microcommunity, so that your sub-system can replace the default implementation in the micro-community (an example is given below ).

As shown in Figure 2-1, umeng micro-Community SDK has a clear hierarchy. With these three layers of isolation, you can customize the UI effect of the outermost layer, it also hides the implementation details of the business logic layer and core layer. The subsystem abstraction defined by the core layer allows users to inject their own implementations, ensuring the flexibility and scalability of the entire microcommunity SDK.

Figure 2-1 onion structure

To put it simply, the user operates umeng micro-Community SDK through common interfaces exposed by the logic layer on the UI Layer, and obtains and stores data and other related operations from closed core systems. The level 2-2 is shown.

Figure 2-2 hierarchical structure

Figure 2-1 and 2-2 both show that the umeng microcommunity SDK separates duties at different levels and is a typical architecture. Users are most concerned about customization. The open source code of the UI layer can be implemented by modifying the code. Other customized users require dependency injection. The umeng microcommunity SDK relies on abstraction rather than implementation, and users can inject specific implementations. That is to say, users can implement their own subsystems based on our abstract interfaces, and then inject them into the SDK. Then, the SDK will use the user injection implementation to achieve the effect of subsystem replacement, that is, customization.

3. How can we customize the micro-community of umeng 3.1?

How can we achieve customization? The umeng microcommunity SDK internally defines some abstractions, such as Loginable, Pushable, and ImageLoader, which respectively represent the logon system interface, push interface, and image loading interface. Each interface has an SDKManager for management. For example, LoginSDKManager is used to manage the logon sub-system. You can add or remove specific logon systems from the sub-system, then, use the useThis function to specify a specific implementation (multiple implementations may exist in SDK Manager ). The structure is shown in Figure 3-1.

Figure 3-1 <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Ghost/ghost/be60M3O0sPHvs2/ghost/cq1z9a1yLLZ1/ez6c/zu6 + jrLHcw + ghost + cq + ow.vcd4ncjxwcmugy2xhc3m9 "brush: java;"> Public abstract class SDKManager {// Generic Map private Map MImplMap = new HashMap (); // Key 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);} public void addAndUse (T impl) {if (impl = null) {return;} mCurrentKey = impl. getClass (). getSimpleName (); mImplMap. put (mCurrentKey, impl );}}

The code is very simple, that is, a Map is maintained in the SDK Manager. The key is a string value specified by the user for this implementation, and the value is the specific implementation. You can use this key to remove the implementation. More often, you need to call the useThis (String key) interface to specify a specific implementation.

We didn't directly use SDKManager because it is an abstract generic class, so we defined some subclasses to manage different implementations. These subclasses are single-instance classes, such as LoginSDKManager, the Code is as follows.

Public final class LoginSDKManager extends SDKManager
  
   
{// Singleton object static LoginSDKManager sInstance = new LoginSDKManager (); private LoginSDKManager () {}// obtain the singleton object public static LoginSDKManager getInstance () {return sInstance ;}}
  

When you need to manage the login systemLoginSDKManager.getInstance()You can obtain the SDK Manager responsible for managing the logon system.addImpl(String key, T impl),useThis(String key)And other interfaces to manage the login system, which allows you to flexibly use the User-Defined subsystem.

3.2 Example

The following is an example to illustrate the problem.
In the process of communicating with users, we found that the login module is the subsystem with the highest user-defined probability. Generally, users may have their own account systems or use third-party logins (such as umeng social components). At this time, users do not need the login implementation included in umeng micro-Community SDK, it relies entirely on its own account system or other third-party logon sdks to implement a logon system. Next we will demonstrate the custom process by implementing the login system (the same as the custom principle of other subsystems.

Before getting started, we need to understand the abstract login interface Loginable. The Code is as follows:

public interface Loginable {    public void login();    public void logout();    public boolean isLogined();}

Login (): indicates the logon function. After Successful Logon, you need to call back the user information to the umeng microcommunity SDK (For details, refer to umeng microcommunity integration documentation). logout (): log out of the function. log out of the user. isLogined (): indicates whether the user is logged on. If true is returned, the user is logged on. Otherwise, the user is not logged on.

The microcommunity SDK abstracts several simple interfaces to define the login module functions. You can customize your login system by implementing these functions, finally, we can implement sdks for the umeng microcommunity. For example, if your application already has its own account system logic, you can implement these functions by calling your account system logic in several Loginable functions; if you use umeng social components (Note: although the logon module of umeng micro-Community SDK uses umeng social components, their jar files are not consistent, so no matter which implementation you use, all jar files related to logon must be updated.), You can use the login and logout functions of the umeng social component to implement the corresponding functions. For example, you canlogin()Function callUMSocialServiceObjectdoOauthVerify(Context context , SHARE_MEDIA platform , UMAuthListener listener)Interface. In a word, we define a class that implements the Loginable interface, you can call the functions of this class to log on, log out, and determine whether the functions are logged on. After the login class is implementedaddImpl(String key, Loginable impl)To inject the implementation into the umeng microcommunity SDK, and finally use the LoginSDKManageruseThis(String key)Function to specify the login implementation to be used. The key isaddImpl(String key, Loginable impl).

The sample code of the custom logon class is as follows:

/*** The login Implementation of umeng social component. Here, you can replace it with your account system and third-party logon, and implement several interface functions. */Public class SocialLoginImpl implements Loginable {@ Override public void login () {// specific implementation of logon, you can call your own login code or third-party SDK login function} @ Override public void logout () {// logout implementation, you can call your own logon code or third-party SDK logon function} @ Override public boolean isLogined () {// check whether logon return true/* code is omitted */;}}

Inject login implementation:

// Log on to the system manager LoginSDKManager loginMgr = LoginSDKManager. getInstance (); // keyString clzKey = SocialLoginImpl. class. getName (); // inject loginMgr. addImpl (clzKey, new SocialLoginImpl (); // specify the specific implementation loginMgr. useThis (clzKey );

For simplicity, this process is encapsulated into a function, and the code used is simplified:

// One line of code! This function encapsulates all the above Code. LoginSDKManager. getInstance (). addAndUse (new SocialLoginImpl ());

After these steps, the logon system is injected into the microcommunity SDK. When you need to log on to the umeng micro-community, the micro-Community SDK will use the getCurrentImpl () function of LoginSDKManager to obtain the user-specified logon implementation, and then trigger the correspondinglogin()Function. Then, your logon process is executed. After successful logonlogin()The listener callback function (this listener is not provided in this simple example. For details, refer to the umeng microcommunity to use the existing account system). This completes the entire login process.

Miscellaneous

At present, umeng micro-Community SDK is still in the internal test phase (umeng micro-Community internal test application address, but can already be used. Some of the apps integrated with umeng's micro-community have been launched and run well. I hope this article will help you develop third-party Android sdks to reduce the development pitfalls.