Currently these APIs are extension functions on Window because frame metrics are per window.

Need to experiment with multi window (activity + dialog) to see if the metrics actually differ. All windows are rendered in one go. A possible difference might be if each traversal is measured separately? tbd.

If there's no difference, then we maybe could come up with a way to grab any or "the best" window and just run with that, removing the need for a window, which is nice when you're in the middle of your navigation code.

Currently an interaction result includes the start and end event.

We should consider simply associating a list of events instead. We'll end up with a single event when start & finish are called on the same event, 2 events for normal delayed interactions, 2 events for normal canceled interactions (but 1 for timed out interactions). We could support more than 3 by having a way to pull a running interaction & associate it to the current event, whether that interaction is running or finishing.

There's separately a question of whether even having an interaction type at all is useful. Since the rules are event based and the events carry all the context needed, an interaction could be defined as a list of events with maybe a name.

To do this we'd likely also need to provide access to all past events associated with a given running interactions, so that you could look them up and find the ones with start ids related to the id of the current event.

One consistent feedback is that cancelRunningInteractions() sounds like it would cancel all interactions when in fact it's all interactions local to the rule. Some have expressed the need to actually do that though, i.e. cancel for a bunch of rules, which might be done by handling all sub rules in a single rule.

This backward-compatibility workaround is now available via androix MessageCompat.setAsynchronous (source)

fixes https://github.com/square/papa/issues/32

https://github.com/square/papa/blob/main/papa/src/main/java/papa/internal/Handlers.kt

See this: https://www.zacsweers.dev/rxandroids-new-async-api/#api-16-21-

Currently there's an interaction object that can be updated, that works but not convenient as it has to be created early, so the end metadata is typically a lateinit var, which you might forget. We want to make sure we don't forget to provide the data as we call finish.

While browsing some code noticed that

In class CurrentFrameMetricsListener -- line 47, 48 is double counting UNKNOWN_DELAY_DURATION twice?

  val drawEndNanos =
      frameMetrics.getMetric(INTENDED_VSYNC_TIMESTAMP) +
        frameMetrics.getMetric(FrameMetrics.UNKNOWN_DELAY_DURATION) +
        frameMetrics.getMetric(FrameMetrics.UNKNOWN_DELAY_DURATION) +

