When you develop and app for Windows Phone there is always an urge to get the project published and start making an impact on your future users. However, if you don’t make sure you have some visibility of usage and behaviour in the wild, it becomes a guessing game to enhance and maintain it.
Why Use a Logging Framework?
Once you have published you app, it is in the wild. You can decide which markets it is in and what types of devices, such as high powered and certain hardware requirements, but you can’t pick and choose the users that download it. Once you get that message saying your app has been published, you got to let your baby go. Or do you? One of the problems I have had, is that as well as you can test your project there is always that niggling doubt that you missed something or that a certain edge case will cause your app to break. I don’t like uncertainty, and when your app is in the wild that is pretty much what you are left with. How do you know when something fails? What can you do if the app does crash on the devices, displays the information incorrectly or can’t find that web service half the times it tries. With a traditional web application or desktop application you can monitor things and set up event logs. Further, how can you tell how often it fails? So not only might your app fail on a particular scenario, but how often does it happen? You need to know if it is a part of a critical path, resulting in a large percentage of failures, or if it is only in some obscure edge case, in order to prioritize the bugs you have to fix.
How can you know which features are popular and could benefit from being extended further? How do you update the project in the right places and with the most valuable features, if you are blind to how the app is used?
How can you manage the bugs that you do become aware of? How do you keep track of current and future bugs? There might be a number of bugs that come to your attention in various ways, but if you don’t have the full picture, you might be fixing inconsequential bugs instead of the real road blocks.
By being a developer for the Windows Phone platform you do get some help out of the box. You can use the Microsoft Crash Reports that are part of the Developer portal, which does give some indication of errors, but the information is only available for unhandled app process exceptions thrown.
Crash report from Windows Phone Developer Portal
You can get the stack traces from those crashes, but I have had apps crash that produced no reports and I only knew because users were telling me. You have no context, and relying on users to tell you what happened when the app crashed is like finding bitcoins at the end of the rainbow. You could also catch exceptions and events and store them manually in your own proprietary logging system, which a number of high profile apps do. But that is effort building a non-core part of your project and will waste time. Time you need to build features that will sell your app and give you that return on investment you want.
Bugsense Setup
What you need to use is an already existing logging framework. Introducing Bugsense. There are several plans with Bugsense, even a free one which is a great way to get started. Go and sign up for a free account now. Go. Do it. Done? Okay, excellent. Let us get started with the fun part then. Put your code hat on and away we go.
First create a new Windows Phone project, or choose an existing Windows Phone project you want to implement Bugsense into.
New WP8 Project
Next step is to install Bugsense which is done via a simple NuGet package update. Use either the Package Manager Console
Package Manager Console
Or the Package Manager Dialog in Visual Studio.
Package Manager Dialog
Next we need to add one line to the installation. Yes, one line. That is all. Open up your App.xaml.cs and in the App constructor insert the following
Insert Bugsense API key
Now you are ready to start logging. Bugsense lets you log both exceptions as well as manual events for areas you want to monitor and log. You can also now remove the default unhandled exception handler, as Bugsense will take care of business for you.
Remove Unhandled Exception Handler
That is it. You are now capturing exceptions with Bugsense. I could imagine you are after a bit more flexibility and functionality though.
Part 2 of this series on Bugsense will look at manual events and how you log custom information.