7.6 JavaTV | ITV Handbook: Technologies and Standards

JavaTV applications are Java class files and meta-data encapsulated within an iTV program to be extracted by a receiver capable of executing JavaTV applications (recall Figure 7.1). JavaTV is primarily directed at an audience of Java developers who are producing iTV content, or tools for creating such content. Much of the functionality that is required by an iTV content developer is already provided by other Java platform packages, such as the PersonalJava application environment and the JMF.

The JavaTV API is simplified to include only functionality that is unique to iTV receivers and not covered by PersonalJava and JMF. Some APIs that are generic to consumer electronics devices, such as persistent storage mechanisms, are not included in the JavaTV API. These non-television specific APIs are provided in new definitions for the application environment or are already being developed in conjunction with various television standards bodies.

JavaTV enables access to three types of components : program guide information, information about the data service, and the data service itself. The EPG related functionality enables applications to explore the transport-stream for announcements about current and upcoming programs. The data-service related functionality enables extracting components of the program and passing them to the JMF API for presentation onto the TV display.

The JavaTV architecture is depicted in Figure 7.3. The JavaTV application consists of an Xlet entry point and possibly a collection of additional classes. The code within that Xlet and the additional classes performs its function through JavaTV API calls. The code of the Xlet, application classes, and JavaTV API implementation is executed by a JVM, which is running under a RTOS and, optionally , natively interfaces with device drivers.

Figure 7.3. JavaTV Architecture.

JavaTV is an API specification and not a library; thus, to be able to write JavaTV programs there is a need to have a JavaTV implementation. All iTV authoring platforms that support Java provide such an implementation. As an example, AltiCast's suite of products enables running the JavaTV MHP application within their simulator.

The JavaTV API was designed to provide, among other capabilities, application life-cycle control and access to the functionality unique to a digital television receiver. This functionality includes audio/video streaming, conditional access, access to in-band and out-of- band data channels, access to service information data, tuner control for channel changing, and on-screen graphics control.

In addition, JavaTV provides a template that if followed, ensures interpretability of Java applications and the receiver components that they interact with. For example, it enables controlling tuners through service selection. EPG information includes a list of virtual channel and schedule of events within them. Information about the data service includes information about a list of applications and their data files. The data service itself includes data files.

Through integration with the JMF, JavaTV provides the additional functionality of media synchronization. Media synchronization allows interactive television content to be synchronized with the underlying video and background audio of a television program.

7.6.1 Overview of JavaTV API Packages

Java API specifications organizes types and their methods within the following packages:

javax.tv.locator : This package provides means for referencing data and resources accessible via JavaTV APIs. It defines the Locator interface, which is used as input to all methods used to construct objects to be populated for transport data. Object implementing the Locator interface are constructed through a locator factory.
javax.tv.service : This package provides mechanisms for accessing the SI database and APIs representing the SI elements it contains. Components within this package include SIRequestor , used to initiate data requests , and SIRetrievable , used to deliver the data retrieved.
javax.tv.media : This package enables management of components within the transport stream that correspond to media for content delivery. As an example, it enables extraction, selection, and presentation of individual video and audio tracks, delivered in a multiplex .
javax.tv.Xlet : This package provides standard means for Xlets and their execution environment to communicate. JavaTV Xlets comprise of a collection of Xlets, each having its own life-cycle, managed through the Xlet interface, and execution context, accessible through the XletContext .
javax.tv.Graphics : This package provides standard means for Xlets to manage their display area. It enables Xlets to discover their root container and provides a uniform mechanism for managing colors and blending.
javax.tv. Carousel : This package enables access to broadcast files embedded in a transport stream file system. This package works in concert with APIs within the javax.io package. Carousel files are handles to broadcast files and cannot be regarded or treated as regular files that have a physical allocation on a storage device.
javax.tv.Util : This package provides means for managing timer events. It is designed for generic use by downloaded Xlets, for example, to mark the time-out (or cancel) delivery requests, or, as another example, for synchronizing presentation of data.
javax.tv.Net : This package provides a single-method access point to IP datagrams transmitted in a broadcast stream. As an example, it could be used to access data transmitted through the ATSC IP Multicast transport.

