The Embedded Devices (EDs) being the potential platforms of the MEEP-1.0 profile, embrace a broad range of device types with very varying capabilities. In order to take this into consideration on the one hand, but enable a suitable footprint of the implementation on a concrete device (especially those with very limited memory resources) on the other hand, optionality is a very important characteristic of MEEP-1.0.
Optionality in MEEP-1.0 requires to give applications the possibility to declare which optional components of MEEP-1.0 they do expect in order to be able to run. Therefore the table with Dependency Names for Standard APIs is amended by the following entries :
Additional Dependency Names For MEEP-1.0 Optional Standard APIs and Components |
||
---|---|---|
Dependency Name |
Specification Defined In |
Version Format |
microedition.lui | [LUI], javax.microedition.lui (Line-oriented UI) package | Undefined |
microedition.rms | [RMS], javax.microedition.rms (Record Management System) package | Undefined |
microedition.media.audio | [JSR135], Mobile Media API
Optional Audio Subpackage
TODO: If the subpackage is defined in JSR-135, the attribute should also be defined there. |
Undefined
TODO: Probably also a JPVS conformant versioning. |
microedition.io | [IO], javax.microedition.io (Connectivity) package as defined in MEEP-1.0 | Undefined |
microedition.io.comm | Support of javax.microedition.io.CommConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8.
|
Undefined |
microedition.io.datagram | Support of javax.microedition.io.UDPDatagramConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8.
|
Undefined |
microedition.io.multicast | Support of javax.microedition.io.UDPMulticastConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8, as well as support of
javax.microedition.io.UDPDatagramConnection in
GCF without the necessity to require this explicitly.
|
Undefined |
microedition.io.http | Support of javax.microedition.io.HttpConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8.
|
Undefined |
microedition.io.https | Support of javax.microedition.io.HttpsConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8.
|
Undefined |
microedition.io.secure | Support of javax.microedition.io.SecureConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8.
|
Undefined |
microedition.io.socket | Support of javax.microedition.io.SocketConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8.
|
Undefined |
microedition.io.serversocket | Support of javax.microedition.io.ServerSocketConnection in
GCF, being part of the underlying CLDC-8 configuration; this includes
support of the GCF itself in CLDC-8, as well as support of
javax.microedition.io.SocketConnection in
GCF without the necessity to require this explicitly.
|
Undefined |
microedition.swm | [SWM], javax.microedition.swm (Application Management System) package | Undefined |
microedition.cellular | [CELLULAR], javax.microedition.cellular (Cellular Network) package | Undefined |
microedition.event | [EVENT], javax.microedition.event package (Event Management) | Undefined |
microedition.power | [POWER], javax.microedition.power package (Power Management) | Undefined |
microedition.concurrency | [CONCURRENCY], Application Concurrency | Undefined |
microedition.liblets | [LIBLETS], Application Suites and LIBlets | Undefined |
microedition.provisioning | [PROVISIONING], Application Provisioning | Undefined |
microedition.multiplesigners | [MULTIPLE_SIGNERS], Application Provisioning | Undefined |
microedition.securityframework | [SECURITY_FRAMEWORK], Security for Applications | Undefined |
The dependency names listed in the table above MUST also be available as
system properties (see
table
in the related chapter). The value of those system
properties MUST be true
or false
. This properties
inform about whether a certein optional API is available in the implementation
or not.
The API of an optional package that is not available in an implementation MUST NOT be provided, and the package MUST NOT exist.
Example: If an implementation decides not to include any user
interface package (see below), then neither the
javax.microedition.lui
nor any API for bit-mapped
graphics and UI (defined outside the scope of this specification)is
allowed to be existent in this implementation.
The following sections discuss the several options for the customization of a concrete MEEP-1.0 implementation.
The existence of a display, and - if available - it's capabilities from a very simple line display without any graphics to a high-end display with graphical capabilities comaprable with those of a mobile phone is a degree of freedom for device implementing MEEP-1.0.
As a consequence, it would make no sense for MEEP-1.0 to offer one user interface library and force every implementation to include it. The following three options are offered therefore for the customization of MEEP-1.0:
Applications requiring the implementation of the LUI package in order
to be able to run, are recommended to declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.lui
dependency name
as defined here.
After chosing one of the three options, an implementation MUST implement the complete javax.microedition.lui for option two and/or the complete bitmap-oriented graphics package for option 3. When chosing option 1, any user interface functionality MUST NOT be implemented.
The usage of peristent storage and a record management system is optional for MEEP-1.0.
As a consequence, the following two options are offered for the customization of MEEP-1.0:
Applications requiring the implementation of the RMS
optional package in order to be able to run, are recommended to
declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.rms
dependency
name as defined here.
After chosing one of these options, an implementation MUST implement the complete javax.microedition.rms or nothing. When a decision has been made agains RMS, any persistent storage management functionality MUST NOT be implemented.
The support of multimedia content is optional for MEEP-1.0. If multimedia content is supported, this means support just for the audio portion of MMAPI. If a device has a bit-mapped graphics and defines an appropriate UI for it (being out of the scope of this specification), it can decide to implement the full MMAPI as defined in JSR-135 instead, also outside the scope of MEEP-1.0.
As a consequence, the following two options are offered for the customization of MEEP-1.0:
TODO: So far, this audio subpackage is not defined in JSR-135 yet. We still have to do that (same subpackage as defined in MIDP 2.0 / IMP-NG).
Applications requiring the implementation of the Audio support
optional package in order to be able to run, are recommended to
declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.media.audio
dependency
name as defined here.
If chosing option 2, an implementation MUST implement the complete audio subpackage as defined in JSR-135. When chosing option 1, any multimedia support MUST NOT be implemented, or the full MMAPI as defined in JSR-135 has to be implemented outside MEEP-1.0. Mixtures of those alternatives are not allowed and not necessary.
Basic connectivity functionality is provided by the
javax.microedition.io
package of the underlying configuration.
GCF is part of CLDC-8, but not all protocols have to be
implemented. If somebody tries to open a connection via an unsupported
protocol using Connector.open()
, a
ConnectionNotFoundException
will be thrown.
Applications requiring the implementation of GCF in the underlying CLDC-8
configuration and of certain protocols in order to be able to run, are
recommended to declare these requests using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using one or more of the following dependency namse as
defined here:
microedition.io.comm
microedition.io.datagram
microedition.io.multicast
microedition.io.http
microedition.io.https
microedition.io.secure
microedition.io.socket
microedition.io.serversocket
Extended functionality (Inter-MIDlet Communication protocol, PushRegistry) is offered in the javax.microedition.io package of this specification. This package is optional for MEEP-1.0. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.
Applications requiring the implementation of the MEEP IO package in order to be
able to run, are recommended to declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.io
dependency name as
defined here.
Non-normative statement:If neither the MEEP IO package nor any of the GCF protocols, classes or interfaces are required, the GCF package itself in CLDC-8 is not needed as well. Platforms including CLDC-8 and MEEP-1.0 can decide not to implement it for deployment.
Basic AMS functionality as the general lifecycle management of IMlets is part of any MEEP implementation. Extended functionality (settings management, extended suite installation features etc.) is offered in the javax.microedition.swm package of this specification. This package is optional for MEEP-1.0. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.
Applications requiring the implementation of the SWM package in order to be
able to run, are recommended to declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.swm
dependency name as
defined here.
An API to handle cellular network functionality is offered in the javax.microedition.cellular package of this specification. This package is optional for MEEP-1.0. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.
Applications requiring the implementation of the Cellular Network package in
order to be able to run, are recommended to declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.cellular
dependency name as
defined here.
An API to handle events for system state changes and app-to-app communication is offered in the javax.microedition.event package of this specification. This packages is optional for MEEP-1.0. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented. In particular, it can be implemented with or without the javax.microedition.power subpackage, being an option for itself.
Applications requiring the implementation of the Event package in order to be
able to run, are recommended to declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.event
dependency name as
defined here.
An API to handle power management is offered in the javax.microedition.power package of this specification. This packages is optional for MEEP-1.0. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.
Applications requiring the implementation of the Power Management package in
order to be able to run, are recommended to declare this request using the
MIDlet-Dependency-
<n>, or
LIBlet-Dependency-
<n> attribute,
respectively, using the
microedition.power
dependency name as
defined here.
MEEP-1.0 implementations may or may not allow applications to run concurrently. If concurrency is implemented, it MUST follow the rules as defined in the Application Concurrency chapter of this specification. If concurrency is not implemented, any feature making only sense for concurrently running applications (like inter-IMlet communication) haven't to be implemented neither.
In MEEP-1.0, a lot of components, features and packages are optional. While this in general means that - with an isolated view onto a particular package or feature - it can be chosen whether it is implemented or not, the relationsship between those specification elements is more complex. The reason is, that there exist dependencies between those elements, i.e. a certain feature or package may not be implementable if another feature or package is missing. Implementors will have to take those dependencies into account when configuring their implementation.
The chapter "Profile Sets" gives an (informal) overview about some probably popular combinations of optional components for certain use cases. The possibilities are not limited to those combinations though. Any combination is possible as long as dependencies are taken into account.
The following table gives an overview about those dependencies:
Dependencies of optional MEEP Components |
---|
![]() |
x means the component in the first line of the table is a pre-condition for the component in the first column of the table.
1) Only for the "classical" provisioning model, the implementation of GCF and the HTTP and/or HTTPS protocol is a precondition. As MEEP-1.0 also allows alternative provisioning models (out of the scope of this specification), those may not require anything of it.
2) What's meant with "IO package" here is only the package
javax.microedition.io
as defined in this specification.
This does not include I/O functionality defined in other specifications,
in particular not those defined in CLDC-8 (GCF etc.).
Please notice that the part of the table above being highlighted gray contains information about dependencies with elements not being part of this specification (GCF is specified in CLDC-8). The information in this gray highlighted part is therefore just informative, not normative (while the dependency information in the white table fields is normative part of this specification).
The interview part of the TCK has to use those dependency definition for checking the conformance of an implemntation. If a component is declared to be implemented, then the TCK will assume all components it depends on as also being implemented. If this is not the case, the TCK MUST fail.