Need to create an event recording system that we can hook into to set listeners (otherwise they're lost) and then each app launch sets a listener and provides the list of events once done. The EventRecorder need to be thread safe. We also likely need 2 recorders or a way to duplicate because process start is one and cold app launch is another. Also need to be able to insert events at a specific time. Need to be able to add custom events.

Once we have that we can migrate a lot of the custom measurements to these events.

Redesigning the API and implementation for tracking interaction latency, with a primary goal of decoupling the code where we send signals (events) from the place where we tie those events together an interaction.

Example usage code

interface PosInteractionEvent
interface PosInteraction

object OpenCheckoutApplet : PosInteraction

class Navigation(val destination: Any) : PosInteractionEvent

class CheckoutApplet : PosInteraction

object TapItem : PosInteractionEvent {
  val itemId = ""
}

object ItemVisibleInCart : PosInteractionEvent {
  val itemId = ""
}

class AddItemToCart(val itemId: String) : PosInteraction

object KeypadVisible : PosInteractionEvent
object UserPressedBack : PosInteractionEvent

fun setup() {

  val client = InteractionRuleClient<PosInteractionEvent, PosInteraction>()

  client.sendEvent(KeypadVisible)
  client.sendEvent(Navigation(Any()))

  val configuredRule = client.addInteractionRule<OpenCheckoutApplet> {
    onEvent<Navigation> { navigation ->
      if (navigation.destination is CheckoutApplet) {
        cancelRunningInteractions()
        startInteraction(OpenCheckoutApplet, onCancel = {
          Log.d("event canceled", it.cancelReason)
        })
      }
    }
    onEvent<UserPressedBack> {
      runningInteractions().singleOrNull()?.cancel("user pressed back")
    }
    onEvent<KeypadVisible> {
      runningInteractions().singleOrNull()?.finishOnFrameRendered { result ->
        logToAnalytics(result)
      }
    }
  }

  client.addInteractionRule<AddItemToCart> {
    onEvent<TapItem> { tapItem ->
      startInteraction(AddItemToCart(tapItem.itemId))
    }
    onEvent<ItemVisibleInCart> { itemVisibleInCart ->
      val addItemToCart = runningInteractions().firstOrNull {
        it.interaction.itemId == itemVisibleInCart.itemId
      }
      addItemToCart?.let { interaction ->
        interaction.finishOnFrameRendered { result ->
          logToAnalytics(result)
        }
      }
    }
  }

  // when we don't need this rule anymore
  configuredRule.remove()
}

Current impl:

internal fun onCurrentFrameRendered(callback: (Long) -> Unit) {
  mainHandler.postAtFrontOfQueueAsync {
    val frameRenderedUptimeMillis = SystemClock.uptimeMillis()
    callback(frameRenderedUptimeMillis)
  }
}

This should be stateful and aware of any pending calls so that we only register a single call and a single uptime and dispatch to all callbacks

We weren't using orchestrator internally so had to run all the tests from a single method. That shouldn't be needed in the OSS version anymore.

Fixes #11

Currently FrozenFrameOnTouchDetector listens to ACTION_DOWN events and schedules a frame callback from there, combined with a post at front of queue, and logs a "frozen frame" if the time from down being issued to the end time is greater than 700. This seems wrong as we're scheduling for another frame instead of relying on "end of current frame" as frame end. We probably don't want to rely on frame metrics here, we just want to know how long things were blocked for. A post at front (not async) from event handling should be enough.

So like the events in TrackedInteraction isn’t super straightforward - events isn’t a good name for that I think sentEvents would make more sense. I had to explain this which is why I’m saying this.

Currently, a launch is considered in-progress until there are 500+ ms between an executed runnable posted from a lifecycle callback and the next lifecycle callback (or we receive our first frame). It seems this timeout-based approach for what is considered a launch still-in-progress is used to support the case of trampoline activities. Outside of the context of trampoline activities, this timeout doesn't really come into play. That's because if you post a runnable during an activity lifecycle event, it will not get executed until after onResume. In the context of trampolining activities, I think a good way to distill this down to what this actually accomplishes is to consider the path to the first frame after onResume as unbroken as long as the distance between the last lifecycle callback of one activity to the first lifecycle callback of the next is less than 500ms. However, I don't believe we need a timeout-based approach like this to support trampoline activities.

I believe that a more deterministic approach is to allow a launch measurement to continue indefinitely (until the first frame is rendered following onResume), unless the app ever goes from 1+ started activities to 0 started activities. In my testing, under all trampoline configurations, I am unable to get a transition from 1+ started activities to 0 started activities through the trampoline. Through the trampoline, we only ever go from 0 to 1+ started activities, and always remain at 1+ started activities.

Figure out some APIs built on top of our interaction tracking to easily integrate with navigation systems.

The litmus test will be that it needs to work with our internal nav system as well as Jetpack's nav.

We also need to figure out inputs to nav and might need to tweak the APIs:

• Most navs are usually triggers by input
• Some navs are triggers by async work (e.g. after a loading network call)
• The first nav is usualled triggers by app launch => this means we can pull up the launch start time. And the end time should be identical. But that'd also mean 2 events (launch + nav), is that right?
• One simplification we've done internally is that the previous nav is always the previous nav, and that's handled in a centralized way. This might not work if you have several parallel activity tasks and you're switching behind them. Though it might still be interesting to represent it that way.

• Should support init via ContentProvider, direct call, or jetpack startup
• On init, there's a bunch of work which we want to make it possible to skip / disable as a configuration option. One approach is using XML bool resources. Another approach is to have a "Configurator" class that's defined as an XML string resource and is loaded dynamically. Another option is to make configuration something possible only with manual install, where one passes the config in.