The Lifecycle Of MHP Applications

As we have already mentioned, every MHP application is tied to a specific service: an application can not exist without having a parent service. Each service will include a list of applications associated with it (the Application Information Table, or AIT), and any applications not listed in the AIT for the current service will be killed.

While this may seem like a very restrictive approach, it has a number of advantages for users and broadcasters. For broadcasters, it means that they always know which applications will be running at any given time – if an application is not listed as startable in the AIT, it will not be running. This makes it much easier to test whether a given set of applications will operate correctly with one another, which in turn makes those applications more reliable for the end user. End users also benefit by only having access to those applications that are relevant to the current show or service (as well as any general-purpose applications such as an EPG which may be signalled on every service). This makes it easier for the user to navigate through the available applications and choose which one(s) the want to run.

The AIT is more than just a list of applications, however. Each application listed in the AIT will have acontrol code associated with it, which tells the receiver what it should do with that application. This control code can take a number of values, as shown in the table below.

Applications with a control code of AUTOSTART will be started automatically when the receiver changes to that service. This allows the broadcaster to automatically start an application associated with the current show (e.g. a news ticker for CNN).

Applications with a control code of PRESENT will not be started automatically, but will be added to the receiver’s list of available applications. The user can then choose to start this application by choosing it from that list. This may be used on a sparts broadcast to indicate that a sports statistics application is availalbe, but it will onyl be starte dif the user chooses to do so.

Any applications with a control code of KILL or DESTROY will be automatically killed by the receiver. For instance, this could be used at the end of a show to indicate that an application associasted with that show should be killed. The only difference between these two control codes is that an application with a control code of KILL will be granted the option to keep running if the application chooses to. Applications with a control code of DESTROY will always be killed.

The PREFETCH control code is only valid for DVB-HTML applications, and indicates that the application should be loaded but not actually started yet.

The final control code that can be used is REMOTE. This indicates that the receiver must switch to a different service in order to start this application.

More details of the AIT can be found in the tutorial on application signalling.

More than one application may be running at any time, and so the user needs some way of switching between them. Like the process for displaying the list of availalbe applications and starting one of them, this is not specified by MHP and can be handled in any way that the middleware designers see fit. Some receivers will choose to only display one application at a time; in this case, any other running applications may be paused until the user switches to them again. Exactly what it means to pause an application is not clear. It’s generally agreed that a paused application should free any scarce resources and make itself as unobtrusive as possible (stopping threads, freeing as much memory as possible, etc.), but there is no clear list of exactly what it should do.

The process of resuming a paused application is similarly unclear, and will generally involve the reverse of what happened when the application was paused. In both cases, the receiver will not enforce any particular standards. It will tell the receiver to pause, and may hide any graphical elements, but any other behaviour is up to the individual application.

Applications may be killed by the user as well as by the middleware, and most applications will include some way of quitting. Once an application has terminated, the user can re-start it simply by selecting it from the list of available applications (assuming that the broadcaster has not changed its control code to KILL or DESTROY).

Changing services and the lifecycle of an application

If an application can only be run if it is listed in the current service, changing to a new service will affect which applications can run. Any running applications that are listed in the new service will continue to run with out interruption. Any applications which are not listed, however, will automatically be killed. This seems harsh, but again it means that only relevant applications will be run. There is no point running a quiz application associated with a game show, for instance, if you are now watching a soccer match.

There are some cases, however, where the broadcaster may want to allow an application to continue running if it’s already been started, but not allow new copies of that application to be started. This would allow a user to continue watching a news ticker, for instance, but not start a new instance of it. To allow this, some applications listed in the AIT can be marked as ‘external’ applications – the entries for these applications do not contain all of the information needed to start the application, but simply tell the receiver that any running copies of this application should not be killed.

This is all made marginally more complex by the fact that some applications can be signalled in the AIT as being bound to the current service. This adds another step to the process, where any applications that are signalled as being service bound get killed before anything else happens.

This isn’t actually as scary as it sounds. Basically, what happens is this:

1. The application manager examines the current set of applications. Any which are signalled as being service bound are killed immediately.
2. The application manager examines every application that is signalled on the new service. Any applications that are signalled as auto-start are loaded and started.
3. Any applications that were already running and are not signalled directly in the AIT are compared against the application identifiers listed in the external application authorization descriptors.
4. Any already running applications that is not signalled, and is not listed in these descriptors is killed.

To further complicate matters, each application specifies which MHP profile and profile version it requires to run. This allows a receiver to decide if an application can actually be run on that MHP implementation, and only show the user those applications that will run. Any AIT entry with a profile or profile version entry higher than the receiver can handle will be ignored. More information on profiles in MHP is given in a separate section of this tutorial.