Open kahest opened 1 year ago
Context: We sometimes initialize a view controller that is later presented when the user does an action (taps on something). This could mean that the child view controller does eventually have viewWillAppear
invoked within the timeout (I've seen it after 20 seconds or so), so it's more complicated than just ignoring it if it hits the timeout.
Thanks for the context, @eric 👏 .
Update: We are currently discussing ways to support this, one of the solutions is to add a special case for ViewControllers spans where they are not waited for. If a root transaction contains a nested view controller span from a view controller that is not attached to the view hierarch, it captures every life cycle that happens while the first one is in progress, but don't need to wait for the second one to appear. If possible, we should add the remaining life cycle events to a UI interaction transaction that triggers them.
This edge case seems like another ducktape fix for our performance implementation. We currently take a step back and reevaluate our approach to performance monitoring on mobile. It could be that we don't need to fix this edge case depending on how the discussions go.
Problem Statement
If a UIKit VC is initialized, a span is created to capture the lifecycle of the VC. For subsequent passes through UI lifecycle events (
viewDidLoad
,viewWillAppear
, etc.), sub-spans are created.In cases where the view never becomes visible (i.e.
viewWillAppear
is never invoked), the main span of the VC runs until the end of the set timeout. This creates non-helpful spans.Solution Brainstorm
One of the following:
viewWillAppear
Are you willing to submit a PR?
No response