7.6.2 Service Context

The JavaTV ServiceContext is a class that encapsulates the environment in which the JavaTV application is running. Intuitively, the ServiceContext is a high level representation of a tuner, its associated decoding hardware, the graphics resources allocated to the application, and state of presentation. To avoid the complexities of running multiple applications concurrently, receivers (such as those compliant with DASE Level 1) often limit the number of objects of this class that they support to a single instance at a time.

Typically, the life span of the ServiceContext objects should correlate with the lifespan of the middleware processes. In other words, all the ServiceContext should be generated on middleware boot, and destroyed on middleware shutdown.

The ServiceContext has a select() method which initiates the presentation of the iTV program. Presentation includes, among other things, loading and running of the JavaTV applications delivered within the selected service. This selection is asynchronous and completion is notified via an event-listener mechanism. Failure to select a service is reported via an exception, if it can be determined at the time select() is called, or via an event, if it is determined at some time later.

A ServiceContext can exist in one of the four states of Presenting , NotPresenting , PresentationPending , and Destroyed (see Figure 7.4 and Table 7.7). The initial state is NotPresenting . On successful invocation and completion of the select() method, from any state other than the destroyed state, the ServiceContext enters the PresentationPending state.

Figure 7.4. ServiceContext state transitions.

When a call to select() method completes successfully, either a NormalContentEvent or an AlternativeContentEvent is generated and the ServiceContext moves into the Presenting state. When the select() method fails, namely the middleware could not perform service selection, a SelectionFailedEvent is generated.

When service presentation is stopped for any reason, (e.g., due to viewer selections, by the application calling the ServiceContext.stop()) , the ServiceContext transitions into the NotPresenting state; this transition generates the PresentationTerminatedEvent .

The Destroyed state is used whenever the middleware needs to stop the use of the ServiceContext . This should not occur on normal operation, since once the Destroyed state is entered the ServiceContext can no longer be used for any purpose. Selecting a different channel is performed using the select() method; had the ServiceContext been destroyed on channel selection, the newly selected channel could not be displayed.

Table 7.7. ServiceContext States

State Name	Description
Not Presenting	The initial state of the `ServiceContext` . In this state, no service is presented to the viewer. The `ServiceContext` also enters this state if its `stop()` method is called or if a previously presented service can no longer be presented.
Presentation Pending	The `ServiceContext` enters the Presentation Pending state after the `select()` method is called and no exceptions are thrown. If a service was being presented in the previous state, the service continues to be presented in this state. If the selection operation does not complete successfully, the `ServiceContext` leaves the Presentation Pending state and attempts to return to its previous state.
Presenting	The `ServiceContext` enters the Presenting state if the service selection operation completes successfully. In this state, either normal content or alternative content is presented to the viewer.
Destroyed	The `ServiceContext` enters the Destroyed state when the destroy method is called. In this context, no service is presented to the viewer. Once this state is entered, the `ServiceContext` can no longer be used.

7.6.3 Xlets

A JavaTV Xlet is a program that can be included in an iTV page, much in the same way an image or video clip can be included. It is similar to applets that can be embedded within Web-pages. The receiver's or set-top box's application execution environment regards the class file implementing the Xlet interface as the entry point within the Java application. That class file is loaded and executed using the environment's JVM.

