Intro & Feedback Overview
Feedback Loops & App Center Analytics
Baselines & Noise
The course is part of these learning paths
The application lifecycle doesn’t finish with app deployment. Feedback is an important element of refining an application, whether that’s exception detection and diagnoses or improving the user experience. In this course, we will look at a suite of services that capture a vast array of feedback data, ranging from exceptions to client and server telemetry. This data can be turned into easily digestible information that can be used to trigger alerts and feedback into the development lifecycle as work items.
This course begins by describing what feedback is, and the types of feedback for improving application performance and usability. It then moves on to how we can integrate feedback into the software development lifecycle and what tools we can use to simplify that task. Finally, we will look at optimizing feedback mechanisms to get meaningful data from feedback noise.
For any feedback and questions relating to this course, please contact us at firstname.lastname@example.org.
- Designing application and user feedback loops
- Setting up crash and event notifications for App Center
- Setting up work item integration from App Center
- Making sense of App Center’s analytic and diagnostic information
- Adding Application Insights Telemetry to an application
- Setting up Application Insights alerts
- Work item integration from Application Insights
- Designing feedback dashboards
- Viewing Application Insights Telemetry data
- Discussing types of user feedback and how they can be captured
- Ways to baseline and filter feedback data
This course is intended for:
- People preparing for Microsoft’s AZ-400 exam
- App developers
- Project managers
To get the most from this course, you should have some experience with Microsoft Azure and application development, as well as knowledge of software project management concepts.
This all makes sense and is logical, but there is a lot going on here. To build and implement an error capturing framework yourself would be a significant undertaking, perhaps more involved than the application it’s supposed to monitor. As this scenario is common to all software projects its not surprising that there is a raft of products designed to help developers integrate exception capture and bug tracking with development workflow.
Products like Raygun will collect exception data from your application, help you prioritize and diagnose the issue, and then link to a development workflow system like Jira or Zendesk.
As it happens, Azure’s relatively new App Centre has just the features you need to capture and analyze exception data with very little effort.
Integrating basic error detection into your application is quick and simple. Start by installing the Microsoft AppCenter Crashes package into your project. Add the using statement to your source code. Before you can use AppCenter Crashes you must start the SDK with AppCenter start. You need to supply the app secret you obtained when registering your application with App Center, and the type of services you want to use. In this case, that parameter will be typeof crashes. We are going to record exceptions and crashes, that is an exception that causes the application to crash, as oppose to a caught exception.
Looking first at a typical try catch scenario, we can call the Crashes TrackError method of the SDK within the catch block. TrackError takes an exception as its parameter. The Crashes SDK also has callbacks that can be used for processing error reports from a previously crashed session or getting user feedback from the UI. The callbacks need to be set up before calling App Center start. Conversely you need to start the App Center SDK before calling any of its methods.
This ErrorInitialization function illustrates how you might put these features together on app startup. Firstly, we setup our callback saying we only want to process an error report if it isn’t a blue screen of death. Next, we start the App Center. Then we find out if the application crashed out the last time it ran. If it did, we get the crash report from the last session and display a message to the user. This last session functionality is very useful as it allows us to easily figure out if the last session went badly and let the user know, that we know all is not well and action will be taken to remedy the problem.
As a side note, Microsoft say, “By default, an unhandled exception in a WinForms application does not trigger a crash (the application does not exit) if the debugger is not attached.” One way around this situation is to call Application SetUnhandledExceptionMode to ThrowException. This will get Winform applications to correctly display crashes in App Center..
User privacy is another factor to keep in mind and the Crashes SDK does provide a call back feature, ShouldAwaitUserConfirmation, where you can ask the user to confirm whether or not they consent to sending error data. This simple example does not cater for the AlwaysSend option that is available with the NotifyUserConfirmation method. You also have the ability to attach files to your error report. This would be useful for sending detailed application state in data driven or highly configurable apps. At the moment the maximum size of attachments per error report is 7 megabytes.
In your project’s App Center go to diagnostics to see a dashboard of all issues. This is where you see the crashes and exceptions separated into groups. A group is all the instances of a particular crash or exceptions. I did find it interesting that the grouping is based on the location within the code as a whole rather than the location within a function as identified by it’s signature. The Main_FORM Tables_LB_Click crash is exactly the same exception, but the one that occurred most recently on line 153, was after I added the ErrorInitialization function above it. Clicking on a group will take through to a detail view.
Here we can see the stack trace plus the number of times the crash has occurred and the number of impacted users. What’s particularly useful for mobile developers is a breakdown of devices and OSes that the crash has occurred on. On the top right you can change the status of the crash group from open to closed or ignored. Clicking on the Reports tab will display all the instances of the crash.
Clicking on a report or instance will display additional information like country and language, and also how far into the session or after app startup did the crash occur under the heading Crashed after. The threads tab shows the stack trace data, while attachments will display any data files that have been uploaded with the error report. Events are analytic events that were recorded just prior to the crash – we’ll have a look at those later.
Ideally, we want to be notified A.S.A.P when our app has crashed. This can be easily set up by going into settings and selecting email notifications. Then under crashes select when you want to be emailed about a crash event. Your choices are immediately, daily or never. On the right is an example of crash group email. It has basic information with a link to the crash group.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.