Clean architecture approach to integrate HMS and GMS apis into your project with the same code base
Hi everyone, in this article we will talk about how to create platform specific classes to support HMS and GMS apis in the core layer of a project which are designed according to the concept of clean architecture. I always believe the motto “Code is read more often than it’s written” . So we shouldn’t skip this.
If you’re familiar with clean architecture you are aware of the importance of writing clean and reusable code. So I prefer to have the same clean codebase for both HMS and GMS based apis integration, and don’t wanna use so much boilerplate code. Plus it should be independent of the presentation layer. So you can reuse it for another project easily.
I will try to explain this approach by implementing both HMS Map Kit SDK and Google Map SDK into a sample project.
IPlatform : As you possibly guess we need an interface for common methods.
IHuaweiPlatform & IGooglePlatform : We also need platform specific interfaces to implement only platform based methods. Each platform may need to access their own specific methods. So we may need an interface for only HMS specific methods and another one for GMS either.
HuaweiPlatform & GooglePlatform : Our platform specific classes should be implemented from the common interface. We should do the works of both platforms in their own class. (see Single-Responsibility Principle)
Platform : We will need a class which is used for calling platform based methods from a single point. Since this class should not have any knowledge about the logic of platform specific classes, but has to know how to call an interaction with a platform based class. It will get common interface as a constructor parameter. Then we will able to call common methods through this interface.
Presentation Layer: We will initialize the platform class according to device’s HMS and GMS availability. We will call common methods through the platform class for the rest of the flow.
This platform util class will help you to check which platform is available on the device.
Another little trick is, as we need to integrate two different platform apis to our project, sometimes we will have to send different type of object parameters. For example if we talk about in app purchase apis Google Play Billing and Huawei IAP have different object type for defining product types. Huawei has PriceType which has Consumable, Nonconsumable and Subscription properties but Google has BillingClient.SkuType which includes inapp and subs properties. If you want to provide both product types through a single product type object, I recommend you to use of your own product type data object. Then you should map this from and to the platform based product objects when transferring data from presentation layer to platform specific classes and into the database or service api if needed.
I prefer to use some extension classes to provide this mapping. Thanks to kotlin. I will not describe extension functions as “syntactic sugar”. I think clean architecture lovers are happy with extensions as I’m.
A very basic extension class to map product types.
And the result:
I tried to explain how to cleanly prepare your project as HMS and GMS compatible using the same code base. Hope you have enjoyed reading this. I would appreciate your suggestions and comments.
You can access the full code from github.
Keep coding!