Figure 7.5 and Table 7.8 describe the Xlet life-cycle states (to be distinguished from the service-context states). A typical scenario is as follows : On receipt of the code and loading of the Xlet entry point class file, the application manager creates a new instance of the Xlet. The no argument constructor for the Xlet is called and the Xlet is transitioned into the Loaded state. Next, the application manager creates the necessary service context object for the Xlet to run, initializes the Xlet, and transitions it into the Paused state. The context object is used to allow the Xlet to access information about the environment in which it is running. Next, the application manager signals the Xlet to enter the Active state. At this point, the Xlet may acquire any resources (e.g., other class files, images) it needs, and begins to perform its service. At the end of the life cycle, the application manager signals it to stop its operation; such signaling may be initiated due to viewer selection as well as by the Xlet itself. The Xlet then stops performing its service. It is important that the Xlet releases all resources it used; if a resource is not released gracefully, it should be automatically released by the application manager.

Figure 7.5. Xlet life-cycle states and transitions.

Table 7.8. Xlet Life-cycle States and Transitions

State	Description
Loaded	The Xlet has been loaded and has not been initialized . This state is entered after the Xlet has been created using new. The no-argument constructor for the Xlet is called and returns without throwing an exception. The Xlet typically does little or no initialization in this step. If an exception occurs, the Xlet immediately enters the Destroyed state.
Paused	The Xlet is initialized and quiescent. It should not be holding or using any shared resources. This state is entered: From the Loaded state after the `Xlet.initXlet()` method returns successfully, From the Active state after the `Xlet.pauseXlet()` method returns successfully, From the Active state before the `XletContext.notifyPaused()` method returns successfully to the Xlet.
Active	The Xlet is functioning normally and providing service. This state is entered from the Paused state after the `Xlet.startXlet()` method returns successfully.
Destroyed	The Xlet has released all of its resources and terminated . This state is entered: When the `destroyXlet()` method for the Xlet returns successfully. The `destroyXlet()` method releases all resources held and perform any necessary clean up so it may be garbage collected; When the `XletContext.notifyDestroyed()` method returns successfully to the Xlet. The Xlet must perform the equivalent of the `Xlet.destroyXlet()` method before calling `XletContext.notifyDestroyed()` .

The entrypoint of every JavaTV application is a class which implements the Xlet Interface. This interface provides an application manager with four synchronized (i.e., blocking) methods to signal application life-cycle state changes to an Xlet. They should be synchronized to ensure that a lock is placed on the Xlet object interface when one of the life-cycle methods is called. This has the effect of blocking other life-cycle method invocation during the execution of a life-cycle method. A well-designed application manager should create individual threads to call the life-cycle methods on Xlets.

The Xlet package provides developers with APIs that deliver application life-cycle signaling in a JavaTV receiver environment. The Xlet API consists of two interfaces, Xlet and XletContext , that express the communication between an Xlet and its environment. The Xlet APIs use a callback to signal state changes (i.e., async nonblocking method invocation). The state of an Xlet can change by either the application manager calling one of the methods on an Xlet or by the Xlet notifying the application manager of an internal state transition via the XletContext object. The semantics of the state transition methods is as follows:

InitXlet : The callback Xlet.initXlet(XletContext ctx) is invoked by the application manager to signal the Xlet to initialize itself. An XletContext object is passed with this call to allow the Xlet to inquire about the environment in which it is about to execute, as well as to signal the application manager that it has changed state. on successful initialization, the Xlet transitioned into the Paused state. A failure to initialize is signaled to the application manager by throwing an XletStateChangeException .
StartXlet : The callback Xlet.startXlet() is invoked by the application manager to signal to the Xlet that it must now start performing its intended function and deliver the service. Typically, Xlets do not load all the classes and resources they need until this point. The startXlet() function must operate asynchronously; namely, it must return control to the calling application manager as soon as possible, so as to allow it to enter the Active state successfully. If the Xlet cannot enter the Active state, it must signal that to the application manager by throwing an XletStateChangeException .
PauseXlet : The callback Xlet.pauseXlet() is called by the application manager to signal the Xlet to stop providing service. When this method returns, the Xlet enters the Paused state. Xlets should release resources when this callback is called. The Xlet signals a failure to the application manager by throwing an XletStateChangeException .
DestroyXlet : The callback Xlet.destroyXlet() is invoked by the application manager to signal to the Xlet that it is no longer needed and that it will soon be purged from the system. On receipt of this call, Xlets are given the opportunity to perform all cleanup needed, such as saving preferences and releasing resources, to avoid abrupt irregular termination.

