View or download the video on Channel 9 (includes higher quality video)
Bad stuff happens! There is no way around that. It’s a fact; your apps, out there in the wild on consumers devices, will crash. This in itself is ok but only if you can get the information about those crashes and use that information to fix the bugs that cause them. The Windows Phone platform actually captures stack traces and provides those to you, the publisher of the app. You can get a view of the number of crashes that are happening as well as download an Excel file with all the appropriate information and stack traces. This is a good thing and you should take advantage of that information as it may give you some good clues as to what to fix to make your app a higher quality product.
There are a few things that App Hub does not give you though. The first thing is that it may not give you enough information about the bugs that you are hitting. One example of that is that the version number of the app is not provided so if you have published a few different versions of your app it is possible that a user is hitting a bug that you may have already fixed in a later version.
The other issue is that stats on App Hub are delayed. As a result you don’t see the issues that your end-users are hitting for a few days. If something is happening out there that is causing a lot of crashes then you may not see it until after users start posting lots of low ratings and negative reviews.
Another thing to keep in mind is that App Hub does not provide any sort of notification of issues. It’s up to you to visit App Hub regularly and pull down those stack traces to see what’s going on.
Finally (and I realize this is more a perception thing than an issue) end-users have no idea that the platform is gathering up those stack traces and making them available to you. And, of course, they have no idea if you are looking at those traces and working on bug fixes. As a result, when they see a bug most will assume the worst and give bad ratings and reviews. As I’ve mentioned on a previous post you really want to make sure that, whenever you can, you provide the ability for the end-user to provide you feedback as that helps build a relationship which ultimately will result in higher ratings and ranking.
Fortunately there is a way to get around all of these issues. Andy Pennell, a colleague on the Windows Phone dev team has posted some sample code which he dubbed Little Watson that I think every developer should include in all their apps. Just like “Big” Watson does on Windows, that code does exactly what you would expect in that it captures all that stack trace info (including additional info you may need) and allows the end user to email it you so you can get to work fixing whatever bug caused the error.
Little Watson is pretty easy to use. There are a few steps that you need to do:
- The first is to include the LittleWatson.cs in your project
- Then you need to let Little Watson know every time an exception happens. When you do that Little Watson captures the trace info to isolated storage. This is done by calling LittleWatson.ReportException. You’ll need to do that in both RootFrame_NavigationFailed and Application_UnhandledException. Both of those are in App.xaml.cs
- Finally to allow the end user to send you the stack trace you’ll need to add a call to LittleWatson.CheckForPreviousException() in the constructor for your main page (i.e. whatever page it is that your app launches into, usually that is MainPage.xaml.cs). When you make that call Little Watson checks for an exception report file in isolated storage and if one exists prompts the end user to send it to you via email.
Since Andy blogged about Little Watson, other devs have grabbed that great idea and taken it further. One example of that is the Northern Lights open source project. Northern Lights has many different capabilities that are useful to Windows Phone developers. One of those is an implementation of Little Watson based on the work I mentioned above from Andy Pennell. One thing that Northern Lights does beyond Andy’s code is that they provide you the capability to automatically send the trace info to a web service behind the scenes so that the end user does not have to see it. You should probably be careful in doing something like that. As I mentioned above, it might actually be a good thing for end-users to know that you care about bugs. You may also want to be careful about sending stuff to a web service behind the users back. Some users will get freaked out about that if they notice. This would be especially bad if you were including any sort of Personally Identifiable Information (PII) along with those traces. In general, you’ll probably want to let users know somehow that you are doing that and definitely stay away from capturing any PII.
Below I’ve included the source code for the project I used in the video. It’s a ridiculously dumb app but I often get asked for source so I’m including it here for completeness.
Let me know what you think about this episode of Top Ranked.
If you have questions about any of the videos, about problems or issues you’re hitting or if you have topics that you think would be of interest to other devs on the Windows Phone platform then drop me a note. I’d be particularly interested in hearing about some of the best practices you’ve adopted that you think have raised your quality or your ratings/ranking in the Marketplace. I’ll be sure to give full credit and link love whenever I can.
The Top Ranked series is hosted on Channel 9. You can view all the past videos there. You can also subscribe to the entire series via Zune or iTunes. All of that is available here:
https://channel9.msdn.com/Series/Top-Ranked
Let me know what you think by dropping me a note with the contact form on my blog here:
http://blogs.msdn.com/b/benriga/contact.aspx
Or better yet follow me on twitter and drop me a note there:
https://twitter.com/benriga
CrashKing.zip
I spent the last 2 weeks traveling through various countries through Europe talking to developers of all kinds. The whirlwind tour through 7 countries in 14 days gave me an opportunity to hear many ideas and concerns and to learn about what developers are out there building. 
