I’ve built a Kotlin and Swift wrapper for Android and iOS snowplow SDK’s respectively, I’ve turned off all automatic tracking features except setInstallAutoTracking. All the other manual events that I’ve created using custom schemas are being tracked successfully via the wrapped trackers.
For iOS, the tracker is able to track the ‘application_install’ event but with empty flower braces.
Ex:
For Android, the tracker doesn’t seem to track the ‘application_install’ event at all.
I’m not sure if I’m missing something or if I’m doing something wrong, could someone help me out?
The fact that the application_install event is tracked with no properties (empty braces) is as expected – it shouldn’t have any properties, it just signals the installation.
In the Android case, please make sure that you test with a clean installation of the app. So try uninstalling the app and reinstalling again. The tracker creates a flag in SharedPreferences after the install event is tracked to prevent from tracking again.
It could also be helpful if you could provide you configuration and the way you initialize the tracker. However, there shouldn’t be anything special needed with the install autotracking feature – enabling it in the configuration should be sufficient.
As Matus said the install tracking works in a separate background task where it update the SharedPreferences with a flag and a timestamp.
My unique guess is that the tracker can’t correctly write or read from the SharedPreferences.
In this snippet the code involved to send the event. This would silently fail if the SharedPreferences is not accessible.
So far, we haven’t found any case where it wasn’t accessible.
Also, this operation happens in a background task. Would it be possible that the application terminates without leaving the background task to complete? It should be pretty fast but in some cases (e.g.: unit tests) it doesn’t start on time and the execution of the application terminates too early. Also, the event could be sent in a second moment if it hasn’t been sent at the first run.
I do not think that the app terminates before completing background task but I assume the tracker is somehow not able to access the SharedPreferences passed through the applicationContext.
I’m using the wrapped tracker(aar) in a bare minimum android application that has a few basic buttons to trigger manual events.
Is there something that I could try to diagnose the issue, I’m new to mobile development.
I tried to reproduce the issue under similar settings – Kotlin app with the tracker included as an aar package but wasn’t successful in doing that (the install events were tracked).
Could you please help us reproduce the problem by providing a minimal example for it? I created this repository with my reproduction attempt (here is the MainActivity where the tracker is initialized). If you could change this (or other) app to simulate the behaviour, that would be extremely helpful for us to identify and fix the issue!
The application structure is similar to what we are doing but we are using a wrapped snowplow tracker, i.e. the snowplow tracker aar is contained in another aar that we created and use.
I’ve tried your application and I’m able to see the installation events on Snowplow Micro.
I would suggest to test the tracking there first, just to exclude any other issue.
I’ve also created a direct dependency between your app and your library (wrapped_tracker) so I could debug it deeper.
I have just few notes that maybe help to narrow down the problem:
In your WrappedSnowplowTracker you check the property setInstallAutoTrackingusing contains but I think that check the value so it would return always false. You should use containsKey which checks the key. If the problem is this, it’s an easy fix as technically the wrapper didn’t configure the tracker properly.
Another minor note is about the app permission. I added the INTERNET permission in the Android Manifest because it wasn’t able to send any event, but I don’t think this was your issue.
I would suggest to check on Micro first (maybe using ngrok to avoid any issue where the traffic is blocked). If it works on Micro but it doesn’t work with the real pipeline we should look into something else, but I don’t think this is the case.