A simple example of Xlet life-cycle is a stock ticker that uses a back channel to retrieve stock quotes, which it displays on the viewer's television.

The application manager obtains the class files for the Xlet.
The application manager creates an instance of the XletContext object and initializes it for the new Xlet.
The application manager initializes the Xlet by calling its initXlet() method and passing it the XletContext object.
The Xlet uses the XletContext object to initialize itself and enters the Paused state.
The user selects a remote control key that, through the middleware, signals the application manager to start the Xlet.
The application manager calls the startXlet() method for the Xlet. The application manager assumes that the Xlet is performing its service.
On receiving this signal, the Xlet creates a new thread that opens the back channel to retrieve the stock quotes. The Xlet is now in the Active state.
The Xlet begins to show the stock quotes.
Due to circumstances beyond the control of the Xlet, it is no longer able to retrieve updated stock quotes.
The Xlet decides to continue displaying the most recent quotes it has. Note that the Xlet is still in the Active state.
After a time, the Xlet is still unable to open the back channel. It decides that the quotes it is displaying are too old to present and that it can no longer perform its service. It chooses to take itself out of the Active state. It calls the notifyPaused() method on the XletContext object to signal this change to the application manager.
Finally, the Xlet decides to terminate. The Xlet does some final clean up and calls the notifyDestroyed() method on the XletContext object to signal the application manager that it has entered the Destroyed state.
The application manager prepares the Xlet for garbage collection.

7.6.4 Electronic Program Guide (EPG)

EPGs are the most common applications found on today's television receivers and set-top boxes. An EPG's primary function is to provide the viewer with an overview of current and upcoming television programs. Usually, an EPG also changes the channel to the viewer's selection. With this type of Xlets, interactive performance and short startup times are critical to a positive user experience.

Typically, the EPG's GUI is laid out as matrix in which rows correspond to channels and columns represent time-slots. Some layouts were developed in which this matrix is laid out on a 3D box, cylinder, or sphere to achieve improved viewer experience.

The primary APIs used for authoring EPG Xlets is the javax.tv.service.guide package. This package contains classes typically used in EPGs, including program schedules, individual program events, and program ratings.

7.6.5 Tuning and Service Selection

In JavaTV, a distinction is made between two concepts: (a) the Service, which is an abstraction of a virtual channel within a major channel, and (b) the ServiceContext , which is an abstraction of receiver resources required to present this service. The only way to cause a channel (and transport stream) switch is through controlling the resources (not the services). This is done through the ServiceContext selection. The JavaTV service selection function can take, as input, either a locator (preferred) or a Service object.

There is a distinction between service selection and tuning; JavaTV does not provide tuning APIs. While service selection can often be regarded as a tuning operation, it is only possible for service selection to perform minor channel changes, which does not require tuner control, rather than a physical channel change, which typically implies tuning to a different transport stream. Therefore, it is not the case that every ServiceContext selection performs tuning. To prevent tuning outside the transport stream and into the transport of a competitor while allowing service selection within the current transport, middleware environments should implement a permission for transport stream changes which does not block all service selections.

The javax.tv.service.selection.SelectPermission defines a general permission that abstracts all types of switching, both between virtual channels within the same transport stream, as well as switching the entire transport stream. If switching between virtual channels within the same transport stream is to be allowed to all Xlets, then this permission should always be granted in case the selection does not entail switching transport streams. Therefore, a run-time check is needed to determine whether the service selection should be allowed. Such a check could be performed, for example, using the ServiceObject.getServiceNumber() , which allows detecting a major channel number change which is typically associated with switching of a transport stream. Such a check requires that the middleware provides a ServiceObject class which implements both the Service and the ServiceNumber interfaces, a constraints not specified by the JavaTV specification.

