Windows 8 Development - Application Startup

10 June 2014

Unlike a web application, which always starts because someone has requested a page, Windows Store applications can be started for a whole host of reasons. It could be that the user has to click on the shortcut/tile to start your app. But, it could also be from the camera sharing a photo with your app, another application (e.g. a web browser) sharing data, or an auto-run triggered by the user inserting a flash drive. There are a whole host of activation kinds that your application can respond to.

Windows.UI.WebUI.WebUIApplication

As you application loads, WebUIApplication provides you with the activated event. This event can be used for any preprocessing that your application needs to do during the startup process. However, it is the only startup event that WebUIApplication offers. It occurs just after DOMContentLoaded. This means that the markup of a webpage has been parsed, but that not all of the resources may be loaded yet.


The activated event gives you a IActivatedEventArgs object as its arguments, and contains information about the reason for the startup.

 1 var app = Windows.UI.WebUI.WebUIApplication;
 2 app.onactivated = function (args) {
 3     //The reason that this app is being activated. 
 4     //This value is an integer based on the activation kind enum.
 5     var kind = args.kind;
 6 
 7     //The execution state of the app before this activation. 
 8     //This value is an integer based on the activation kind enum.
 9     var previousExecutionState = args.previousExecutionState;
10 
11     //The splash screen object that provides information about 
12     //the transition from the splash screen to the app.
13     var splashScreen = args.plashScreen;
14 };

The activation event above is fairly simple and its arguments are consistent. It always has the properties:

If you plan on handling more than one activation kind and there is a distinct difference in the way you handle the different kinds, I recommend using multiple event handlers. This will make your code cleaner, more testable, and easier to read.

 1 var kinds = Windows.ApplicationModel.Activation.ActivationKind;
 2 function userLaunchHandler (args) { 
 3     var kind = kinds.launch;
 4     if(args.type != kind) {
 5         return;
 6     }
 7 
 8     //Handle user launch...
 9 }
10 
11 function cameraLaunchHandler (args) {
12     var kind = kinds.cameraSettings;
13     if(args.type != kind) {
14         return;
15     }
16 
17     //Handle camera launch...
18 }
19 
20 Windows.UI.WebUI.WebUIApplication.addEventListener("activated", 
21     userLaunchHandler);
22 Windows.UI.WebUI.WebUIApplication.addEventListener("activated", 
23     cameraLaunchHandler);

WinJS.Application

As I mentioned in a previous post, WinJS.Application has events that wrap Windows.UI.WebUI.WebUIApplication. WinJS events are more verbose than their WinRT counterpart during application startup.

To use the WinJS events, at a minimum, you have to include WinJS' base.js and call WinJS.Application.start().

1 <!-- This is required for WinJS.Application events -->
2 <script src="//Microsoft.WinJS.2.0/js/base.js"></script>
3 <script type="text/javascript">
4     WinJS.Application.start();
5 </script>

WinJS.Application has not one, but three events that fire during application startup.

Not only are there more events during activation in the WinJS framework, but the event arguments vary based on the "type" parameter. onactivated has a whopping 12 different possible argument types. If not handled using Clean Code practices, a handler of the WinJS activate event can be extremely sloppy and unmanagable. Based on my experience, I feel that this type of event signature will likely lead the average developer to use a switch statement. I find this to be unsavory on the part of the framework developer because it leads his/her consumers down the wrong path. Switch statements should be used sparingly (if at all) because they break well establed practices such as the Single Responsibility Principle. This makes the code harder to test. It makes the tests more brittle because there are multiple reasons for your handler to change. And, most of all, it makes it harder to read and maintain in the long run. If you need to respond to more than one activation type, I recommend separate event handlers.

While it is true that you would have to do a similar thing using the WinRT API, the WinJS API is just that more complicated because of the variation of they types in the event arguments. Furthermore, since the "type" property is given as a string, you cannot compare it to the Windows.ApplicationModel.Activation.ActivationKind enumerator like you could in the WinRT event handler. Also, during debugging, I have often seen the value activated, which isn't even in the kind enum. I find this inconsistency a bit sloppy.

 1 function userLaunchHandler (args) { 
 2     //This value is a string based on the activation kind enum.
 3     if(args.type != 'launch') {
 4         return;
 5     }
 6 
 7     //Handle user launch...
 8 }
 9 
10 function cameraLaunchHandler (args) {
11     //This value is a string based on the activation kind enum.
12     if(args.type != 'cameraSettings') {
13         return;
14     }
15 
16     //Handle camera launch...
17 }
18 
19 WinJS.Application.addEventListener("activated", 
20     userLaunchHandler);
21 WinJS.Application.addEventListener("activated", 
22     cameraLaunchHandler);