>> Hi, my name is Matt Johnson Pint and I am from Sentry.
I wanted to tell you about
Sentry's new offering for.NETMaui We are
adding a new SDK to the Sentry family of SDKs.
That is specifically for Maui.
We're very excited about this.
Let me tell you a little bit about what Sentry does.
We're an error monitoring solution first, and foremost.
We also have performance monitoring in our portfolio.
I'm going to talk a little bit about that later.
But basically what Sentry is for is,
say you develop your brand new Maui app
and you deploy on all your platforms
and something doesn't quite work on it.
Well, you would really like to find
out about it before your users do,
before somebody calls and complains.
It would be great if you had
a very easy way to bring all that forward into your application.
Keep in mind you're writing a mobile app,
what it its offline,
how do you even find out about those things?
Well, Sentry can handle that by
simply storing everything and caching it locally,
and then sending it into your Sentry dashboard
when the devices come back online.
Let me show you a little bit about how to get started with Maui.
If you have your Maui application,
you do create Maui app
is what something you are probably already used to.
All you really have to do is say use
Sentry and give it any of the options that Rck offers,
but the only ones required is what we call
the DSN or the data source name.
When you sign up for a Sentry account,
you'll be given this string, it's not a secret,
but it's how we know how to give the data coming out of
your application into your specific dashboard.
What do you get for that?
Well, here's an example application crash.
This happened in a test app that I was doing,
and you can see that not
only did we get all the details about the application,
including what version it was on?
What version of.NET was running?
What operating system was running on?
We also have when did the crash happened?
What was the stack trace from that crash?
For Maui, we've got this thing down here called breadcrumbs,
which I'll zoom in on over here on the right,
where you can see a whole list
of what happened leading up to that crash.
For example, what I'm showing here is that we started our app,
the page was appearing,
the Maui life-cycles of window created, activated,
they are happening and then the user clicked a button,
and that's when we got our crash.
The corresponding stack trace for that one
looks a little like this and you can see
that we also have it happened in the on button click at that.
All this stuff will come through on the dashboard,
and we correlate them and
group them and do everything that you need to
do in order to distinguish one type of failure from another.
Now, we give you
all kinds of information about the device that was running on,
which is really important when you're working
on a multi-platform product like Maui.
There's way more here than you could possibly even
see unless you want to zoom in on this screen.
But I wanted to throw it all up on here
just to give you a sense of all the things we capture,
we've got the amount of memory on the device,
how much was free in terms of storage
if the screen was a certain size or orientation,
will tell you if the person had routed
their device or if they were running it in
a simulator or on a real device,
will give me their time zone and their culture
and all other information that you
might need that's relevant to
debugging that error in your application.
For our Maui offering,
we also offer native mobile crashes for Android,
and we'll soon have native [inaudible] crashes for iOS.
What this means is we've taken
Sentry's very good SDKs that
already exist for Android and for iOS,
and we've embedded them into the Maui SDK,
so that you get all the benefit of
a native error monitoring
environment even from your managed world.
Here's an example,
I specifically through a bad instruction crash
from some native code running within my Maui application,
and I got all the information.
This was on a Mac all the way up from UIKit
into mono and up into Xamarin,
and then I'm showing finally
into the application that I was testing.
This will really help if you're trying to debug something that
maybe isn't happening in
your own code or is caused by something going on under the hood.
Let's do a little demo.
Here's a Maui application,
it's actually just the file new Maui project starter template,
and the only thing I've done is I
added the Sentry Maui new Get-Package,
and I've done UseSentry right here.
Let's run this,
and you'll notice that when this runs on my little Android device.
This is running on my Android device,
and I've got the Getting Started with Maui.
Let's click this button and I'm sure
you guys have done this a bazillion times.
I've got something special in this code.
What happened when I clicked it the third time?
The application crashed.
Now if this is a real application,
the user might be like what's
going on and they might try to run it again.
They run it again and they click the button and it's crashing,
so they might then call
you and give you some information out of the app info here,
and that's really all you get.
But thankfully we have this app connected to Sentry,
so if I go to my Sentry dashboard and I wait just a second here.
There is the error that we just created.
You can see it came in twice because
I had it happen twice. What happened here?
I've got to divide by zero,
and it's happening on my Android device,
and I can see in my stack trace
here that it happened in my on counter clicked event.
It happened when the button
was released and then it's measured was invalidated,
which is all happening underneath the hood.
Let's take a deeper look at these breadcrumbs by the way.
I've got all the way up from the app handlers that Maui has,
the navigation of the user,
the UI handlers, every little bit of thing that's happening.
I've got a timeline so that I can
tell how much time is passing between these things.
Maybe your app isn't crashing,
but it's hanging in certain parts.
Again, here's all my memory info, thread pool info,
that's really cool, device information, etc.
Let's go back to our code and find that bug,
so it happened when I click the button.
I put this code in here.
It's truly doing a divide by zero.
Don't actually do that in your own code,
but that was indeed causing a divide by zero exception,
so we can find the source of that.
Let's do something a little more interesting now.
I've put in a few other things in this application that will make
it easy to try some of our native crash handling.
Let's do this.
I've got some Android-specific code here that's going to call into
a Kotlin library that I've embedded into the platform's folder.
Up here in my Kotlin folder,
I've got this little bit of Kotlin code called buggy,
and it's going to throw an exception in Kotlin,
which is running on the JVM,
which is underneath the hood in
my Android language in my Android platform.
Let's call this and see how that comes through.
Because remember this time we're not calling.NET code.
The.NET code is invoking Java code
on the device and it's going to crash there.
Again, we're going to click three times. It's going to crash.
>> That will come through. I'll show you in a
second why we're waiting,
because it does take a few seconds sometimes.
I also want to show you that we can do the same thing
with native code all the way down to the C++ or the C layer.
Here's a C crash that is going
to basically try to increment a pointer to zero.
This is not going to be good.
We're going to go out here, and instead
of this little bit of code,
we'll run another one.
This time instead of my Kotlin,
we're going to crash in C. I'm going to do,
is I'm going to P invoke into
that C library that I've also embedded into our application.
Let's give it one of those two.
Sure enough this will crash.
But these are the types of things just for
demonstration that could happen in your app in the real-world,
especially when you think about
all the different types of devices and
platforms that your application is going to run on.
We'll click three times and boom, it's crash.
Just for good measure, we'll run it again.
Now on a native crash,
if the application crashes and
it's literally like a native layer crash
and it shut down instantly.
What we'll do is we'll write that crash off to
disk and then we'll send it to Sentry the
next time the application starts.
That's part of the caching process or Sentry.
Let's go back to our Issues
and we can see some of these have come through.
Here's that Kotlin one.
It came through as a Java.Lang.Exception,
there's our OnCounterClicked, Buggy.Throw.
We came through into the Java layer,
we called into that method through
JNI and got our exception in Kotlin.
Again, we solve all of our breadcrumbs.
We still got our device information,
lots and lots of stuff.
That's C layer severe too.
Actually it looks like I didn't even wire it up correctly,
so the layer we got was a DIINotFound.
But even a true C Exception would end up coming
through into the application and we would end up seeing it here.
That's something that's important to know and we'll have
that capability on as many MAUI platforms as we can support.
Right now it's on Android,
we're adding it for iOS.
But it really distinguishes
something that Sentry can do that others can't.
Let's say we didn't want to just let these things go unhandled.
One thing we can do is we can use the Sentry SDK.
Let's put a try-catch around here.
We could do something like SentrySdk.CaptureException.
You can see here in Visual Studio we have a lot of other options,
but the easiest thing to do is capture it.
That'll swallow that exception.
It's not going to error to our user,
but we can still get it to Sentry like that.
That'll come through the same way as everything else.
There's a whole bunch of other stuff that the Sentry SDK provides
for.NET that is available too in MAUI. That's it for the demo.
I want to talk to you a little bit
about where we're at and where we're going.
We've currently released two premiums,
we're at Preview 2 right now.
We have streamlined our MAUI integration,
so it's a simple use Sentry.
In your MAIU AppBuilder.
We've given you devise contexts,
information and breadcrumbs specific for MAUI.
We support manage exceptions on all platforms that's iOS, Android,
Mac Catalysts, and Windows,
and we have Native Crash support for Android.
What's coming next in our Preview 3 is right around the corner,
we'll have native crashes for iOS supported,
and we'll also be doing native symbol uploads.
What this means is as you're building your application,
we can take your symbols
and send them up to Sentry on the backend,
so that when your app crashes,
instead of just seeing address offsets like you saw in this demo,
you'll actually see stack traces with
class names and other information coming out of your symbols.
We'll be adding a release health feature,
which is something we have in some or other platforms.
This is a good way to know,
not just when things are crashing,
but which releases are healthy.
If you tell us that your application is Version
2.5 and we see that Version 2.5 is getting good health signals,
and then we start seeing some crash that are
only happening in Version 2.6,
we can distinguish them at the backend and tell you,
there's something that you
probably introduced in your new version.
That is supported many Sentry SDKs right
now and we'll have it in Sentry MAUI for Preview 3.
Shortly after that will be going to GA,
which is really just going to be adding a whole lot of tests,
making sure it's solid,
fixing it up and really making sure
it's perfect for you to put into
your application and then
gets everything right that we are currently offering.
Down the road, shortly after that hopefully we'll
be doing automatic performance instrumentation for MAUI.
Right now you can use
Sentry's performance features in your MAUI apps if you want to,
but you'll be wiring up
the actual things you're tracking performance on yourself.
If you have part of your application
that's doing some background work,
you might want to start and stop a transaction around there.
You've taken to manually with the Sentry SDK.
But we want to do that for you using all of
the events that MAUI gives us as much as possible anyway.
Right out of the box you'll get Perf data for MAUI.
We also want to give you mobile vitals.
We can tell you how long did it take for your app to
start from when the user click the button to the first screen.
We want to give you
any information about when your application isn't responding,
and some of our SDKs,
we can actually give you screenshots of what
was the user was seeing when an exception was happening.
We certainly will be able to give you that for native crashes,
but we're going to see if we can do it
for managed crashes as well.
Here's a little sneak preview.
This is how we do performance monitoring
for Mobile Vitals in our Android SDK.
This will come through on
the Sentry dashboard showing you your cold start times.
If there were any discrepancies between versions,
you'd be able to see very
easily how long it took for your applications to run.
The nice thing about this tool is it will tell you
whether the start times are
different on different device families.
Maybe your application runs really fast on
iOS and it works really great on Android 12,
but it doesn't work really great on Android 10.
We would be able to tell you that information here.
That's all I have for today.
Thanks for joining.
If you want to learn more,
you can go to a Sentry for dotnet-maui.
I believe there'll be a link you can click on right here.
Feel free to reach out to us @getsentry on Twitter
or just find us on GitHub or our discard channel. Thanks a lot.