Introduction: This article aims to provide readers with an idea of making their own aggregation sdk, and to inspire more readers to have a good understanding of aggregation sdk.
In the previous article "General Idea and Architecture of TypeSDK", a brief description of an aggregation SDK, which modules are required, which functions are implemented, and the relationship between modules is how.
With the basic ideas and architecture, any program or solution will have a basic design principle. As an aggregation sdk, what basic principles should we uphold?
1. Low coupling with game projects
2. Aggregation SDK is easy to use
3. Strong expandability
1. Let’s first discuss how to achieve low coupling.
As an aggregation sdk, the most immediate problem that needs to be faced is the cross-platform problem. We must first have a concept, that is, the development platform of the game and the hairstyle platform of the game are completely different. The game development platform refers to the language used for the game and the production environment in which it is developed. The distribution platform of the game refers to what kind of terminal the game runs on.
The main release platforms for mobile games are iOS and Android. The share of windows phone is too small, and there are almost no distribution channels in China.
The mainstream game development platforms include unity and cocos2dx. And relatively many use native Android and ios to develop software. In view of the above, we use native Android and ios as the release basis, and are providing development packages for unity and cocos2dx.
The realized logical relationship is as follows:
1. As a game developer, at the game client level, you only need to pay attention to the sdk interface call logic of the development platform, not the implementation logic of the sdk interface. The declaration of the Sdk interface is given by the typesdkclient part provided by typesdk
2. As the aggregation SDK access layer, access to the SDK code implementation part of the major channels, that is, the implementation layer of the major publishing platforms, only need to realize the functions of each logical interface under the framework of the types SDK, and do not need to care about the specific Who calls and how.
3. The interface declaration of the development platform and the specification of the unified interface of the publishing platform, this whole set is the main framework of the aggregation sdk client part.
4. The call of the interface is completely separated from the implementation of the interface, which realizes the decoupling of the game logic code and the channel SDK. The entire aggregation sdk system is independent of each other and related to each other, so that the overall function can be realized, and the purpose of modularization, functionalization, and differentiation can be achieved. Let the entire project be jointly developed by multiple people, greatly improving the development progress.
2. How to make aggregation sdk easy to use
People love to get along with simple people, and people love to use simple and easy-to-use things. One of the successes of the iphone is its simplicity in appearance and its easy-to-understand system.
There are two types of objects used by the aggregation SDK, 1.
When it comes to simplicity, I have to mention a word related to simplicity, unity, and all simple things can make users quickly form a unified usage habit. So from the point of view of code design, the most representative of unification is the singleton mode in the program.
We design a simple class (TypeSDKClass), so that all the user's interface calls, callback function reception, event processing, etc., start from this entry and only export from this entry. No matter how complicated its internal structure is, Users don't need to care. They just need to remember that I want to do one thing, and I found the singleton TypeSDKClass that can meet my needs from the methods it provides and the callbacks that need to be implemented.
Moreover, this singleton object TypeSDKClass does not need to care about how it is created or destroyed, it only needs to be used whenever and wherever I want.
With the singleton object as the main body, data transfer is inevitable in program design.
The most easy-to-use and understandable data structure, the hashmap class should be one of them. Our program provides the parameters passed in the interface. The data structure used is a packaged hashmap, and there is a set of easy-to-understand keys to access the corresponding value.
Users don't need to care about how this data structure works when it is passed across platforms, they just need to feel easy to understand and easy to use when using it.
3. Let's talk about scalability
The SDKs of all major channels are developing, and the major distribution platforms are also constantly developing. Android has changed from 2.0 to 7.1 now, and iOS has maintained a stable rhythm of one major version a year. The replacement of new and old versions, some Old interfaces are deprecated and some new interfaces are enabled. In more cases, there are new functions to improve the experience and functionality of the game.
As our aggregation sdk, we must be able to keep pace with the times in order to continuously bloom new vitality. The best way to keep pace with the times is to have strong scalability.
On the game publishing platform, we need to design an interface that can call a specified function through the function name, and the parameters of the function also need to be of type string. This has several advantages.
1. The function name is of string type. The cp connected to the aggregation sdk does not need to re-update the aggregation sdk part of the development platform (unity or coco2dx). It only needs to add a few string fields to call the function
2. The parameter is of string type, that is, we can convert our previous hashmap type data into string type json, which is both general and rich.
3. Execute the function through the string type function name, even if the function does not exist (for example, the running device version is too low and does not support this function), we can do corresponding logic processing at the release platform level without causing game failure collapse.
4. No matter how many new functions will appear in the future, we will remain unchanged to meet all changes. One trick is eaten all over the world. We only need to continuously add the implementation of new function interfaces at the implementation interface level of the running platform, so that we can use the new functions we support anytime and anywhere in the game client part.
The above are bloggers’ views on some principles that need to be followed in the design of a set of aggregation sdk. Of course, there must be other principles. For example, the key value of the hasmap data structure type in the code specification is string type, and the content of string type , There must be a unified naming rule, so as to avoid data operation bugs caused by writing errors.
The blogger throws bricks to attract jade, and hopes that more readers can put forward your opinions and suggestions without hesitation.
In the next article, we will mainly explain the detailed ideas and structure of the aggregation SDK implementation at the distribution platform level (Android and iOS). Let everyone have their own views and understandings on the aggregation sdk, and finally make your own aggregation sdk.
This project has been open sourced. If you are interested, you can do your own research or refer to the project to write your own aggregation SDK
project address: https://code.csdn.net/typesdk_code
project address: https://github.com/typesdk