Add support for Custom URI Schemes

[ysfchn]

Is your feature request related to a problem? Please describe. Some applications might want to register a custom URI on the system, for example when you go to example://thing it can launch the app. This may be useful when you want to launch an app from a web page. As Custom URIs support parameters, you can even pass query strings like normal URLs.

Describe the solution you'd like As far I know, all operating systems are already supports custom URI handlers. Some of them are:

• Android - with modifying the manifest (Android calls as Deep Linking)
• Windows - by modifying the Registry
• Linux - by adding MimeType=x-scheme-handler/example; entry to .desktop file

As beeware's own cookiecutter templates contains files for setting build configuration, a uri-schemes option can be added to [tool.briefcase] setting, then inject scheme handler with cookiecutter templates.

[tool.briefcase.app.example]
formal_name = "Example"
description = "An example app."
author = "Yusuf Cihan"
uri-schemes = [
    "example" # Will register "example://" to system.
]

I'm considering creating a PR for this feature, but I still wanted to create this issue, as someone might be able to add this feature faster than I can.

Describe alternatives you've considered I'm currently cloning the cookiecutter templates from beeware's own repositories and replacing .wxs and .desktop files with my modified files, however if briefcase had a configuration itself that adds required keys to build files, it would be very easy.

[freakboy3742]

This is absolutely a feature we should support - thanks for writing this up as an enhancement request!

This is an areas where we need to be consistent with an existing feature - Briefcase already has support for document types; it's only implemented on macOS, but the configuration option exists and could be implemented on other platforms.

So - we need to work out if there's any overlap between those two features; and, if necessary, make the configuration consistent.

[ysfchn]

URI schemes only handle URLs (myapp://) where document types are for files (example file.myapp). At first I thought it can be added under document types configuration, but if we add schemes under document types, then it can be confusing for people who want to handle a URI scheme only, not a file extension. It might make more sense to include both file extensions and URI schemes if the document type configuration were renamed to handlers, but the current configuration name is document_types.

Also, document types are not handled the same with URI schemes, they need to be registered separately on the system.

[freakboy3742]

The fact that URI handling and document types aren't quite the same is a good point - I was overthinking things.

Looking cross platform, macOS and iOS need a little more metadata to register a URI type, so we're probably going to want to use a section parallel to document_types that allows definition of a human-readable name, icon, and role. These identifiers will have reasonable defaults (e.g., icon can fall back to the app icon), but we should provide enough flexibility to customise where needed.

[ysfchn]

I agree on giving more flexibility to customize, looks like we can also define icon and name on Windows too (optionally), I'm not sure about other platforms but yes, it is better to implement a new section same as document_types that will both support icon and name.