Enum ViewTreeWatcherRequest

pub enum ViewTreeWatcherRequest {
    Watch {
        responder: ViewTreeWatcherWatchResponder,
    },
}

A method of obtaining view tree snapshots for a particular view, the “context view”, and its child views, if any. The returned data is a sequence of snapshots during the period of observation, which starts at the client’s prior Watch() call’s [epoch_end] (or zx.Time 0), and ending at the current [epoch_end]. The timebase is ZX_CLOCK_MONOTONIC.

Clients typically obtain a ViewTreeWatcher capability from within a test, and it is not generally possible to obtain outside of a test environment. For more information see fuchsia.ui.observation.test.Registry and fuchsia.ui.test.scene.Controller.

Usage note. With this protocol, a client can watch for changes to the view tree over which it has authority. For example, if a client owns view A, then A serves as the context view for A’s subtree (i.e., a “root view”), where A is a parent of view B, and B is a parent of view C. The client can then observe key lifecycle events in all of A, B, and C, such as newly connected views, changes to view position and size, etc. In doing so, a client can gate its actions on changes to the view tree, in a reliable and ergonomic manner. For example, a client can wait for a descendant view C to become connected before requesting a focus transfer to C.

Configuration: The context view is determined outside of this protocol.

Frequency: A client can receive one or more snapshots per frame. Clients should not “count snapshots”, as the per-frame snapshot count can be non-deterministic. Instead, clients should look for specific conditions on the snapshot state.

Issuance: If the context view is disconnected from a display, no frames are issued on behalf of the context view, and a Watch() call will sit quietly.

Lifecycle: The server endpoint is closed when the context view dies.

Variants

Watch

A method of obtaining view tree snapshots for a particular view.

This call is formulated as a “hanging get” pattern: the client asks for a set of recent snapshots, and receives them via the callback. This pull-based approach ensures that clients consume events at their own pace; events don’t clog up the channel in an unbounded manner.

Error Handling. If Error is unset, the client may assume that the the response contains updates with complete information over its epoch.

Flow control. The caller is allowed at most one in-flight |Watch| call at a time; it is a logical error to have concurrent calls to |Watch|. Non-compliance results in channel closure.

Client pacing. The server will dispatch snapshots to the caller on a lossless, best-effort basis, but the caller must allocate enough time to keep up with new snapshots.

Fields

responder: ViewTreeWatcherWatchResponder

Implementations

impl ViewTreeWatcherRequest

pub fn into_watch(self) -> Option<ViewTreeWatcherWatchResponder>

pub fn method_name(&self) -> &'static str

Name of the method defined in FIDL

Trait Implementations

impl Debug for ViewTreeWatcherRequest

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.