7.6.6 Transport Access

Data services are subsets of transport components, delivered by transport stream packets. They are described by data structures that contain details about extracting these components from the transport and processing them for purposes of rendering. Examples of such components are Java class files and icons used to assemble and execute a JavaTV Xlet.

Data services are usually structured hierarchically as follows. Each transport stream may contain major physical channels, each of which contains one or more virtual channels, each of which contains data services that carry Xlets assembled from resources such as files and streams (see Figure 7.6). Each of these components in the hierarchy may be associated with meta-data such as a name, description, or URI. Different standards have different meta-data specifications.

Figure 7.6. The structure of EPG data in an iTV transport.

At any given time, each virtual channel contains, in addition to video and audio streams, a single data service, namely the data services for a single virtual channel cannot overlap in time. Each data service may contain one or more Xlets, however at any given time only one Xlet may be active, namely Xlets may be started and stopped during the life-span of the data service so that at any given time at most one single Xlet is active.

Data services could contain various types of Xlets, including channel-bound Xlets, often referred to as program related Xlets, and unbound Xlets, sometimes referred to as stand-alone Xlets.

Bound Xlets are intended to be integrated with some video and audio components of a program. Many advertisement Xlets fall into this category. These Xlets execute only when viewers tune the channels to which these Xlets are bound. It is useful, for example, for a bound Xlet to be stored persistently on a disk of a receiver, and be launched when the channel it is bound to is selected. As soon as the active channel is selected, the Xlet execution is suspended or terminated. JavaTV does allow binding an Xlet to multiple channels.

Unbound Xlets are intended to be launched independently from channel selection. These Xlets often scan the transport for information. As an example, Xlets that could be designed as unbound are those that automatically download news and present flashing indicators as items are discovered .

7.6.7 Access to Broadcasted Files

The JavaTV API provides access to broadcast file and directory data through use of the file access mechanisms defined in the package java.io. The data in the broadcast file system is typically transmitted in a carousel wherein the contents of a remote file system are cyclically transmitted to permit reconstruction on the receiver. The JavaTV API models broadcast carousels as conventional disk file systems with high access latencies. Most interactions with the specific carousel protocols are handled by the JavaTV API implementation rather than the Xlet.

For example, accessing a DSM-CC-based broadcast file system is done using the following steps:

Creating CarouselFile of top-level directory using the assignment
```
 CarouselFile serviceGateway = new CarouselFile(locator); 
```
Listing top-level objects using the assignment
```
 String files[] = serviceGateway.list(); 
```

Creating a file object using the assignment

 CarouselFile myFile = new CarouselFile(serviceGateway, files[0]);

Creating a file input stream using the assignment

 FileInputStream fis = new FileInputStream(myFile);

Reading from the file using the assignment byte data = fis.read();
Closing file using fis.close();

7.6.7.1 IP Datagrams

The JavaTV API provides access to unicast and multicast IP datagrams transmitted in the broadcast stream through the use of the conventional datagram reception mechanisms of the java.net package. Xlets may receive unicast IP datagrams using the java.net.DatagramSocket class. Multicast IP datagrams may be received using the java.net.MulticastSocket class.

To support reception of multicast IP datagrams, the JavaTV API implementation needs to assign IP address which is unique to all receivers connected on the same cable subnetwork. To simplify management of these addresses, all set-top boxes should use the set of IP addresses reserved for use in private networks (see RFC 1918). The JavaTV Xlets may determine the local IP address assigned to them, and the service they belong to, using the class javax .tv.net.InterfaceMap . Xlets then uses this IP address to construct instances of java .net.MulticastSocket or java.net.DatagramSocket to receive multicast datagrams.

