Abstraction Analytics layer for Swift
Very often — just before app release — client realizes that he needs to trace user activity and collect events, or when the app is already released he wants to change analytics tool. There are many tools for collecting analytics in the mobile app. Some are more extensive, some are just for creating reports, but most of them work the same way — You create event object and call one function to save them and the library does all dirty work for you. It looks simple, but think a moment, what if You have 40 screens and You have to change Firebase to Facebook analytics? Damn it… You need to find all references, change framework imports and replace calls… a lot of work and you know you’ve been writing this code long time ago… Or another example — Your company want to create their own analytics system, but work is in progress now and You have to maintain both tools. These are real, live problem and if you work in a software house and you’ve been working on many apps you know what I mean.
Let’s start from protocols definition. Of course when we want to make something universal and reusable we need to use protocols. Our event contains name — that is our key — parameters and userProperties, what is the difference between the last two? Parameters are save as additional data in a specific event, e.g. value in purchase. User properties are attributes you define to describe segments of your user base, such as language preference or geographic location. It also depends on tool implementation but in most cases, it works this way.
Next, we need to define how Our provider will look like. All the tools log events someway and many of them allow us to save user id and map them in the dashboard for filtering.
Our ‘manager’ will hold all registered providers and broadcast event with required data. It’s nothing more than a simple aggregator.
All the above code can be saved in a separate framework attached to our application and moved between apps. Now I’ll show You how to use them.
At the beginning we define all events, of course, we can separate them in different files, even modules — the way how You do it doesn’t matter.
And voilà! We can log our events in any place!
Not so fast! We need to do one more step… Now our events are collected in void… We need to register providers — that are connected with the external library.
But first of all, we need to implement those providers. Let’s see how Firebase integration may look like.
For Facebook, it’ll be similar. You probably can implement this by yourself.
Hey! What about tests? I know that many of You — maybe even more than less — don’t write tests, but if You do, You can realize that this ‘microservice’ is not injectable. It’s not a problem, Analytics isn’t but providers can be, just create TestProvider and register it during tests.
TL;DR
Using analytics aggregator helps us send events to multiple providers without changes in the whole application. Read it! Is worth it ;)
Thank you for reading! If you liked this article, please clap so other people can read it too. I will also have more motivation for the next article :) You can also see my other articles, maybe you will find something for you.
If you have any question or suggestion leave a comment.
