Last week I received an email with a link to a comment on merge request that I wanted to respond to. Even though I have an app installed on my phone where I'm signed in and can view and comment on the merge request, when I clicked the link it opened up in my browser where I was not signed in. This was less than optimal. Three days later I published an app to scratch my own itch - and that of other people in my situation. Here's how I arrived at my solution.
My company uses a private instance of GitLab to host all our source code. Since it is a private instance, our projects are only accessible via our custom domain - not gitlab.com. In order for the link in the email I received to open in LabCoat, the app I use to browse our source code on my phone, LabCoat would need to register as a handler for any url on our custom domain.
Desired behavior v1
- User installs LabCoat.
- User signs in to GitLab instance.
- LabCoat registers as a handler for links to the domain that was used during sign in.
- Links to GitLab instance open in LabCoat.
- Bonus: If the user signs out of all of the accounts on a particular domain, LabCoat could unregister as a handler for that domain.
Dynamic deep links
Handling links to content at different layers within your app is called deep linking and it is not a feature any of the apps I have worked on have required, so I started by doing a little research. I quickly discovered that an app must declare all the urls it intends to handle in its Android manifest and new deep link urls cannot be added dynamically.
Dynamic-ish deep links
Even though an app can't add or remove deep link urls, apps can often enable and disable components that have been declared in their Android manifest. Perhaps I could submit a patch to LabCoat to include our custom domain in a list of urls it is capable of handling. Most, if not all, urls would be disabled by default, but when a user signs in to a site in the list it is enabled (and disabled again when they sign out).
Unfortunately, I found an open issue on the LabCoat project that suggests that this avenue of inquiry is a dead-end. The issue requests that LabCoat add a handler for the urls of three or four very large and very well known GitLab instances. The maintainers of Labcoat have declined to do it, because they don't want to have to add urls for every small GitLab instance. Basically they didn't want to receive the kind of patch I wanted to submit.
However, that led me to look at the code LabCoat has already implemented for handling deep links. It handles two types of links - gitlab.com links and links starting with labcoat://
Desired behavior v2
- User installs LabCoat and a separate app deep link app, in no particular order
- User signs in.
- Links to GitLab instance open in LabCoat
Since LabCoat has registered to handle links with a custom scheme, all the deep link app would need to do is redirect any links to private GitLab instances to LabCoat using its custom scheme.
Not only does this prevent the LabCoat app from ballooning to support GitLab instances that very few users will ever use, it frees the developer of that app from having to deal with all the related merge requests and support issues too.
That's probably why he thought it was "an awesome solution".