The content on demand feature allows an SDM model to delay the loading of its objects content in order to save resources. Unlike a tiling system, content on demand requires that all the objects be present in the model. The objects can be empty. Content on demand sends a notification when the content of a set of objects needs to be loaded, and, optionally, when it can be unloaded. Assuming that empty model objects have low memory and time footprints, content on demand allows you to fill them on demand and empty them when they are no more needed.

Content on demand addresses two main use cases:

The Concepts

The content on demand feature operates at the granularity of SDM model objects. The content controller maintains a state for each model object. A model object can be in one of three states:

The state changes after events, such as a user request, a zoom or a pan change (in fact visible area changes), have taken place. The controller then sends a notification to explicitly load or unload a set of objects.

Usually, the lifecycle of an object content is: unloaded, then locked, then loaded, then potentially back to unloaded.

The cache is virtual. The object content is held in the SDM model. When the state changes to loaded, this simply means that the content remains in the model. As a matter of fact, the SDM model implements the cache for the object content, and the controller manages this cache.

The controller contains the states of the objects as well as a handler that processes the load and unload commands.

Tuning Cache Size

Extreme values for the cache size have a radical impact on the content on demand behavior.

For other cache size values, the objects are loaded when locked and remain in the cache until they are flushed (FIFO way) to keep the average memory size close to constant. Note that when objects are requested to be locked, they are loaded before the cache is purged to avoid unloading an object that is going to be locked again. This means that the cache can temporarely be larger that the expected size.

Locking Requests

A locking request is an event sent to the controller to lock, load or unload objects. There are two types of event:

Both types of event are non exclusive: An area event may be followed by a set event, and conversely.

Notifications

The controller does not know by itself how to load the content of SDM model objects. On request, it calls a handler, ilog.views.sdm.modeltools.IlvContentHandler, that performs the load and unload actions by upgrading the SDM model. Then, the usual SDM model notifications take over to customize and refresh the graphic representations.

A load event is sent when the object state changes from unloaded to locked or loaded. An unload event is sent when the object state changes from locked or loaded to unloaded. No notification is sent when the state changes from loaded to locked.

Multithreading

The handler is able to work asynchronously, that is, if the controller asks to load an object, the handler marks the object as locked while the object may be loaded in a separate thread. In any case, the handler must notify the SDM model when the action is complete. The locking requests are synchronized, so that the handler holds the controller synchronization lock until completion of the event.

SDM Model Changes

The controller is aware of SDM model structural changes when:

To summarize, the controller forgets about the obselete objects of the model.

The Classes Involved

Using the content on demand feature involves the following steps:

All these methods are synchronized and return an integer which represents the number of objects that have switched to the requested state.

The following method retrieves the current state (LOCK/UNLOCK/UNLOAD) of an object in the controller. Depending on the handler implementation (typically, if actions are performed in a different thread), the state may differ from reality, for example, a content is not available although the state is LOCK.

Other methods of the IlvContentController class:

The IlvContentHandler Interface

The IlvContentHandler interface defines the following methods:

The source argument indicates the controller that sends the request.

The IlvVisibleAreaListener Class

The IlvVisibleAreaListener class computes the visible area of a view as it changes and sends it as a request to the controller. The constructor takes the controller as parameter. To start listening to the visible area changes on a view, call the method:

Example of use:

IlvVisibleAreaListener l = new IlvVisibleAreaListener(contentControler);
l.installListener(contentControler.getSDMEngine().getReferenceView());

The method requestAreaToLock can be subclassed to control the area to lock, as follows:

Content on Demand and Tiling Systems

The content on demand feature is similar to a tiling system, such as ilog.views.tiling, with the following major differences: