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:
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.
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.
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?
Thank you for bringing this subject to a conversation, deep link is very important for a smooth user experience in a mobile device.
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.
iOS supports all the deeplinks in the documentation, Android only supports the authentication one for now.
“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”?
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.
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.
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.
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)
Hello, we are intending to roll out an implementation of RC shortly, and would like to be able to minimize the setup process across all platforms in that we’d be interested in pre-configuring a chat server URL in the application. At first, I was thinking this might need to be done by changing code, but then I found the documentation for the deeplink support. I’m not sure how feasible it is to have users start RC every time using deeplinks, and I also noticed it doesn’t quite work on my Android mobile installation. That having been said, does anyone have suggestions on how this might be able to be accomplished? I am not opposed to modifying code, but probably want to reserve that as a last resort.
I think I read somewhere (I forget where) that a JSON file could be included that might be able to be pre-configured with server URL(s) so that the application would automatically know this information without the user having to set it up.
Also, any further thoughts on how deeplink might help in this situation would be appreciated (although I’d have to get confirmation that it is working as intended on Android). Other alternative ideas are welcomed as well.
