[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
The View interface provides a way for a stream, data provider, or another view,
to notify an object of additions and deletions to its data set.
Views are themselves Viewable by other Views, and can implement their own set of cached data internally.
The contract is that a View is wholly derived from the object (its parent) to which it is attached.
That is, it must be able to reconstitute its cached state from a playback of source data passed to it
through the update() method.
A view's job is to derive some data from the data in the Viewable object to which it is attached.
This can happen by a 'push' mechanism whereby new data in the underlying collection is pushed to the view
through the update method. A view that operates in this mode incrementally updates its derived data and
then provides this data to any queries or requesters through its Data interface and potentially through
other customized methods it exposes. When these methods are called, the view in push mode does not contact
its parent: it just supplies the requester with the data it already derived. The push mode is efficient
when data in a view is slow-changing with respect to how much its data is requested. For example, a view
calculating the mean of an intermittent signal over time may be queried very frequently. It incrementally
updates its statistic and then provides that quantity to callers whenever they want it, which may be much
more frequently than the incoming signal occurs.
The 'pull' mechanism is driven by requests to the view's Data interface or other customized data access methods.
A view operating in 'pull' mode may know whether it is "clean" or "dirty" by listening to its update method, or
it may not get any calls to its update method, and have to consult its parent to re-derive data when it is called.
This mode is efficient when requests to a view for its data are infrequent compared to the update frequency of its
parent's data. For example, a temperature sensor may be changing on a near-continuous basis, and a view which
derives some quantity from that sensor may be queried irregularly. It is most efficient for that view to operate
in pull mode, and only update itself when it is asked by some consumer for its derived quantity. It then asks the
temperature sensor for the current temperature, does its derivation, and returns to the requester.
To feed views that are registered with it, a view should only call the update method on its child views when its own
data has changed. If it receives an update which results in no change to its data, it should not update any children
views.
The following tables list the members exposed by the View type.
Public Properties
Name | Description | |
---|---|---|
![]() | EventType | Provides metadata information about the type of object the event collection contains. (Inherited from EventCollection.) |
![]() | HasViews | Test is there are any views to the Viewable. (Inherited from Viewable.) |
![]() | Id |
Gets a unique id for the view.
|
![]() | Parent | Gets or sets the View's parent Viewable. |