Close sentry instance when quitting the app

[vaind]

closes #543

Native integrations

• standalone native (windows)
• iOS
• Android

[vaind]

My original approach was to listen to SentryMonoBehaviour.OnApplicationQuit() - that's what's currently implemented in the current WIP version of this PR. However, I've now noticed there's also another implementation, using Application.Quitting, also used here:

sentry-unity/src/Sentry.Unity/Integrations/UnityApplicationLoggingIntegration.cs

Lines 93 to 106 in 68b7ec1

	private void OnQuitting()
	{
	_sentryOptions?.DiagnosticLogger?.LogInfo("OnQuitting was invoked. Unhooking log callback and pausing session.");
	// Note: iOS applications are usually suspended and do not quit. You should tick "Exit on Suspend" in Player settings for iOS builds to cause the game to quit and not suspend, otherwise you may not see this call.
	// If "Exit on Suspend" is not ticked then you will see calls to OnApplicationPause instead.
	// Note: On Windows Store Apps and Windows Phone 8.1 there is no application quit event. Consider using OnApplicationFocus event when focusStatus equals false.
	// Note: On WebGL it is not possible to implement OnApplicationQuit due to nature of the browser tabs closing.
	_application.LogMessageReceived -= OnLogMessageReceived;
	// 'OnQuitting' is invoked even when an uncaught exception happens in the ART. To make sure the .NET
	// SDK checks with the native layer on restart if the previous run crashed (through the CrashedLastRun callback)
	// we'll just pause sessions on shutdown. On restart they can be closed with the right timestamp and as 'exited'.
	_hub?.PauseSession();
	_hub?.FlushAsync(_sentryOptions?.ShutdownTimeout ?? TimeSpan.FromSeconds(1)).GetAwaiter().GetResult();
	}

Now I'm confused which one would be the best one to use - they seem to be duplicate implementations binding to the same event..

[bitsandfoxes]

The SentryMonoBehaviour was added to give us access to callbacks on the MonoBehaviour and things from inside Unity itself. It's an actual game object that receives the OnApplicationQuit inherently to destroy itself.

In your case, I'd go with the IApplication and use the OnQuitting there.

[bruno-garcia]

One questions but other than that. lgtm

[bruno-garcia]

The only risk I see is that an error/crash happens after the Unity's AppShutdown thing ran, and we'd be all shut down and not capture. For that reason, recently we've changed the .NET SDK to have the Dispose handle returned by the Init call behave like a Flush only since that's what the semantics where in the code snippets (block to capture and flush). So the SDK would continue to capture even after that block.
That said, .NET SDK's Close continues to completely close the SDK since it swaps to a NoOp hub instance (the old one would be GC'ed):

https://github.com/getsentry/sentry-dotnet/blob/2d6c847268c9422c0a02bffe87dd656736cf197c/src/Sentry/SentrySdk.cs#L123-L125