When an mCent member clicks a link to start an offer, the member will need to go from mCent, to browser, then finally to Google PlayStore. In addition to this inconvenience, we do not know if this link will still be valid when the user clicks it. No matter how strict we control what we show to our member, there will always be surprises at runtime for our user. This, by all standards, is not a good experience. At Jana, we aim to provide the best user experience and here’s how we approach this problem.
We realized that both of these issues can be solved by handling the URL links ourselves instead of letting Android’s default behavior on URL links to take control. As always, there are multiple ways to solve a problem. We believe that the most important aspect for us when it comes to handling URL links is the redirects. We do not want to trouble our member when the needless redirects are happening. Here are several approaches we tried:
- Using Volley with HurlStack, overriding createConnection() and disable following redirects
- Using Volley with OkHTTP
- Using Volley with custom HTTP stack
- Handles HttpURLConnection manually in the background and follow the redirects ourselves
- Using WebView, overriding shouldOverrideUrlLoading() to track redirects
It is easy to see that the WebView method is the cleanest among those approaches. And it would be possible to utilize WebView in the service thread and try to trick it as being displayed. However, an easier approach would simply be setting the WebView element as invisible/gone and load it without changing the UI, literally loading WebView in the background.
We start by adding WebView to the XML file for our activity. Setting the visibility to gone or invisible.
Using the WebView, we can set our custom WebViewClient with our override methods and take over the control when a url is being loaded.
Calling loadUrlWithWebView() method will load the URL in our WebView instead of opening in browser. On each redirect, shouldOverrideUrlLoading() will be called and we can start tracking where the link will go and what to do should there be an error.
Since now we control the loading process of URLs, we can decide what to do when a member lands in specific domains. For instance, should a member tries to open a link that eventually leads to the Google PlayStore, wouldn’t it be better to just open the page in the Google PlayStore App if the phone has the application? Luckily, if we try to open a market link in Android, the OS will try to open it in the Google PlayStore App first.
With above function, it will try to open in the Google PlayStore App first, if the phone doesn’t have the application, we will try to open it in a browser, the default behavior.