"Win10 UWP" URI Scheme (ii): processing and application scenarios for custom protocols

The previous article mentions the use of the Windows Store protocol, in fact the Windows Store protocol is only a protocol rule built into the system. We can also define a set of specifications of the Uri-scheme, in addition to other applications can be called, the application can also be called, to solve some special scenes, this talk about the specific discussion of this issue.

For the resolution and use of the Windows Store protocol, you can read the previous article: http://www.cnblogs.com/zhxilin/p/4819372.html

I. Handling of custom protocols

As mentioned earlier, through the protocol, the application can be "activated (Activated)", and can handle the operation after the activation itself. The App Store app is very simple, it defines a "protocol" type of declaration called Ms-windows-store in Package.appxmanifest, we can simulate:

Since Ms-windows-store is defined as a built-in protocol, we cannot use this name when we customize the protocol, which is replaced by Ms-windows-store1.

For more information on the use of built-in protocols, please refer to: https://msdn.microsoft.com/en-us/library/windows/apps/mt228340.aspx

Back in App.cs, overload the Onactivated method, which receives a parameter of type Iactivatedeventargs:

1 protected Override Async void OnActivated (Iactivatedeventargs args) 2 {3    // Todo:handle Activate action 4 }

Using the kind property of the args parameter to determine what type of application was activated, we only handle activation of the protocol type (since the custom Protocol is a protocol):

1 protected Override Async voidOnActivated (Iactivatedeventargs args)2 {3     if(args. Kind = =Activationkind.protocol)4     {5          if(!_haslaunched)6         {7 createrootframe ();8_haslaunched =true;9         }Ten   One          var protocalargs = (Protocolactivatedeventargs) args;  A          if (protocalArgs.Uri.Scheme = = appconfig.myappscheme)  -         { - Urlschemehelper.parsescheme (Protocalargs.uri); the         } -     } - Window.Current.Activate (); -}

Determined that after the protocol activation, the args will be converted to the corresponding type of parameter Protocolactivatedeventargs, and finally we like to deal with a normal HTTP URL, custom one Urlschemehelper class for parsing and page navigation, Specific treatment please self-brain hole.

Two. Meaning of the custom protocol

It's a cool thing to customize the protocol and respond differently to the call protocol. Not only can the third-party application call, but also to the application itself call, processing some special scenes! Here's what I'm going to say. A special application scenario is the interaction between the app and the Web page .

The interaction between the app and the Web page is very common, the General page will consider the direct use of the script to notify, and I believe most front-end developers have been driven crazy: WP needs a processing, iOS is another processing, the front-end to judge the request from what platform, but also inaccurate, blabla .... Overall the problem is very much!

Now there is a need, such as in a Web page has a button, triggered by the button to ask the app to jump to a specific page, usually write a script should be like this (UWP should use the window.external.notify ("") function , and can only return strings)

1 function Onnavigateclick () {2    window.external.notify ("Navigate:some_page"); 3 }

The app registers a void Browser_scriptnotify (object sender, Notifyeventargs e) event on WebView, via the parameter E. Value takes the notification content "Navigate:some_page" of the Web page out and handles it accordingly.

However, the limitations of the Scriptnotify event are very large:

1.window.external.notify can only return a string

2. Only local Web pages (Ms-appdata, Ms-local-stream, or ms-appx-web), or trusted HTTPS, can trigger events; Normal HTTP cannot be triggered

Most Web pages are HTTP, and if downloaded to a local display is often problematic, this interaction is a nightmare for the UWP! Not only the front end pain, client also pain!

This time the custom protocol can play its skill! The same example can now be changed into the form of a protocol to inform:

1 function Onnavigateclick () {2    window.location.href = ' Myapp://page?id=1&title=hero '; 3 }

The app uses the above mentioned method to receive notifications!

Wait, in a UWP project, in a webview, an HTML page notifies the app in the form of a custom uri-scheme, webview triggers a unsupportedurischemeidentified event, indicating that WebView does not recognize this protocol and whether to deal with it depends on you.

The webview of the UWP can only handle protocols such as HTTP, HTTPS, Ms-appx-web, and Ms-local-stream, and will trigger unsupportedurischemeidentified events for other protocols. and a warning dialog box pops up:

In order not to display this dialog box, we need to handle it manually:

1 Private Async voidwebview_onunsupportedurischemeidentified (WebView sender, Webviewunsupportedurischemeidentifiedeventargs args) 2 {3       args. Handled = true; 4       if(args. Uri.scheme = =appconfig.myappscheme)5       { 6            awaitLauncher.launchuriasync (args. Uri); 7       } 8}

First, the args. Handled is marked as true, the warning dialog box does not pop up, and then attempts to start the WebView unrecognized URI by launcher, and finally receives and parses it in the app.onactivated with the processing method described above.

This benefit completely frees the front-end development pressure, which applies to a wide variety of clients (IOS, Android, WP, windows, etc.), and for clients, defining a normalized uri-scheme helps maintain and extend Can even evolve into a development platform or open app (like a store app).

"Win10 UWP" URI Scheme (ii): processing and application scenarios for custom protocols