Docking system design of AFP for Android aggregation AD

Work needs, to docking Ali Mother's advertising aggregation platform, referred to as AFP. For general applications, the need for traffic monetization, advertising is the obvious means, especially in China, open a Tens other users, there must be some place there is docking advertising, but not obvious.

Ali mother's AFP advertising aggregation platform is the point, is a platform to aggregate a number of third-party platforms, such as Baidu, wide-point through their platform to access, and then push the corresponding ads, of course, including self-selling ads.

If we do not use this aggregation platform, but also want to improve their advertising revenue, increase advertising exposure is the only choice, but the filling of ads is a big problem, because the single advertising platform of the material filling is not guaranteed to hundred, multiple platform access, the client itself is a very big burden, think about it, In order to determine the Baidu platform to pull the advertising failure, then to call the wide-point access to the ads, or to pull two platform ads at the same time, and then determine the priority, who is the preferred, who is the alternative, these are very headache problem, more serious is, multiple Platform SDK access, will increase the volume of the package.

Ali mother's AFP aggregation platform solves this problem, as long as the access to their SDK on the line, do not have to access the SDK of other platforms, because their own backstage to call the other Platform SDK to obtain the corresponding ads.

Considering the future of the ad display form is a variety of, such as open screen, interstitial, of course, the AFP itself API is already very simple, but it is inevitable to be based on different circumstances of the corresponding configuration. If you want better management, you can use the Factory mode + policy mode to complete the configuration problems of these different situations.

Our vision is simple: top-level business does not need to ignore the implementation of the specific advertising SDK, even the corresponding libraries are not imported, they just and an abstract docking on the line, this abstraction is responsible for regulating and managing various types of advertising.

We are named AdManager.

The business unit of Android is activity, according to the AFP API, we need to communicate the ad bit ID, corresponding to the ad display form, advertising platform.

AdManager AdManager = Admanager.newinstance ();
Admanager.setup (ID, AdManager.ShowType.Welcome, AdManager.Platform.Baidu);

We do not treat AdManager as a single case. Not all high-level abstractions require singleton processing, instead, single-session causes unknown errors because the program shares the same instance, and we have no way of knowing where the instance will be modified.

Here the use of the scene as long as you want to directly new one, but in order to avoid each time to write the new code, a newinstance method to encapsulate it.

The code implementation of Setup is a typical policy pattern, because different configurations need to be returned based on the type of ad being passed in.

1Mmuproperties Properties =NULL;2Object Controller =NULL;3         Switch(showtype) {4              CaseBanner:5Properties =createbannerproperties (activity, SlotID, ViewGroup, platforms);6Controller =((bannerproperties) properties). Getcontroller ();7                  Break;8              CaseFeed:9Properties =createfeedproperties (activity, SlotID, platforms);TenController =((mmufeedproperties) properties). Getcontroller (); One                  Break; A              CaseInsert: -Properties =createinsertproperties (activity, SlotID, platforms); -Controller =((insertproperties) properties). Getcontroller (); the                  Break; -              CaseLoopimage: -Properties =createloopimageproperties (activity, SlotID, ViewGroup, platforms); -                  Break; +              CaseWelcome: -Properties =createwelcomeproperties (activity, SlotID, ViewGroup, platforms); +Controller =((welcomeproperties) properties). Getcontroller (); A                  Break; at             default: -                  Break; -         } -  -         if(Properties = =NULL) { -             return NULL; in         } -  to mmusdkfactory.getmmusdk (). Attach (properties); +         returnController

We're not talking about the API call code for AFP, which is used in the Switch+enum way to implement the policy pattern.

When we first learned the design pattern, we knew that the code scenario to be solved by the strategy pattern was a lot of if-else if-else, but in fact not all such use would have to be used in the policy mode, the design pattern should be used in order to make the usage scenario more extensible. Rather than the optimization of a part of the code structure, which is why some people refer to the MVP design pattern for their own application of the architecture design, found that the code is more difficult to write, and in order to meet the MVP model, some non-trivial business scenarios are also very heavy design, resulting in the code is not more clear , but more like a person's design mode test field, if more stringent point, is a landfill.

We need to make different configurations based on different ad presentation types, and this scenario is consistent with the usage scenario of the policy pattern. Although it is only our personal little prejudice, that is, if different situations can be defined as different enums, such as the above ShowType, is the ad display type of enum, you can use the switch with the policy mode, because it can be categorized as an enum, Illustrates that each instance of an enum is indeed a set of conditions that are required under the same business scenario, and that different policies are implemented based on these conditions.

So we used the policy model here.

Here we can notice a problem: The conditions are more than one group, but two groups.

