Designing Loosely Coupled Metro Applications with URIs

Posted by Jonathan Allen on Sep 15, 2011

Sections

Enterprise Architecture,

Architecture & Design,

Development

Topics

HTML5 ,

Javascript ,

HTML ,

Rich Internet Apps ,

Web Development ,

Dynamic Languages ,

C++ ,

Markup Languages ,

.NET ,

Languages ,

Compilers ,

Programming ,

Interop ,

Windows 8

Share |

RELATED Research

Metro-style applications are meant to be small and highly-focused. The large scale, monolithic applications that we traditionally build for the enterprise can be reimagined as work-flow specific tools. For example, a stock trading application you may have one tool for locating and viewing basic customer information and another for researching financial products. From either of these modes you would then need to jump over to the “purchase a stock” workflow, which may be in an entirely different application.

The way you can do this in Metro is by leveraging protocols. For our example above the protocol may look like “acme-stock-purchase://client=123&stock=XYZ”. At install time the stock purchasing tool would be registered to listen for messages sent to the “acme-stock-purchase” protocol. When that happens the tool is launched and receives the indicated parameters.

The code to handle this is quite easy to write and is available in C++, .NET, and JavaScript based applications. The code excerpt below shows a C++ application listening for OnActivated and OnFileActivated events. The latter is used when launching the application via a registered file type.

  
void App::OnLaunched(Windows::ApplicationModel::Activation::LaunchActivatedEventArgs^ args) 
  { 
    Window::Current->Content = ref new MainPage(true); 
    Window::Current->Activate(); 
  } 

  void App::OnFileActivated(Windows::ApplicationModel::Activation::FileActivatedEventArgs^ args) 
  { 
    MainPage^ page = ref new MainPage(false); 
    page->SelectScenario3(args->Files->GetAt(0)->Name); 
    Window::Current->Content = page; 
    Window::Current->Activate(); 
  } 

  void App::OnActivated(Windows::ApplicationModel::Activation::IActivatedEventArgs^ args) 
  { 
    MainPage^ page = ref new MainPage(false); 
    if (args->Kind == Windows::ApplicationModel::Activation::ActivationKind::Protocol) 
    { 
        Windows::ApplicationModel::Activation::ProtocolActivatedEventArgs^ protocolArgs = dynamic_cast<Windows::ApplicationModel::Activation::ProtocolActivatedEventArgs^>(args); 
        page->SelectScenario4(protocolArgs->Uri->RawUri); 
    } 
    Window::Current->Content = page; 
    Window::Current->Activate(); 
  }

This sort of communication is one-way, the source application has no way of knowing how the destination is going to handle the message. While this limits some of your design choices, it keeps the various tools loosely coupled. As your companies business needs change individual tools can be updated without having to redeploy the whole stack.

Since these are URIs, they don’t have to be triggered by another Metro application. Any application that is capable of launching the web browser using “http://sample.com” can launch a protocol-enabled Metro application. Likewise users can simply paste the URI into the Run menu or the address field in either Windows Explorer or Internet Explorer. This allows developers to easily integrate legacy, web, and Metro applications.