This section is informative (not normative).
In general, a stand-alone JME application
(e.g., a MIDlet) may be delivered to a device in the context of a broadcast
service. For instance, the normal MIDlet OTA process may be initiated by
providing a URL in the Electronic Service Guide of a broadcast service (e.g.,
as a RelatedMaterial metadata associated with a
Service or a Program). Additionally, the application may also be directly
broadcast to the device as a raw data file, possibly including a JAD file
along with the JAR file. Normally, once the application has been downloaded, it
should be installed on the device in order to let the user run it at a later
time.
We refer to a service-bound JME application when the activation of such an
application is controlled in association with selection of one or more related broadcast
services. These are normally A/V services, and in some cases, come with associated
programs in those services. It is up to the device’s system
software (usually dubbed “middleware”) or client application devoted to handle
the broadcast services to decide how to deal with the service-bound application
once it has been correctly downloaded on the
device.
It has been common to
launch a service-bound application as soon as part or all of it is downloaded
without going through a standard persistent installation process. And upon
termination, the constituting code and data will be discarded
since broadcast receivers capable of running applications were historically
limited on storage space.
Downloading and launching a service-bound
application should not interfere with the normal activation of the service. But recent
evolution of broadcast receivers allows storage of part or all of the
application code and data for repeated uses. Some of the relevant standards
for fixed reception TV have included supports for stored applications and API
registration.
Service-bound applications represent the most
general yet complex way to add interactivity to an A/V service. The application
may code any interactivity and presentation logic by leveraging all the APIs
available in the device, including JSR 272. Nevertheless, the application will
suffer from all the limitations brought by device characteristics. Concurrency
issues, lack of specific APIs, device limitations and capabilities will
strongly constrain the actual behavior of the application. Moreover, if the
application is broadcast to the device as a file, it should take into account
the differences between all the types of devices that will be able to receive
it.
In practice, due to the reasons above we do not
expect that service-bound applications will be used to add interactivity in the
first deployments of broadcast services. Nevertheless, the standardization
bodies are beginning to take into consideration the standard ways of adding interactivity
to a broadcast service, in order to simplify the future deployments of
interactive broadcast services.
JSR 272 does not specify how this type of
applications should be handled, and leaves the programmers to possibly leverage
additional JME APIs that could be available on the device. One possibility is
given by the JSR 211 Content Handler API (CHAPI), as explained in the
followings.
The CHAPI and its execution model let an
application invoke registered JME and non-Java applications, referred to as
content handlers. A content handler may be invoked by URL, by content type (the
most common content types are MIME types as defined in RFC-2046), or simply by
its ID. For instance, the specification suggests that the device’s Web/WAP
browser is one of the most important applications that should be run by the content handler mechanism.
Each content handler application executes in
the appropriate runtime: The interactions between the invoking and invoked
applications are carefully managed so that applications can be active either in
parallel or in sequence, depending on the runtime environment.
Moreover, the CHAPI works with the DRM
implemented on the device and do not bypass any mechanisms of the device for
implementing or enforcing content controls.
Most of the use cases defined for the CHAPI may
also apply to the case of broadcast services. For instance, content like video
or music clips, advertising coupons, game levels, and the likes can be
broadcast to users’ device which may receive, store locally, and open them by
means of the registered content handlers.
The case in which the broadcast content
consists of stand-alone service-bound
JME applications needs special considerations. The CHAPI may be used to launch
an application only if it is installed on the user device and registered as a
content handler. Additionally, dynamic registering and un-registering of
content handlers is allowed as far as the JME application implements the CHAPI
interfaces in order to be called as a content handler.
The broadcast service provider who wants to
broadcast service-bound JME applications targeted to devices in which the CHAPI
is available, has the option of coding those applications as content handlers
and instruct the client application devoted to handle the broadcast services to
follow the following steps:
Note that the service-bound JME application may
also leverage the JSR 272 API; for instance, it may access the ServiceContext
to continue showing the A/V tracks of the service. The actual behavior of
ServiceContext should be carefully taken into account in the implementation
guidelines of service-bound JME applications in order to avoid unexpected
results.