In this article, we will explore how to get the correct intent through which the app was brought to focus on Unity-Android applications. Speaking technically, we find out how to workaround the fact that Unity handles onNewIntent callback internally and how to get the intent that actually brought the app to the foreground.
We will use GetSocial’s Smart Invite feature to explore the issue and demonstrate our solution. Smart Invites allow users to invite their friends via popular messaging and social networking apps. Figure below demonstrate show the smart invite flow works.
Recently, we discovered the following issue in our Android-Unity SDK:
When a user opens an app from the invite link they received from their friend, they did not receive the referral data that was embedded with the invite. Technically, we did not receive the intent that brought the app to the foreground, instead, it was the intent that had initially launched the app.
Let’s get into more technical details:
When a user clicks on a smart invite link, we first check if they have the app installed.
- If the app is not installed, we redirect the user to the appropriate app store.
- If the app is already installed on their device, we will open the app directly.
The issue arises with the second scenario. What happens on Android when the app is already installed is actually quite simple – the intent with data is created and opened as URL in the browser. The intent looks something like this (note: this is a sample one from our test app):
When opened in the browser, this intent is supposed to open the app and we are supposed to get intent data with the referral data. But when we receive the intent of the main Unity activity after opening the app with the above URL, the intent data is not present. This is happening because Unity handles onNewIntent callback on its own and we don’t get to intercept this essential data. Instead, we get the original intent that the app was launched with some time ago.
In this case we have two possible solutions:
- Export Android project and subclass UnityPlayerActivity – this approach is inconvenient and not possible as we are providing the SDK and we cannot force our customers to do this.
- Provide the intermediate activity without any GUI that just intercepts the intent, stores it and opens the main activity (which most of the time is UnityPlayerActivity).
Here is the code of the intermediate activity:
In this case we just forward the intent to GetSocial and launch main activity immediately after that. We intercept the correct intent and do what we need to do with the data. What the developer has to do is just declare this intermediate activity in their manifest with the required intent filter.
So, if you are also opening your Unity-Android application from a browser using an intent, this technique might help you to avoid confusion.