Sentry-dart: Set sdk name for Flutter desktop

[marandaneto]

Today we can't query Desktop adoption because the SDK name for Desktop is also sentry.dart.flutter.
Pure Dart is sentry.dart
Web is sentry.dart.browser

Should we consider breaking it down like:

Pure Web: sentry.dart.browser
Flutter Web: sentry.dart.flutter.browser
Flutter Desktop: sentry.dart.flutter.desktop or would that be too much?

cc @bruno-garcia

[bruno-garcia]

Usualy the sdk.name represents the installable unit. So if I go to pub.dev and installsentry-flutter, it's fair to expect all events to come from to be sentry.dart.flutter. It's true we changed it for web which deviates from this a bit already.

We could use another part of the protocol (a tag or context.runtime.platform for example` to indicate what type of build this is.

Unity will have the same challenge. Currently we'll send sentry.dotnet.unity for all events from Unity. That could come from Android, Xbox, Windows or whatever so aligning on this could be beneficial.

[marandaneto]

Sentry already creates tags automatically out of a few device context, maybe it's not even needed.

[bruno-garcia]

Makes sense. In this case I'd say we could close this.
We could also reconsider the decision of special-casing the sdk name for sentry_flutter when building for the Web. Since it's anyway the same package.

Device there though would still report as 'Android' for example, so not really help us know the 'Flutter app model'. Maybe a tag could be helpful nonetheless. flutter_build=web|ios|android|windows|etc

[marandaneto]

sounds good, well the flutter_build would be pretty much the same as os.name which is the OS family (Android, iOS, ...) so I'll close this.

[bruno-garcia]

@marandaneto Except on Web, that would report just as mobile and we wouldn't be able to tell if it's a native app or just Flutter on the browser. Unless we do os.name=ios and browser.name=null if that makes sense

[marandaneto]

that's a good point, https://github.com/getsentry/sentry-dart/pull/452/files is adding more info like runtime that we can rely on, but the main goal of this issue was breaking up the SDK names but as they are not different packages, it does not make sense, if we ever intend to get the adoption per OS or runtime type, we could use the tags that are automatically created already, or the info brought by #452