Methodology about Managing Mobile Service Dependencies in one codebase for Unity

Hi everyone,

I want to present one basic methodology which lets us manage multiple mobile service dependencies in one code base with minimum effort. After Huawei Mobile Services was born into the ecosystem, game developers have to maintain one more game version, if they want to reach players which have Huawei mobile phone.

Actually, Unity developers are used to managing game flows and services according to platforms such as IOS & Android. But this time, there is one thing different.

Image 1: Difference between supporting different platforms and mobile services.

As you see in Image 1, Huawei Mobile phones are still using Android Operations System and your Unity Project should be using the Android Platform when you build for Huawei. But at the end of the day, you have to release 2 different Android APK or bundle for Huawei App Gallery.

So, what will be differences between these 2 apks?

First and the main difference is mobile services. You cannot use GMS in new Huawei Mobile Phones. Because of this, you need to create one APK which includes Huawei Mobile Services to release it in Huawei App Gallery, and one more APK which includes Google Mobile Services to release it in Google Play Market. Services are can be “In-App Purchase”, “Advertisement”, “Game Services”, “Analytics” etc…

Second and another important difference is the package name. You know, both ecosystem works on Android, so to avoid inconsistency and overriding, Huawei App Gallery has one more rule that your package name should end with “.huawei” or “.HUAWEI”. This approach is just being used for separating two ecosystems from each other.

Don’t worry so much, we can handle these differences in one code base to keep development effort minimum.

I will mention about 2 small tricks to handle these two differences which I described above. Let’s check them;

1. Have you ever heard about #defines

#defines are one of the lifesavers, thanks to this structure we can manage our flows on build time (also in coding time thanks to IDEs). What is the meaning of flow? Imagine that you have 2 different Game Services such as Google Play Game Services and Huawei Game Services. You can separate your code with defines to build your app for 2 different game services in one codebase. Let’s check a small example for #defines;

If you add the “HMS_BUILD” keyword in your defined list, your released game will call HMSGameServiceProvider. In this way, we will manage our flows in the same code.

And of course, you can use the below Editor Script to manage your defines before build :) After you changed DefineKeywords and save it, IDE will refresh your code flow according to keywords.

2. Pre & Post Build Scripts

As I mentioned before, we need to change the package name for Huawei App Gallery version of our game.

But if you also use Google Play Services all configurations are bound to your existing package name and changing package name affects your configuration. In addition, Unity Editor started to warn you with a popup to fix the package name of your application because your package name and mobile service configuration are different now. Yes, it is really boring to close this popup each time again and again.

To solve this problem and manage two different package names in one codebase, we can use a perfect workaround with pre-build & post-build scripts with defines.

Let’s see how can we solve this issue;

It is just easy. By the power of defines, we can change our package name on pre-build just for HMS_BUILD. After the build, we can revert the package name again to the original one, so Unity Editor will not warn us for package name mismatch anymore.

That’s it. We are ready to develop our game in one codebase for Huawei Mobile Services and Google Play Services at the same time.

Sample Application Development

We will create a sample application that includes Games Services, IAP, and Advertisement from Google and Huawei Mobile Services in one codebase.

P.S. We will not implement all functionalites of each services, because this is just demo for presenting methodologhy which we can apply our games. You can extend each feature and each functionality of mobile services by this way.

Structure of Service Modules

Image 2: Structure of Service Module Schema

For each service, we will have;

• Manager: This class will include game-related logic for services and manage overall functionalities. It depends on your game logic. For different games, you may need to change this class according to the requirements of the game.
• Factory: This class will include the logic of provider selection. The main task of this class is returning to the target provider. In our approach, we will use defines and it will be seen as static selection maybe, but you can change the provider selection mechanism as you wish.
• Provider: For each service that we want to support in our game, we need to create one provider. All dependencies between your project and mobile services should stay in the provider class.
• Provider Interface: We need common providers to unify the usage of different mobile services, and we will do it with Provider Interfaces. According to your game requirements, you need to define all methods which you need to use in your game from mobile services.

and if we need we may have;

• Common Entities: For some mobile services you may need to create common entities to abstract your game from mobile services. To keep a dependency on just provider classes you can use common entities according to your requirements.
• Common Listeners: Same as Common Entities, if you need common listeners, you can create them for the same purpose as common entities.

Image 3: Example of folder structure for Game Service Module

Now, let’s see examples and try to understand what we can do with this methodology.

To abstract mobile services from game logic, we will use Managers. Managers reach to Providers through Factories. So we can use providers as plug-ins. Providers need to implement a common interface and this interface should contain methods that we want to access in our game. For this demo application below methods will be enough for us on Game Service.

Then, we need at least one provider which implements a service interface. As I mentioned before, all dependencies between game and 3rd party mobile services should stay in providers. We will create 2 providers for Huawei Game Service and Google Play Game Service.

Check the below examples;

I will just put part of code to prevent longer code blogs, you can find all codes in the project which I attached to article.

Huawei Game Service Provider

Google Game Service Provider

Now we just need to create our manager and through factory class, we will get the provider according to our define.

And the factory class is here;

That’s it, now we have GameManager class which can manage Game Service functionalities with multiple providers.

To initialize GameServices, you just need to use the below code line where you want;

I will not explain each service module one by one in the blog post, because all of them have the same logic and structure. You can check all of them in the sample project from GitHub.

In addition, if you need to guide to configuration of Huawei Unity Plugin, you can follow this blog post.

If we summarize the result;

Just by changing defines between HMS_BUILD and GMS_BUILD in DefineConfig.cs,

1. We can get two different apk or bundle for Huawei App Gallery and Google Play,
2. Login&Logout, Leader Boards, Achievements, IAP Operations and Advertisements functionalities change between HMS and GMS,
3. You can see short video records for both builds below,

If we build with “HMS_BUILD” define;

If we build with “GMS_BUILD” define;

You can check the demo project and find prepared apk files for HMS and GMS builds on GitHub.

Thank you for reading, I hope it will be helpful for you.