Open Apps from a HTTP URL (Android Intent)
Opera for Android (v42) seems to be missing the feature to open an App via HTTP URLs such as https://www.google.com/maps/search/?api=1&query=City+Hall%2C+New+York%2C+NY
On Chrome on Android, the above URL leads directly to the Google Maps App (as documented in the Google Maps docs). In Opera, the Google Maps web page is opened instead. Not even a dialog to select what to do (open web page or open App) is displayed. It would make sense to at least have the choice to open the App (especially for cases like Google Maps or Wikipedia).
Is this indeed a missing feature (then I'd suggest to implement it) - or did I overlook something?
If this is really intended behavior, I suggest to change it.
@Mods: Could you please amend a "[Suggestion]" before the title of my first post?
I see the following arguments PRO opening Apps from HTTP URIs:
- It is the user's will and expected behavior. A user actively chooses to install an App with certain intent filters or custom URI protocols. He/she expects that a web browser adheres to these standards and uses the App instead of the website. Also, developers expect this to work as the Google documentation (see above) implies that this works on the whole android system.
- If the App is installed, the user may want to use it instead of the website. At least, he wants to have the choice. If I were to click on, e.g., a Google Maps HTTP URL for a business address with the goal to save this address to my favorites, I could do that at once if I had the option to open it in the Google Maps App directly. From the mobile website, I'd need to log in separately (!) or copy & paste the link to the App. Further examples include using Google Maps for navigation (Native Features like Bluetooth connectivity and Offline capabilities needed). You can find numerous use case for other Apps that have web counterparts such as YouTube.
- Opera already supports this behavior for other URI (geo:). For instance, clicking on a Geo link like
geo:0,0?q=business+near+cityalready opens a popup, where the user can launch a respective maps App. A smartphone user often cannot even see if a link is a Geo link or a Google Maps HTTP link (there is no mouse over and URI hint). In my opinion, it makes the whole behavior inconsistent. I really cannot see why there is a distinct difference between these URIs in real-world cases.
Regarding the security argument from your post above. If this is really the reason, I see a specific problem with this line of argumentation as well:
- Opera cannot vouch for the security of other websites either. In fact, especially for common YouTube and Maps, I cannot why they should be less secure than their website counterpart. Apps at least (usually) go through a Play Store verification.
Moreover, several android vulnerabilities affected both websites and Apps to the same degree (e.g., Stagefright). Therefore, I do not see that always preferring websites over an installed App (and not even offering a choice) increases my security in any way.
Conclusively, I think that Opera should at least offer a choice to open such URLs either in the browser or in the respective App(s), e.g., using a popup as in Chrome or for the Geo links. It would promote user choice, follow expected behavior, and offer a consistent experience, which makes Opera on-par with its competition (Chrome) again.
It is somewhat disputable that this be the expected behavior.
This has been filed as a bug for Opera Mini not long ago, and has been fixed, so that it works perfectly in it now.
In Opera Mobile (Android), it is still not working in 43.
I filed a bug as ANDEX-52214 but unfortunately bugs / development issues handling at Opera are just as transparent as a piece of andesite.
For what it's worth, this seems fixed in the latest Beta (44).
Hopefully it will make into the next release.
I tried the latest Opera for Android 44 stable (44.1.2246.123029). Unfortunately, I still cannot open web links in associated apps (e.g., YouTube, Google Maps).
If this already worked in the Beta, I really hope that this feature will be added (or the "bug" will be fixed, however you see it) to the stable version in the near future, because I clearly see a case for this one.