7.6.7.2 Streaming Data

The JavaTV API provides access to generic streaming data extracted from the broadcast using the JMF package javax.media.protocol. A JavaTV API Xlet typically refers to an individual data service component using a javax.tv.locator.Locator object. Using the method Locator.toExternalForm() , an Xlet converts the Locator object into a string from which a javax.media.MediaLocator object is constructed. The resulting MediaLocator object is then used to obtain a javax.media.DataSource object from javax.media.Manager . Subsequently, the DataSource object is used to obtain one or more PushSourceStream2 objects.

The interface PushSourceStream2 is used to access asynchronous streaming data. It is an extension to the JMF version 1.0 interface javax.media.protocol.PushSourceStream with a new read mechanism. The method PushSourceStream2.readStream() provides access to the payload of the data and throws exceptions to indicate data loss. The JavaTV API makes no guarantees concerning buffering or availability of the data obtained through PushSourceStream2 .

7.6.8 JavaTV Service Model

An iTV data service is regarded as a collection of content components for presentation on a receiver. Viewers often refer to this collection of components as a TV channel. On today's advanced television receivers, a service may consist of multiple audio, video, and data streams.

The description of all components of a service is referred to as the Service Information (SI), which is stored in the JavaTV SI database. The SI describes the layout and content of an audio, video, and data streams, such as the MPEG-2 transport stream.

The JavaTV API uses Locator objects to reference SI elements. A JavaTV locator is an opaque reference to any information that is addressable within the JavaTV API. The javax.tv.locator package contains a locator interface, a locator factory, and invalid, malformed locator exceptions. An instance of the locator class may represent a network-independent name and, at the same time, have mappings to multiple network-dependent locators. The JavaTV API provides methods for discovery of network dependencies and transformation from network-independent to network-dependent locators.

Implementers of JavaTV API are expected to create a locator hierarchy whose elements implement the locator class. For example, a vendor base locator class should be used for all locators used by a specific middleware vendor. The locators used by the downloaded JavaTV Xlet must extend that hierarchy.

Various protocols for transmitting SI are used and standardized today. For example, DVBSI is used in various satellite, cable, and terrestrial systems; the ATSC A56 standard is used on both satellite and cable; and the new ATSC PSIP (A65) is used on terrestrial and cable DTV. There are also a wide variety of private protocols. The JavaTV API provides an abstraction of SI protocols, therefore a JavaTV Xlet does not have to be aware of the SI protocol that delivers information to the receiver. As a result, the Xlet is not required to have special code to run in various environments, such as DVB-based, SCTE-based, or ATSC-based systems.

7.6.8.1 Overview of the SI Database Packages

The SI database object model allows various views of SI, based on an Xlet's needs. Each view is represented as a package in the JavaTV SI APIs. The SI API packages are Service, Navigation, Guide, and Transport.

javax.tv.service : This package provides the primary point of access to the SI database and contains classes common to the other SI packages, such as the Service and SIElement interfaces.
javax.tv.service.navigation : This package contains classes that are used to navigate the existing data services.
javax.tv.service.guide : This package contains classes useful for EPGs, including program schedules, individual program events, and program ratings.
javax.tv.service.transport : This package represents the MPEG-2 delivery mechanism.

It is generally believed that most digital TV receivers are likely to be unable to cache all the SI data in memory. In a typical scenario, a receiver caches a subset of the SI data, consisting of the most frequently used information. When a reference to uncached data is made, the receiver needs to wait for the data to reappear in the transport and, when it reappears, parse the relevant portion of the transport stream. Because such access to the transport stream may take a significant amount of time, the SI APIs provide asynchronous access to information that is not cached. The SI APIs also provide a flexible mechanism for future extension of the API through the extension of SIElement , which would allow access to additional information.

