Improved deep linking support

#1

All,

IOS already supports some level of deep linking, which is documented here: https://rocket.chat/docs/developer-guides/deeplink/. This leverages the scheme name “rocketchat” to specify that it should be opened in the app. Of course such a link would be essentially broken on desktop and Android, which is problematic as we don’t know the device ahead of time when we send links to other users.

At the same time there appears to be some work on a redirection server that will support deeplinking via URLs of this form go.rocket.chat/room?host=foo.bar.com&rid=1234&path=group/important. Thanks @aaron.ogle for making me aware of that service. This link opens the web based client on desktop and Android but does not open the installed Android client currently.

So I wanted to try to document the use cases and then hopefully provoke some discussion around current efforts to support these use cases and then also how we can define additional features required to cover all of them.

When a “deep link” URL that contains information identifying the server and the room (or DM) is clicked by a user the following use cases should be supported depending on their device:

  1. User on desktop should click a deep link and go to the web version of the room (or DM) referenced in the link after either signing up or logging in.
  2. Users with rocket.chat installed on IOS and Android should click a deep link and go directly that that room or DM after either signing up or logging in.
  3. Users without rocket.chat installed, should first be taken to the play store to install the app and then proceed to #2 use case.

My understanding is that today #1 is supported by the redirection server approach described above and that #2 on IOS is supported by the scheme-based approach. Does #2 on IOS also work via the redirection server approach?

What is our plan for supporting #2 on Android (across all supported versions of Android) and supporting #2 and #3 on IOS and Android?

0 Likes
#2

A good survey of the complexity:

https://blog.branch.io/universal-links-uri-schemes-app-links-and-deep-links-whats-the-difference/

0 Likes
Invite New Users Feature
#3

Thank you for bringing this subject to a conversation, deep link is very important for a smooth user experience in a mobile device.

  1. We created the go.rocket.chat. redirect so we could from the web control what direction should that link go, exactly like you said. It was suppose to be working for both iOS and Android. iOS and Android also understands the URL https://go.rocket.chat, so you press a link with this subdomain, the app should be opened in case it’s installed.
  2. iOS supports all the deeplinks in the documentation, Android only supports the authentication one for now.
  3. “If the app is not installed, it should redirect the user to the store”: well, that depends. If you’re really in a rush to open the link and you don’t want to download an app, you can do your task on the web browser. Maybe the web could present you a webpage with two options? “Go to the website version” or “Download the native app”? :thinking:

I think we can definitely increase the amount of deeplinks we have to offer more flexibility and options to the users, and I also agree that Android should be handled correctly from the webpage… let me know what you guys think about my point 2 please.

Regarding the missing deeplink support on Android to open a room, I just created an issue for that: https://github.com/RocketChat/Rocket.Chat.Android/issues/1415.

Any other ideas of deeplinks to be supported other than what we currently have on the documentation?

1 Like
#4

Two questions:

  • Assuming issue 1415 gets fixed, what is the earliest Android version that will support this?
  • For your #3 above, do we want to consider https://developers.google.com/web/fundamentals/app-install-banners/native. It seems less annoying than the typical app install banners. Essentially the user can use the web version and install the native app without an interstitial and without leaving the web version. Not sure this is available on IOS.
0 Likes
#5

I think we need to make sure to cover at least Windows, Mac OS/X, and Ubuntu Desktop in these scenarios. Including re-direct to App stores on Windows, Mac, and Ubuntu.

0 Likes
#6

Sorry never got back around to posting here.

For #3 the idea was to potentially store a fingerprint with the url with super short timeout. But long enough for them to be redirected to App Store and install. Then… when the app first stars sends the same fingerprint to the service which would retrieve and add the server and the app would have what ever other info was passed.

(Of course things like tokens likely would not be stored)

0 Likes
#7

We have this working as part of Android invites and will have a PR soon.

0 Likes