Ads are displayed in a group, and the platform for advertising is also a group. How do we decide which group is a prerequisite?

It can be clear that these two sets of conditions are not divided into preliminary and final points, in the code organization, the decision to show the form is the first set of policy conditions, but also the first judgment of the conditions, simply because we feel that the first group of policy conditions if it is more, then resistance to see the second group of people, Found that the second set of conditions is so simple, the heart may have a sense of relief, that is, the so-called first bitter sweet feedback bar.

Of course, if you really want to find an objective reason, is AFP it allows us to customize the third-party platform, if we do not want to completely give them to deal with some problems, such as the UI, this is very obvious on the open screen, although not know the specific reasons, but most of the mainstream advertising platform is not allowed to expose the Open data, But to give them to render, and open screen there is inevitably a design is to skip the button, wide-point before the version is not allowed to customize (now the version is ready), Baidu is OK, so want to add their own skip button, it is necessary to take data docking way, The realization of this in the AFP is to let the customer to define the third-party platform, their own to render and add.

Unfortunately, we are in the back of the situation, so in the need to add a different platform to adapt this requirement, we have to build an advertising platform of the factory class, to help us better manage the different platforms.

So, one of our little experiences is this: If two sets of conditions, where one set of conditions are common to another set of conditions, the display of similar ads is what each platform should have, you can put this set of common conditions in the first policy group.

We mentioned the advertising platform factory class, this class is very important, because we need an abstraction to manage the scheduling of these custom platforms, and AdManager itself should be to achieve some kind of display of the advertising platform, regardless of how these different ad platforms are generated, This is not its responsibility.

Responsibility is a very important concept when considering the design of a code structure. What kind of responsibility a class should take, determines the role of this class throughout the design.

AdManager This abstraction we give the meaning is to provide some kind of display form of advertising, as for what kind of advertising, this is not its decision, according to the design requirements of a single duty, it assumed the responsibility is sufficient, decided that the advertising platform should be another class.

We gave this responsibility to adadapterfactory.

Bannerproperties.addcustomadapter (AdId, (mmubannercustomadapter) Adadapterfactory.createadadapter (platform, Showtype.banner));

Adadapterfactory needs to produce adapters for different platforms that correspond to the ad presentation, so there is a policy model involved.

1     Switch(platform) {2              CaseBaidu:3Adadapter =Createbaiduadadapter (ShowType, viewgroup);4                  Break;5              CaseGDT:6Adadapter =Creategdtadadapter (ShowType, viewgroup);7                  Break;8             default:9                  Break;Ten}

It is important to note that there are two sets of conditions for advertising presentation and advertising platform, but the choice and AdManager of the first set of conditions are the opposite.

The basis of our choice is actually very simple: AdManager pay attention to the choice of advertising platform, and adadapterfactory more attention is the choice of advertising display form.

AdManager to solve the problem is to show what platform ads, because it is scheduled to be different advertising platform, and adadapterfactory to solve the problem is to call their ad platform according to the needs of their ads to display the form of the API.

So when we select the order of the policy conditions Group, the definite condition group is placed in the first group, and the core condition group is placed in the second group, emphasizing that the core problem is always put in the last most critical place, and that the person reading the code will follow the clarity of the problem in the business scenario when they see the corresponding code.

The clarity of the problem simply means that when we solve a problem, we know the definite condition of the problem.

When we call AdManager, we know the need to display the form of advertising, the location of the open screen must be open-screen advertising display, but do not know how the advertising platform is chosen, so the clear conditions here is the form of advertising display.

When calling Adadapterfactory, we are also clearly aware of the ad platform to dispatch, but do not know the platform corresponding to the format of the ad display code.

The core of the Createbaiduadadapter is to select the corresponding adapter according to the corresponding display form:

 Switch(showtype) { CaseBanner: Break;  CaseFeed: Break;  CaseInsert: Break;  CaseLoopimage: Break;  CaseWelcome:adapter=NewBaiduwelcomeadapter (ViewGroup);  Break; default:                 Break; }

Here, our overall advertising management design system of the approximate implementation has come out, the rest is only based on specific circumstances to make specific adjustments.

Although it is just a simple business scenario code, but when we encode, we have to consider the core point of the business itself where, and then around this core point will have what kind of problem, how to solve such problems, code design on how to better reflect the solution of these problems, we usually do business needs to be considered.

Many people will complain that they have just come out to work, just do some simple business, similar to my AD access business, it does not have any technical content, but the quality level of coding does not depend on whether to solve more complex problems, nor depends on the ability to solve more problems, it is important to provide better and more convenient ideas based on the current problem.

Docking system design of AFP for Android aggregation AD