Deep Dive Into Deep Link. Part 3. OS shell, application
We continue writing our cycle. Parts one and two are available on our Medium. If you haven’t read this far, go ahead. This knowledge will help you deal with it with confidence. For those who are already know the cycle, let us remind you of the theses of the previous article:
- We have considered the structure of experiments: the configuration table, the experiment table, the testing process itself
- Described the chronology of problems
- Analyzed the hypothesis about the influence of device hardware on deep link processing
Hypothesis 1: Different devices — BUSTED.
The device (hardware part) does NOT affect Deep Link processing.
We have examined in detail how the Android OS version affects deep link processing
Hypothesis 2. Different Android versions — BUSTED.
Android OS version does NOT affect Deep Link processing.
Today we are going to deal with two more issues related to OS shells and the application from which deeplink is opened.
At the end of the previous article, we formulated hypotheses 3 and 4:
Hypothesis 3. Different OS shells.
Android OS shell affects the performance of Deep Link.
Hypothesis 4. Application.
The application from which the link is opened affects Deep Link.
Today we’re going to break down some interesting examples that will set the stage. Let’s get started!
Problem №3. Different shells
Different OS shells. Deep link processing was different on different Android shells
Let’s describe the conditions under which the problem is reproduced:
On both devices, open Gmail, send yourself an email with the link domain1.domain2.ru/landing, receive it, open it, click on it.
This time we open the same link, in the same app. One UI was able to navigate to our app, Vanila was not. Let’s formulate a hypothesis:
Hypothesis 3. Different OS shells.
The Android OS shell affects Deep Link’s performance.
To test it, we chose a third-party Gmail application and shells:
- One UI 2.5, One UI 3.1
- Samsung Experience 9.0
- EMUI 9.1.0
- Vanila
All four shells showed the same result when trying to open the deeplink through the Gmail application.
But!
If you run tests on a built-in application (e.g. SMS client), differences appear:
Let’s figure it out. One UI 3.1 in Messaging showed itself as in the previous case.
EMUI 9.1.0 is very different in a similar test:
Why is this happened? The fact is that applications can be third-party (you can download them from Google Market) or built-in (pre-installed on your smartphone). This is the difference between Gmail (third-party) and Messaging (built-in).
Get Valery Petrov’s stories in your inbox
Join Medium for free to get updates from this writer.
You could take this further and say that the shell directly affects which built-in apps will be on the device. After all, someone will say, “Samsung’s SMS client can be installed on Honor.” Yes, but who will do it? :) Moreover, once it’s installed on Honor, it will still be Samsung’s. Therefore:
Hypothesis 3. Different OS shells is BUSTED.
Android OS shell does NOT affect Deep Link’s performance.
Problem №4. Different applications
Different applications. Deep link processing was different when clicking on a link from different applications.
Show to us configurations, please!
Of the significant parameters, only the application. In the first case — Gmail, in the second — VK.
Let’s formulate a hypothesis:
Hypothesis 4. Application.
The application from which the link is opened affects the operation of Deep Link.
To test this hypothesis, we will try opening links from different applications:
- Messaging
- Gmail
- Google search bar
- Telegram
- VK
- VK Toasters
The results are different. Let’s get to the point. For all listed applications, except VK, the results were as follows:
And here’s what happened in VK. No links for any schemes were opened in our app!
Trying to figure it out:
Q: Does the application from which the link is opened affect Deep Link processing?
A: Yes, but the behavior is not always expected
Q: What do you mean by “not always expected”?
A: Some applications (e.g. VK and Telegram) have a built-in browser (in VK and Telegram you can disable it in the settings)
But even in applications with built-in browsers, the behavior is different!
VK and Telegram have built-in browsers that try to intercept clicks on links from the app. But the mere fact of having a browser is not determinative. The behavior can still be different.
What’s more! Deep Link processing can be different on different versions of the same application. A simple example:
We have sorted out a few striking examples that are more than enough to draw a conclusion:
Hypothesis 4. Application — CONFIRMED.
The application from which the link is opened DOES affect Deep Link’s performance.
Summarize
Today we have considered the third and fourth of the seven problems we encountered while solving the original task.
The third problem: deeplink is handled differently on devices with different shells. Here we agreed that applications are third-party (installed by us from marketplaces or websites) and built-in (pre-installed by developers on smartphones). We sometimes don’t notice how we use different calendar, mail and SMS-clients. They are so similar in functionality and do not differ much in appearance, but they are still different. And the shell contributes to it to a greater extent, but in an indirect way.
Hypothesis 3. Different OS shells — BUSTED.
The Android OS shell does NOT affect Deep Link’s performance.
The fourth problem was that the applications from which the link was opened affected the performance of Deep Link. Experiments showed how different the processing can be. We found that when testing applications, it is very important to pay attention to the presence of an embedded browser, which can greatly affect processing. The conclusion is this:
Hypothesis 4. Applications — CONFIRMED.
The application from which the link is opened is affecting Deep Link’s performance.
Congratulations! You’ve done well three times! Three of the five parts are behind you. Next time we’ll figure it out:
- Links without a scheme. Links of the host/path kind were handled differently
- Second host. We forgot about having a second domain
- Interception of all links. At one moment the application started capturing all the links with our domain (even those for which we had no scripts)
In the meantime, share your impressions in the comments. Maybe you’ve encountered something similar? Any experience is extremely important (that’s what we’re here for :)). See you soon!
