Mobile development and

Xamarin are both evolving, which means not everything will always run smoothly.

So it's a good idea to know where to look when things go wrong.

There are a few new output logs that you should be aware of.

The Xamarin output log will tell you how your connection

with your Mac Agent is working.

It'll start connecting as soon as you load an iOS project.

So this is where you go to see what may have gone wrong, usually,

network-related issues.

Xamarin diagnostic output dialog shows the status of the ADB server, which is part of

Android SDK, which manages installing and running Android devices and emulators.

I'm not sure why it didn't call these outputs, Xamarin iOS and Xamarin Android.

The build output always has a lot of good information.

And especially with Xamarin because it's running so many customized build steps.

In the Tools, Option menu, Under Projects and

Solutions, select Build and Run, and change the MSBuild output

verbocity to something higher than usually is by default.

This will take the build extra time to run, so

turn it back down when you don't need it.

If you're dealing with runtime issues, the Debug output is your first place to look.

If you're having trouble with a physical device, the Device Log works

with Android or iOS devices that are connected to your computer.

A more powerful tool for Android diagnostics is the Android Device Monitor

which is an external app that comes with Android SDK.

You can find it in the Tools, Android menu.

The device monitor will let you inspect memory usage,

network status, file system, and much more.

You can see here the Android Device Monitor is monitoring the current

emulator.

When diagnosing an iOS runtime issue, you can use the Device Log.

But Xcode has more powerful diagnostic tools.

There's a developer tool called Instruments within Xcode which can

monitor memory usage, file activity, and much more.

This is only a few of the tools that you can use to debug Xamarin in

a Visual Studio environment.

There are some good resources in the Xamarin documentation

around troubleshooting errors with builds.

Check the teachers notes for links to the documentation.

Since we've gone over some build and

runtime troubleshooting, we can talk about handling exceptions.

Neither Android or iOS will deal with unhandled exceptions well.

If our app has an unhandled exception, your app will simply crash.

We've all seen this happen with our favorite app, but it's annoying and

can leave your app in a bad state.

Xamarin has normalized both Android and iOS exception handling and

has included an event to handle unhandled exceptions.

You can register a method to the AppDomain.CurrentDomain.UnhandledException

event, and trap an unhandled exception.

So any app you develop should at least handle this event.

In iOS, it should be registered in the AppDelegate class

in overridden FinishedLaunching method.

Here in the FinishedLauching method,

we'll register a handler for unhandled exceptions.

Using the System.AppDomain,

The CurrentDomain, We can handle the UnhandledException.

We simply do a System.Console.WriteLine which should show up in our debug logs.

So if we do something silly like in the middle of our

application throw new Exception,

When we run the iOS version of the app, On

our simulator, And we watch the debug output,

We can see our exception getting thrown.

And you can see our unhandled exception message.

Let's remove that.

Now, look at the Android version.

For Android, we use the same class to get to the unhandled exception.

And we'll write right out to the console again, Using WriteLine.

And we use the correct stream formatter, so that we can see who the sender is.

To make Android crash, let's throw an exception in the calculate click event.

Then switch to the Android project as our startup project, and debug.

Now, with the Android app, let's go ahead and add a number, although we know

it's gonna crash when I hit the Calculate button, and let's watch it.

An exception is thrown here, And we continue when the app crashes.

We scroll through the debug log and here is our unhandled exception message which

only shows up after we've stopped debugging.

So again, let's remove the exception.

There are some exceptions that are thrown that will not be caught by the unhandled

exception of it, like exceptions not thrown on the main thread and

unhandled objective C exceptions.

The teacher's notes includes a link to object C exceptions where this can happen.