class ViewTreeWatcher
Defined at line 1254 of file fidling/gen/sdk/fidl/fuchsia.ui.observation.geometry/fuchsia.ui.observation.geometry/hlcpp/fuchsia/ui/observation/geometry/cpp/fidl.h
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.
Public Methods
void ~ViewTreeWatcher ()
void Watch (WatchCallback callback)
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.