For an Xlet to acquire components of a service, a reference to the SI Manager must first be obtained; typically, a single SI Manager should be constructed per JVM process. Next, once the SI Manager is obtained, retrieval proceeds through one of several possible routes:

ServiceCollection : This is used as an access point for collecting the list of data services embedded in a transport stream. In ATSC standards, due to the one-to-one mapping between data services and virtual channels, this corresponds to the list of virtual channels.
Transports Array : This is used as an access point for acquiring information about accessible transport streams. In DVB, the transports array may expose various types of entities (e.g., bouquets, networks, or transport streams) by optionally implementing additional interfaces (i.e., BouquetCollection , NetworkCollection , or TransportStreamCollection ).

As an example, to retrieve EPG related information delivered in a transport, access is performed in an asynchronous fashion using SIRequestor s, which is an interface for asynchronous SI retrieval requests. The SIRequestor registers itself at the time of the asynchronous call for a single request and is automatically unregistered when the request is completed. Xlets can disambiguate retrieval operations by registering a unique SIRequestor for each retrieval request.

The SI information is organized in a database accessible through a service package containing the basic SI classes, events and exceptions. It provides a high-level abstraction of the SI information which describes the layout of the content delivered over a multiplex. For maximum flexibility, the designers of the JavaTV Service package introduced additional derived classes which organize it into the following views of SI database:

Navigation view : This view is accessed through the Navigation package and contains the main set of classes and interfaces that are used to navigate the existing services (DVB Services, ATSC, or SCTE virtual channels).
Guide view : This view is accessed through the Guide package and provides information useful for EPG including program schedules, individual program events, and program ratings.
Transport view : This view is accessed through the Transport package that isolates some of the specific delivery media information. The classes provided in this package currently represent the MPEG-2 delivery mechanism.
Demultiplex view : This view is accessed through the Selection package that provides a convenient mechanism to select a Service (i.e., tune to it and start presenting it).

The javax.tv.service package utilizes the basic data element called SIElement , not all of which may be supported in a given broadcast environment. Asynchronous retrieve operations for unsupported SI elements result in the failure code DATA_UNAVAILABLE. Likewise, synchronous query operations may fail indicating that the requested data is unavailable.

7.6.9 Time Synchronization

The service information usually contains system time related information in the form of the PSIP STT message or DVB TDT and TOT messages. It is assumed that the local TV receiver time is synchronized with the system time of the service currently tuned and that this value can be obtained using the java.util.Date class. This is straightforward if all transport multiplexes use a reliable and synchronized data source (e.g., GPS). If a certain multiplex provides erroneous time information, it is up to the receiver implementation to resolve the conflict.

7.6.10 Change Notification

The SI APIs permit Xlets to be notified of changes to elements in the SI database. There are multiple sources of SI change notification, as listed in Table 7.9. An Xlet can register as an SIChangeListener with the above listed objects to be notified with an SIChangeEvent subtype when a change occurs. The resulting SIChangeEvent indicates the SIElement that changed in the database. Note that it may be quite difficult for the receiver to provide detailed information concerning the data that changed without a field-by-field comparison of old and new MPEG tables from the broadcast. The receiver may therefore choose to deliver an SIChangeEvent indicating a change at a high level in the SI hierarchy and require the Xlet to determine the specific nature of the change.

Table 7.9. Capturing Transport Changes Using JavaTV

Change Type	Implementing Class
Transport Changes	The TransportStreamCollection objects report changes concerning TransportStream information on a Transport.
Service Changes	Transport objects report changes concerning services.
Service Detail Changes	ServiceDetails objects report changes concerning ServiceComponent information for individual services.
Schedule Changes	ProgramSchedule objects report changes detected in the program events in the schedule, including the current ProgramEvent.
Network Information Changes	NetworkCollection objects report changes concerning Network information on a Transport (not available in ATSC).
Bouquet Information Changes	BouquetCollection objects report changes concerning Bouquet information on a Transport (not available in ATSC).