Conversation
...ples/sentry-samples-android/src/main/java/io/sentry/samples/android/ThirdActivityFragment.kt
Outdated
Show resolved
Hide resolved
...ples/sentry-samples-android/src/main/java/io/sentry/samples/android/ThirdActivityFragment.kt
Outdated
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Outdated
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## main #1528 +/- ##
=========================================
Coverage 76.03% 76.03%
Complexity 1955 1955
=========================================
Files 192 192
Lines 6765 6765
Branches 675 675
=========================================
Hits 5144 5144
Misses 1294 1294
Partials 327 327
Continue to review full report at Codecov.
|
sentry-samples/sentry-samples-android/src/main/AndroidManifest.xml
Outdated
Show resolved
Hide resolved
sentry-android-core/src/main/java/io/sentry/android/core/ActivityLifecycleIntegration.java
Outdated
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
| enableAutoFragmentLifecycleTracing = enableAutoFragmentLifecycleTracing | ||
| ) | ||
|
|
||
| private val isPerformanceEnabled = hub.options.isTracingEnabled && enableAutoFragmentLifecycleTracing |
There was a problem hiding this comment.
If we use the accessor like I suggested above, it would affect this too given the new hub could have perf enabled but the first not. So technically we'd need to evaluate this on each call hubAcessor().options....
Unless we get a new instance of this class for each Hub (each Sentry.init) in which case it would be fine we bind to the on Hub and disable when the hub closes.
There was a problem hiding this comment.
Good catch @bruno-garcia. I think this would to the trick
| private val isPerformanceEnabled = hub.options.isTracingEnabled && enableAutoFragmentLifecycleTracing | |
| private val isPerformanceEnabled get() = hub.options.isTracingEnabled && enableAutoFragmentLifecycleTracing |
There was a problem hiding this comment.
its a new instance per activity, as the callback is bound to the fragment manager, and each activity has its own fragmentmanager, I guess its the same as #1528 (comment)
so in the case that a new activity is setup and isTracingEnabled is disabled, nothing is gonna happen.
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
philipphofmann
left a comment
There was a problem hiding this comment.
On Cocoa, we only track spans until onResume is called because otherwise, the duration of a transaction would vary vastly. We could also create spans for onCreate, onStart and onResume. Then you get more insight into how long each of the lifecycle methods took.
sentry-android-core/src/test/java/io/sentry/android/core/ActivityLifecycleIntegrationTest.kt
Show resolved
Hide resolved
...ry-android-fragment/src/main/java/io/sentry/android/fragment/FragmentLifecycleIntegration.kt
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
| enableAutoFragmentLifecycleTracing = enableAutoFragmentLifecycleTracing | ||
| ) | ||
|
|
||
| private val isPerformanceEnabled = hub.options.isTracingEnabled && enableAutoFragmentLifecycleTracing |
There was a problem hiding this comment.
Good catch @bruno-garcia. I think this would to the trick
| private val isPerformanceEnabled = hub.options.isTracingEnabled && enableAutoFragmentLifecycleTracing | |
| private val isPerformanceEnabled get() = hub.options.isTracingEnabled && enableAutoFragmentLifecycleTracing |
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| private fun stopTracing(fragment: Fragment) { | ||
| if (!isPerformanceEnabled || !isRunningSpan(fragment)) { |
There was a problem hiding this comment.
h: If isPerformanceEnabled is evaluated on each call it could be that it is disabled here and never finish the span. If isPerformanceEnabled is set to false and we have a running span we could just discard the span.
There was a problem hiding this comment.
you cannot mutate the isPerformanceEnabled after the SDK is inited, so I don't see the point of taking care of this corner case, the same happens on ActivityLifecycleIntegration
There was a problem hiding this comment.
Couldn't you do some crazy stuff like this?
public class MyApplication extends Application {
private SentryOptions myOptions;
@Override
public void onCreate() {
super.onCreate();
SentryAndroid.init(
this,
options -> {
myOptions = options;
});
// some time passes
myOptions.setTracesSampleRate(null);
}
}There was a problem hiding this comment.
you could, yes, this would be misusing the API hence not really a case that we should take care, if we take this option in consideration, there are N cases that would break the whole SDK, or using reflection and setting non null fields to null etc
There was a problem hiding this comment.
also init should be called only once, its part of the spec.
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Outdated
Show resolved
Hide resolved
...ndroid-fragment/src/main/java/io/sentry/android/fragment/SentryFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
the idea is that first, we measure the impact of adding spans for every single lifecycle method and later expand upon feedback, fragment has like 12 lifecycle methods, it's too noisy |
Didn't know that. We currently don't have much "noise" on Android, so adding some makes sense to me as performance is about getting more insight. But I'm fine with the let's see how it goes approach. |
we've discussed this for Activity instrumentation, I'm just taking the same approach. |
📜 Description
Feat: Perf. for fragments
💡 Motivation and Context
Able to start spans out of fragments
💚 How did you test it?
📝 Checklist
🔮 Next steps