An analysis of the technology architecture of Android in-app Community SDK

Android in-app Community SDK Technical architecture What is an in-app micro-community?

Figure 1	Figure 2 Snowball finance in-app community

First, take the Friend Alliance Micro-community as an example

In short, the Friends Alliance's micro-community is a product that helps developers quickly build a community (similar to Sina Weibo and friends) in their apps. In many applications, developers often need a user and interaction between the user and the community, users will often in the community to choose to like, comment, attention, forwarding, post and other interactive ways. But the development of a social system is not so easy one thing, complex user relations, message Flow, server architecture and so on are difficult issues, more importantly, we are all repetitive labor! Each developer needs these features to build a social system that is very expensive to develop from scratch. In order to solve these problems, AU has launched the Friend Alliance Micro Community SDK (Beta phase), which allows you to quickly build a community in an SDK-integrated way, greatly improving productivity and user activity.

1.1 The characteristics of the Friends Alliance micro-community

1. UI Open source;
2. Can be used as an SDK embedded in existing applications;
3. One-click to create a standalone app;
4. account system, image loading and other core components can be customized;
5. Advanced anti-spam, automatically eliminate spam information;

3, Figure 4 is the integrated effect of cloud picture TV.

Figure 3	Figure 4

Second, the technical framework

From the project structure, the Friends Alliance Micro Community SDK can be divided into the following three layers:

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

• Business Logic Layer
  The business logic layer provides the UI layer with a unified interface to provide data data requests, such as access to cached feeds, friends list, etc., so the business logic layer is a data manipulation interface for users, through which users 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 makes it easy for the user to realize the customization, that is, to implement the abstract interface, and then inject the concrete implementation into the Friend Alliance micro-community, so that its subsystem can replace the default implementation in the micro-community (show example below).

2-1, the Friend Alliance Micro Community SDK hierarchy, through the three levels of isolation, so that users can both customize the outermost UI effect, but also hide 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 2-1 Onion Structure diagram

Simply put, the user can manipulate the Alliance Micro Community SDK through a common interface exposed by the logical layer in the UI layer, capturing, storing data, and other related operations from a closed core system. As shown in hierarchy 2-2.

Figure 2-2 Hierarchy Chart

Figures 2-1 and 2-2 show that the Friend Alliance Micro-Community SDK is a more typical form of architecture by separating responsibilities at different levels. 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 Friend Alliance micro-Community SDK relies on abstractions internally rather than on specific implementations, and users 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.

Iii. customization of the Friends Alliance Micro-Community 3.1 how to 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-1.

Figure 3-1

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    Privatemap<string, t> mimplmap =NewHashmap<string, t> ();//Key of the implementation to be used    PrivateString 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; } PublicTGetcurrentimpl() {returnMimplmap.get (Mcurrentkey); } Public void Addanduse(T Impl) {if(Impl = =NULL) {return;        } Mcurrentkey = Impl.getclass (). Getsimplename ();    Mimplmap.put (Mcurrentkey, Impl); }}

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  > { //Singleton object  static  loginsdkmanager sinstance = new  Loginsdkmanager (); private  loginsdkmanager  () {} //get Singleton object  public  static  loginsdkmanager getinstance  () {ret    Urn  sinstance; }}

When the user needs to manage the login system, it can LoginSDKManager.getInstance() obtain the SDK manager which is responsible for managing the login system, at which time the user can addImpl(String key, T impl) useThis(String key) manage the login system through, and so on, so that the user-defined subsystem can be used flexibly.

3.2 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 (such as the Friends social component), 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:

publicinterface Loginable {    publicvoidlogin();    publicvoidlogout();    publicbooleanisLogined();}

• Login (): Login function, the user needs to log in after the successful user information back to the Alliance micro-Community SDK (the process can refer to the Friend Alliance micro-Community Integration documentation);
• 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 implement such as the Friends Alliance Micro Community 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, if you use the Friends social components ( Note: Although the Friend Alliance Micro Community SDK Login module uses the Friend Alliance social components , but their jar files are not consistent, so regardless of which implementation you use, you need to update all the jar files associated with the login. , you can use the login and logout functions of the Friends social component to implement the corresponding functions, for example, you can login() invoke the interface of the object in the function UMSocialService doOauthVerify(Context context , SHARE_MEDIA platform , UMAuthListener listener) to implement the 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 implementing the login class, the implementation is addImpl(String key, Loginable impl) injected into the Friend Alliance micro-Community SDK by Loginsdkmanager, and finally through the Loginsdkmanager useThis(String key) function to specify the login implementation to use, this key is the addImpl(String key, Loginable impl) key set in.

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, etc., the implementation of several interface functions can be. */ Public  class Socialloginimpl implements loginable {    @Override     Public void Login() {//Login specific implementation, 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() {//Detect if login        return true / * Code omitted * /; }}

Injection Login Implementation:

// 登录系统管理器LoginSDKManager loginMgr = LoginSDKManager.getInstance() ;// keyString clzKey = SocialLoginImpl.class.getName() ;// 注入实现new SocialLoginImpl());// 指定使用的具体实现loginMgr.useThis(clzKey);

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

// 一行代码搞定！这个函数封装了上述所有的代码。LoginSDKManager.getInstance().addAndUse(new SocialLoginImpl()) ;

With these steps, the login system is injected into the micro-Community SDK. When a friend Alliance Micro community needs to log in, the micro-Community SDK will take the user-specified login implementation via Loginsdkmanager's Getcurrentimpl () function and then trigger the corresponding login() function, and your login process will be executed. After successful login, through the login() function of the 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.

Zatan

At present, the Friends Alliance micro-Community SDK is still in the beta phase (Friend Alliance Micro Community application address, 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.

An analysis of the technology architecture of Android in-app Community SDK