Debugging in Xamarin Forms is a different beast than other .NET projects especially in Visual Studio. I know that Xamarin Studio may offer a different debugging experience, but in enterprise, you aren’t using Xamarin Studio, you have Visual Studio. And even if I’m not in enterprise situations, Visual Studio is still the best IDE I have ever worked with, why would you give that up?
When you are debugging in Android, you are really debugging Mono and Java, something that the Visual Studio Debugger isn’t really qualified to handle. In iOS you are getting a remote debugging experience to a Mac. It results in incredibly cryptic and useless error messages that make no sense or give you no clue as to what is going on.
Take a look at a Xaml error I had and the error message I get when running the Xamarin Forms project in the VS Android Emulator
Debug in Windows Phone. Its so much easier.
That’s right. I know I am a minority on this, Xamarin Forms in Windows Phone. Who does that? Enterprise, that’s who. But there is such a benefit to it even if you aren’t going to deploy for it.
Here I have the exact same error as I did above with Android but here is the exception I get in my Windows Phone 8.1 SL project.
That error message actually told me what Xaml page was causing the issue and more specifically on the LoadXaml method meaning it was in the Xaml. Then on top of that the specific Xaml and why it was causing an error in the exception message.
It makes for much faster development. I develop my first Xamarin Forms project in Windows Phone always. Then I do Android and iOS next because I have already resolved any of the basic issues quickly with Windows Phone. All I need to focus on now are any platform specific bugs and platform UI tweaks, not tracking down mysterious cryptic or non existent error messages.
You need accurate, timely bug reports with a lot of useful information to debug some issues on mobile devices. You absolutely need a 3rd party bug tracking party.
Bug Tracking Tools
Going into how to implement bug tracking is not worth it here, there are many good tutorials on how to do it and it is normally as simple as add these 3 lines of code here and you are done. All of them include such things as storing bug reports locally and sending only once a good network connection is established and sending all environmental variables along with the device model and device condition such as battery level and connected networks.
But I am going to leave you with some considerations
- Have a central exception handling function where you can add extra parameters to the bug report if needed. I have noticed that Stack Traces can sometimes be very non-descriptive in the error reports.
- If you can recover from an error, do so, but still send an exception report. All you need to do for insights is Insights.Report(ex); and you can continue on with your code.
- Implement the send on startup crash reports. When an app crashes a report may be generated but it won’t be sent until the user starts the app again. However if it crashes on startup you will never get the errors. Hence make sure you implement their Send Crash Reports before startup code. This is normally just another 3 lines of code on top of the main ones.
- Know the difference between errors and metrics. For example if you record an error message every time the client fails to connect to a remote service because the remote service is down, this isn’t an error, its a metric. Record differently than an error but monitor them to see the issues your clients are still seeing.
- Ensure you setup filters to avoid recording sensitive information in an error report.