Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
An important thing to know when developing an app is where to look when things go wrong. We'll discuss the output logs that we can be used to determine what went wrong. And we'll learn where to catching unhandled exceptions for each platform.
Further Reading:
Troubleshooting Android
Troubleshooting iOS
Cross-platform Troubleshooting
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Mobile development and
0:00
Xamarin are both evolving, which means
not everything will always run smoothly.
0:01
So it's a good idea to know where
to look when things go wrong.
0:07
There are a few new output logs
that you should be aware of.
0:12
The Xamarin output log will
tell you how your connection
0:16
with your Mac Agent is working.
0:20
It'll start connecting as soon
as you load an iOS project.
0:22
So this is where you go to see
what may have gone wrong, usually,
0:28
network-related issues.
0:32
Xamarin diagnostic output dialog shows the
status of the ADB server, which is part of
0:35
Android SDK, which manages installing and
running Android devices and emulators.
0:40
I'm not sure why it didn't call these
outputs, Xamarin iOS and Xamarin Android.
0:47
The build output always has
a lot of good information.
0:52
And especially with Xamarin because it's
running so many customized build steps.
0:56
In the Tools, Option menu,
Under Projects and
1:01
Solutions, select Build and Run,
and change the MSBuild output
1:08
verbocity to something higher
than usually is by default.
1:13
This will take the build
extra time to run, so
1:19
turn it back down when you don't need it.
1:22
If you're dealing with runtime issues, the
Debug output is your first place to look.
1:34
If you're having trouble with
a physical device, the Device Log works
1:41
with Android or iOS devices that
are connected to your computer.
1:46
A more powerful tool for Android
diagnostics is the Android Device Monitor
1:51
which is an external app
that comes with Android SDK.
1:56
You can find it in the Tools,
Android menu.
1:59
The device monitor will let
you inspect memory usage,
2:03
network status,
file system, and much more.
2:07
You can see here the Android Device
Monitor is monitoring the current
2:11
emulator.
2:16
When diagnosing an iOS runtime issue,
you can use the Device Log.
2:21
But Xcode has more
powerful diagnostic tools.
2:30
There's a developer tool called
Instruments within Xcode which can
2:34
monitor memory usage,
file activity, and much more.
2:38
This is only a few of the tools that
you can use to debug Xamarin in
2:45
a Visual Studio environment.
2:49
There are some good resources
in the Xamarin documentation
2:52
around troubleshooting errors with builds.
2:55
Check the teachers notes for
links to the documentation.
2:58
Since we've gone over some build and
3:03
runtime troubleshooting,
we can talk about handling exceptions.
3:04
Neither Android or iOS will deal
with unhandled exceptions well.
3:09
If our app has an unhandled exception,
your app will simply crash.
3:13
We've all seen this happen with our
favorite app, but it's annoying and
3:17
can leave your app in a bad state.
3:22
Xamarin has normalized both Android and
iOS exception handling and
3:24
has included an event to
handle unhandled exceptions.
3:28
You can register a method to the
AppDomain.CurrentDomain.UnhandledException
3:32
event, and trap an unhandled exception.
3:38
So any app you develop should
at least handle this event.
3:41
In iOS, it should be registered
in the AppDelegate class
3:46
in overridden FinishedLaunching method.
3:49
Here in the FinishedLauching method,
3:53
we'll register a handler for
unhandled exceptions.
3:55
Using the System.AppDomain,
3:59
The CurrentDomain,
We can handle the UnhandledException.
4:08
We simply do a System.Console.WriteLine
which should show up in our debug logs.
4:33
So if we do something silly
like in the middle of our
4:53
application throw new Exception,
4:58
When we run the iOS version of the app, On
5:10
our simulator, And
we watch the debug output,
5:15
We can see our exception getting thrown.
5:30
And you can see our
unhandled exception message.
5:44
Let's remove that.
5:51
Now, look at the Android version.
5:54
For Android, we use the same class
to get to the unhandled exception.
5:56
And we'll write right out to
the console again, Using WriteLine.
6:32
And we use the correct stream formatter,
so that we can see who the sender is.
6:53
To make Android crash, let's throw
an exception in the calculate click event.
7:06
Then switch to the Android project
as our startup project, and debug.
7:16
Now, with the Android app, let's go
ahead and add a number, although we know
7:23
it's gonna crash when I hit the Calculate
button, and let's watch it.
7:28
An exception is thrown here, And
we continue when the app crashes.
7:35
We scroll through the debug log and here
is our unhandled exception message which
7:46
only shows up after
we've stopped debugging.
7:51
So again, let's remove the exception.
7:55
There are some exceptions that are thrown
that will not be caught by the unhandled
7:58
exception of it, like exceptions
not thrown on the main thread and
8:02
unhandled objective C exceptions.
8:08
The teacher's notes includes a link to
object C exceptions where this can happen.
8:12
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up