How-To: Last Chance Exception Handling in WinJS Applications

One of the things we designed MarkedUp to do was to be able to capture and save fatal errors that crash your Windows 8 applications and to reliably transmit them back to the developer for analysis and diagnosis.

Most fatal errors fall into one of two categories:

  1. Something went wrong with the environment outside the application, like an OS / driver error or an hardware issue; or
  2. The application failed to handle an exception thrown by the application itself.

Fatal errors in category #1 are impossible to recover from (usually because the application runtime or OS crashed) and are typically outside the control of the developer anyway.

Errors in category #2 are firmly in the control of the developer, however – and I’m going to show you how to tackle them in WinJS.

Sometimes you’re going to forget to handle an error in-context in your application – so what can you do to stop unhandled exceptions from crashing your application? Use the last-chance exception handler.

If you’ve done any serious Windows Phone 7 development, then you might have worked with LittleWatson at some point for simple last-chance exception handling and reporting – like this:

So how do you tackle this in WinJS?

The answer is fairly simple – in your default.js file you just need to chain an event handler to WinJS.Application.onerror event, like this:

In this instance I’m just using MarkedUp to transmit the fatal error message back to our servers next time the app starts (which is really the only safe way to capture a fatal error message.)

This technique has worked well for me for my Windows Phone 7 applications and should work fine for WinJS / Win8 too!

New Change in the Windows Store TOS: Any App with the Word “Metro” in the Title is Insta-Failed

Just in case you weren’t reading your Hacker News last week, you might have missed the news that Microsoft has decided to abandon the name “Metro” for its distinctive user interface that’s been used to power everything from Windows Phone 7, the new Xbox UI, the Windows Azure portal, and of course: Windows 8.

Suffice it to say, there were a lot of developers who were disappointed with the decision.

I thought it was rather spineless on Microsoft’s part to let Metro UI fade into the night – if Apple can spend $60 million putting an iPad trademark dispute to rest, then why wouldn’t Microsoft spend what it needs to keep the brand that’s heralding the new area of desktop and mobile application development on their flagship platforms.

So imagine our amusement today here at MarkedUp HQ when Erik reviewed the Windows Store “Before Your Sell Your App” guidelines and discovered this gem in the section regarding how to name your Win8 applications* (emphasis ours:)

Note  Make sure your app name doesn’t include the word metro. Apps with a name that includes the word metro will fail certification and won’t be listed in the Windows Store.

Looks like our friends at MetroTwit and other popular ported WP7 applications (many of which include the word “Metro” in the title) are going to have to undergo a similar rebranding to “the New Windows UI” or whatever we’re calling Metro now.

The Metro brand is a unifying force for developers building on Windows Phone and WinRT – after years of being promoted heavily by Microsoft as the new design language for their consumer-facing developer platforms it’s become both popular and self-descriptive.

Stripping the name away has ramifications beyond muddying Microsoft’s message to developers – it cripples the developers themselves who wanted to identify themselves with and support the Metro brand. Imagine if Apple caved and banned every application that began with a lowercase “i” at the start of it – it’s as severe a blow as that for a nascent and upcoming platform.

Abandoning Metro was the wrong thing to do – it ultimately won’t impact the developer opportunity for Windows 8 or the consumer app experience itself, but it completely undermines both Microsoft’s and their developers’ abilities to succinctly differentiate their WinRT / Windows Phone properties apart from everything else.

*Look mid-way through the page.

Introduction to MarkedUp

markedup-logo-smlAs I announced on my personal blog earlier this morning – today marks my last day with Microsoft. I am sad to be leaving such a tremendous and awesome organization, but I am very excited about what we’re going to be doing with MarkedUp moving forward.

Our vision for MarkedUp is simple: we want to make it really easy for WinRT developers to get actionable insights on how users are consuming their applications.

 

We intend do this through providing WinRT developers with kick-ass analytics and reporting on in-app behavior and more.

MarkedUp is a service created by developers, for developers. We created MarkedUp because it’s something we wanted for our own applications first and foremost.

We’re gearing up to put a beta version of the product in market soon, so if you’re developing for Windows 8 or Windows Phone 8 we strongly suggest that you sign up for updates on MarkedUp.

If you have any questions, feel free to leave comments here or reach out to MarkedUp on Twitter.

-Aaron

Engines Start. Development is Go!

Welcome to the inaugural posting of the MarkedUp blog!

Hopefully the first of many such posts. On this blog we’ll share our experiences not just with developing MarkedUp but with our general development experience from Windows 8 development and others as well.

We’re a passionate bunch of developers and hope this blog and the posts that follow will help the greater development community as a whole. Even if it’s just in small way. Since that’s what we do.