Manoel Aranda Neto
Manoel Aranda Neto
Yeah the approach taken on sentry-java worked well, now it's a matter of doing it on Dart/Flutter, not planning on this Quarter tho.
I've created an empty project using the `react-native-tvos/react-native-tvos` template and added Sentry to it. Called `Sentry.captureMessage('test');`, `Sentry.captureException(e);` and `Sentry.nativeCrash();`, all of them worked.  ![Screenshot...
Similar to https://github.com/getsentry/sentry-java/issues/2004 and https://github.com/getsentry/sentry-cocoa/issues/1768
The way how the SDK works now would make it either very difficult or not possible. Ideally, we'd store the transaction instances in a sort of `Map`, so every time...
Right now users could disable the auto instrumentation for those specific cases and use the custom instrumentation https://docs.sentry.io/platforms/react-native/performance/instrumentation/custom-instrumentation/
https://github.com/ueman/sentry-dart-tools/tree/main/sentry_plus/lib/src/http
I believe the right solution here would be to align the way how we capture events, which is what iOS does, on RN, we call the native bridge to get...
also for Android, so I made it more generic, thanks.
I believe some pieces could be unit tested but indeed, integration/e2e would play a bigger role.
Let's configure SwiftLint to fail if there are warnings. Let's silence these warnings that we don't consider to be an issue.