📜 ⬆️ ⬇️

Making life easier for a mobile gaming developer.

Hello,

Making a good game is not all work. In order to get a complete product that can be successfully distributed, it is necessary to integrate various kinds of marketing tools into the game: tracking of referral settings, banner rolls and offwolls, newsletter subscription modules and other good games, various partner SDKs, etc. etc. In this post I will tell you what tools for this we use in Alawar, we and our developers. Take for example our iOS projects.

After analyzing the main marketing tools that are used in the market, we have identified some groups of tools that have common features. For example, almost all such SDKs require session initialization in the application: didFinishLaunchingWithOptions: or applicationDidBecomeActive: methods. All installers trackers are working there.
Push notifications are always logged with the same calls.
Referral trackers usually need information after successfully performing an in-app. And they themselves need to validate.
And usually all the same places you want to "hang" events for collecting statistics, for example, through Flurry.

It is also worth noting that these tasks are common to all projects, the differences are only in IT and other apiKey for third-party services.
')
Gamedev under iOS is designed so that without marketing - nowhere. But developers, first of all, should (and want) to think and work directly on the game, and not to bother with the “marketing kit.” To make this possible, publishers provide their developers with various SDKs, frameworks, etc. Alawar is no exception. We have prepared the Alawar iOS Framework, which includes all the necessary marketing modules of the current versions and "does a little bit of magic."

For “a little bit of magic” there is a great Objective-C runtime and its ability to mix code.

So, for example, to start sessions for several SDKs in the application: didFinishLaunchingWithOptions method: we need to “intercept” this call from the Application Delegate and add our implementation to it. To do this, create a category over UIApplication, catch the setDelegate method:

@interface UIApplication(AlawarFramework) @end @implementation UIApplication(AlawarFramework) + (void) load { method_exchangeImplementations(class_getInstanceMethod(self, @selector(setDelegate:)), class_getInstanceMethod(self, @selector(af_setDelegate:))); } - (void) af_setDelegate:(id<UIApplicationDelegate>)delegate { Method method = nil; method = class_getInstanceMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:)); if (method) { class_addMethod([delegate class], @selector(application:AFDidFinishLaunchingWithOptions:), (IMP)AFdynamicDidFinishLaunching, "v@:::"); method_exchangeImplementations(class_getInstanceMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:)), class_getInstanceMethod([delegate class], @selector(application:AFDidFinishLaunchingWithOptions:))); } else { class_addMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:), (IMP)AFdynamicDidFinishLaunching, "v@:::"); } //  ""  [self af_setDelegate:delegate]; } BOOL AFdynamicDidFinishLaunching(id self, SEL _cmd, id application, id launchOptions) { //  "" ,    if ([self respondsToSelector:@selector(application:AFDidFinishLaunchingWithOptions:)]) { result = (BOOL) [self application:application AFDidFinishLaunchingWithOptions:launchOptions]; } else { [self applicationDidFinishLaunching:application]; result = YES; } //   ,    .. return result; } @end 


Similarly, we mix work with third-party libraries in applicationDidBecomeActive, initialize push notifications, etc.

Developers can only add the framework to their Xcode project and set the flag of the linker –all_load.

The situation is somewhat different with in-appy, their validation and registration in the referral trackers and statistics. Here we solved another side problem. The developers conduct primary testing under their Apple account and with some ITD in-apps, and when passing QA, a different account and other ITC are used in publishing and publishing to the store.

To solve these problems, we implemented our API “wrapper” on the StoreKit API and additional protocols for notifying delegates about the results of payment validation. At the same time, all product identifiers are placed in a separate configuration config.

Thus, the developer uses an API similar to the StoreKit, but without the need to load purchases with statistics, independently implement validation, etc.

At the end of the article, we note that we also provide similar tools for the Android platform.

Source: https://habr.com/ru/post/199348/


All Articles