simtools.data
Interface EndNotificationListener

All Known Implementing Classes:

Abstract1DShape, Abstract2DShape, AffineTransformData, AutomatonShape, ConnectionShape, CubeNodeJava3D, CubeNodeXith3D, DataAnimator.Data, DoubleDataAnimator.DoubleData, DynamicDataSourceInformation, EllipseShape, HistoryShape, HistoryShape.HookedTextShape, HistoryTextShape, ImageShape, Java3dShape, LinesShape, MultiStampedDataSourceInformation, PieChartShape, Plot, PlotShape, PolygonShape, PropertiesTransformGroupNode.ColorMapperManager, PropertyData, RectangleShape, SceneGraphData, SceneGraphDoubleData, SceneGraphFloatData, SceneNode, SceneNodeJava3D, SceneNodeXith3D, ShapeNode, ShapeNodeJava3D, ShapeNodeXith3D, SourceCategoryDataset, SourceIntervalXYDataSet, SourceMeterDataset, SourcePieDataset, SourceXYDataset, SphereNodeJava3D, SphereNodeXith3D, StreamingMSDataSourceInformation, StreamingTSDataPlugin.SourceCollection, SvgShape, TextArrayShape, TextShape, TimePlot, TimePlot, TimeStampedDataSourceInformation, TransformData, TransformData, TransformDataJava3d, TransformDataXith3d

public interface EndNotificationListener

This class is useful to optimize data source listeners, especially when listening to several data sources belonging to the same collection. When a data source notifies a change, the listener may have added an EndNotificationListener to the data source, and expect it to be called later on. Then in the case of a collection (or if the single data source changes both its index, value range, order, etc... at the same time), all events are processed as usual, but the listener may defer part of the processes it has to do at the end of the changes. In the case of a single notification, this changes nothing :the listener would just do its tasks in two steps instead of one. But in the case of multiple notifications, fast tasks specific to each event may be kept in each event notification, and heavy processes may be defered and done _only_once_ and _after_ all the changes are done in the shape. => big optimization. Especially, the listeners are propagated to the collection and may refer to multiple sources. Thus, the referer argument of the callback may not be the same object on which the listener was registered. Of course, it is perfectly possible to ignore this possibility and not register an end of notification listener. This is the former behaviour, and this is still perfectly valid, especially for objects that listen on only one event in only one data source. Those objects would gain nothing in a 2-step algorithm, and are better off with the simpler API. Note: This change is fully API and class-binary upward compatible with the former one-step way of doing things. But please, consider evolving each of your data source listener listeners on a case by case basis, as the performance improvement benefits _all_ the application, not just your own objects.

Method Summary

void	notificationEnd(java.lang.Object referer) This callback is called after all notifications were processed.

Method Detail

notificationEnd

void notificationEnd(java.lang.Object referer)

This callback is called after all notifications were processed. The referer object is the one to decide what the end means. For example, it may be a single data source notifying both a range change and a value change. Or it could be a collection notifying all its sources.