Deep Link Bug

Below I document some findings around the problem of changing deep links, some of them have been recorded/discussed by @ThinhDinh @Wiz.Wazeer @wjcv06 @yinon_raviv @Darren_Murphy @Jeff_Hager

This is an example structure of the deep link:

The t stands for the position index of the “parent” tab of the Detail Screen, from which you derive the deep link in the app mode!
The index is counted in the builder and starts with 0, if there are hidden tabs in the builder this doesn’t influence the position number. The index hence is not related to the visible tabs in the app!
If one moves tabs around in the builder, the deep link changes

N stands for the name of the Detail Screen, if one changed the name → the link changes.
R stands for the RowID of item in the sheet.

BUT there is a big problem!

A common scenario:
Say you have 4 tabs, named Tab1-4
And you’ve recorded the deep link from a detailed screen named Screen3, and it’s parent tab (Tab3) was on position 3 in the builder. If then the position of that tab changes to position 4 (e.g. by duplicating a tab on position 0, or moving the tab manually, …) and let’s say Tab2 is now on position 3 (in the builder).

If then someone clicks that deep link of Screen3, the correct detail Screen3 is been opened and the correct row is shown. But, if the back button is been clicked, this leads to Tab2 and not to the parent tab of the Screen3 (which is Tab3) as expected, as this tab is now on position 3! → This can lead to a totally confusing UX in the app.

You can try this out in the following public test app: Move tabs around…
The decoder I’ve used is shown on the main tab.


Very well explained! :clap:

Closing due to inactivity. This topic will be deleted in a few weeks if there are no more comments.