Ad hoc screen traces rather than Fragment only

[shamilovtim]

What feature would you like to see?

I understand that Firebase is implementing a method to automatically sample screentraces per-screen like Fragment on Android or ViewController on iOS. However, this isn't good enough for cross platform frameworks like React Native which runs in one fragment of one activity. Screens in React Native are sometimes a bunch of components nested in an RCTView (or its equivalent Android abstraction). Thus in React Native it's actually preferential to be able to start and stop a screentrace on demand, because the native code does not know when a React Native screen has mounted. Could the ScreenTrace API be provided on an ad hoc basis with start/stop methods? Could the Fragment based workflow be shut off so we can instrument our own ScreenTrace?

How would you use it?

1. React Native App starts
2. developer calls ScreenTrace.start('StartScreen')
3. the user navigates to the next React Native screen
4. developer calls ScreenTrace.stop('StartScreen') and ScreenTrace.start('MySecondScreen')

Like in previous versions, a screentrace is always running but now the developer has fine tuned control over when to start and stop the screen trace and what name to give it.

Big thanks to @mikehardy for helping me triage this issue in RN

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[mikehardy]

I am not sure how exactly Flutter handles it's mapping from cross-platform-level views / screens to native android Activities / Fragments, but this may be useful for them as well. It is definitely useful for react-native at least

[shamilovtim]

I think API is performance @argzdev

[kim-f]

Hi Timothy,

Thank you for reaching out to the Firebase Performance team, and for suggesting a way to improve the usefulness of our product! I've filed a detailed feature request in our internal tracking for discussion and potential prioritization. I appreciate the level of detail you've included within this and your similar request for our iOS SDK–the context you've provided will be very helpful to us as we consider what we should focus on building next.

Thanks again,
Kim