These examples are provided for illustration only. CLDC itself does not define any protocol implementations. It is not expected that a particular J2ME profile would provide support for all these kinds of connections. J2ME profiles may also support protocols not shown below.
HTTP records: Connector.open("http://www.foo.com");
Sockets: Connector.open("socket://129.144.111.222:9000");
Communication ports: Connector.open("comm:0;baudrate=9600");
Datagrams: Connector.open("datagram://129.144.111.333");
Files: Connector.open("file:foo.dat");
Network file systems: Connector.open("nfs:/foo.com/foo.dat");
KVM
http://java.sun.com/products/cldc/wp/KVMwp.pdf
CLDC 1.0
Aus CLDC 1.0a Spezifikation
CLDCspec10a.pdf von
http://jcp.org/aboutJava/communityprocess/final/jsr030/index.html
Sandbox Model
Supporting multiple, simultaneously running Java applications
Depending on the resources available on the device, a CLDC system can allow multiple Java applications to execute concurrently, or can restrict the system to permit only the execution of one Java application at a time. It is up to the particular CLDC implementation to decide if the execution of multiple Java applications is supported by utilizing the multitasking capabilities (if they exist) of the underlying host operating system, or by instantiating multiple logical virtual machines to run the concurrent Java applications.
Thread groups and daemon threads
A JVM supporting CLDC implements multithreading, but shall not have support for thread groups or daemon threads. (See JVMS §2.19, §8.12-14). Thread operations such as starting and stopping of threads can be applied only to individual thread objects. If application programmers want to perform thread operations for groups of threads, explicit collection objects must be used at the application level to store the thread objects.
MIDP 1.0a
Spec.pdf http://java.sun.com/aboutJava/communityprocess/final/jsr037/index.html
Two categories of APIs are shown on top of the CLDC:
MIDP APIs: The set of APIs defined in this document.
OEM-specific APIs: Given the broad diversity of devices in the MIDP space, it is not possible to fully address all OEM requirements. These classes may be provided by an OEM to access certain functionality specific to a given device. These applications may not be portable to other MIDs.
MIDP implementations MUST provide support for accessing HTTP 1.1 servers and services.
Each device implementing the MIDP MUST support the full specification of RFC2616 HEAD, GET and POST requests. The implementation MUST also support the absolute forms of URIs.
The MIDP specification does NOT mandate a datagram API/protocol for a MID. MIDs that implement a datagram API/protocol SHOULD use the GenericConnection framework (DatagramConnection interface) as defined by the CLDC specification.
Record Store getrennt von allen anderen Handy Daten
MIDP 2.0
http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html
MIDP 2.0 also requires HTTPS
Permissions and Code Signing
MIDlets that use the Generic Connection Framework may cost users money (in the case of network connections) or involve a security risk (in the case of serial port access). In light of the sensitivty of the connection framework, the MIDP 2.0 specification recognizes the concepts of trusted and untrusted code and permissions. Untrusted code cannot make connections at will; it must receive permission from the user. Code can be designated as trusted if the developer digitally signs it and the user's device can verify the signature.
Record stores may be shared between MIDlets.
Standardized connection strings for datagram, socket, and server socket connections. The specification doesn't require support for these types of connections but it recommends their implementation and provides supporting APIs.
Siemens Extensions (SL45i / 6688i)
http://www.cellconcept.com/j2me_siemens_doc/api/overview-summary.html
Voice Call
Vibra
Music Interface
Game API
Text SMS
File Managment (Open, create, delete,...)
Siemens Erweiterung
com.siemens.mp.gsm.*
provides methods for starting a call, accessing the phone book of the mobile and sending SMS
com.siemens.mp.io.*
gives you file access to the MMC and other input/ouput connections like IRDA
Generic Connection Framework
Während in der Java 2 Standard Edition Klassen z.B. zur Socket- oder Datagramm-Verbindung im Paket java.net vorliegen, muss in der Java 2 Micro Edition auf das Generic Connection Framework im Paket javax.microedition.io zurückgegriffen werden.
Das Generic Connection Framework vereinheitlicht die unterschiedlichen Verbindungarten und faßt sie in einer „Factory“ zusammen. Das Framework besteht aus einer Klasse Connector, deren statische open- Methode eine Instanz des Datentyps Connection zurückliefert. Connection ist das Interface von dem alle weiteren Schnittstellen des Generic Connection Framework abgeleitet sind. Die von open erhaltene Verbindung muss deshalb unter Umständen mit einem Typecast in die konkrete Verbindungsform konvertiert werden.
Mit dem Generic Connection Framework ist es für Hersteller möglich für Geräte auf die sie die KVM portieren, weitere Verbindungsprotokolle, z.B. Bluetooth oder Irda, zu unterstützen.
try {
StreamConnection scon = (StreamConnection) Connector.open("socket://127.0.0.1:4444"),
Connector.READ_WRITE, true);
InputStream is = scon.openInputStream ();
OutputStream os = scon openOutputStream ();
is.close ();
os.close ();
scon.close ();
}
catch (IOException ioe) {
// Exception behandeln …
}
[Codebeispiel 3.2] Aufbau einer Socket-Verbindung
Sms
Wireless Messaging API WMA-RI .pdf
Zusatzpaket WMATM in jedem J2ME- fähigen Endgerät verwendet werden, vorausgesetzt der Gerätehersteller implementiert die notwendigen zusätzlichen Klassen, die dieses Zusatzpaket benötigt.
The WMA is an optional package based on the Generic Connection Framework (GCF) and targets the Connected Limited Device Configuration (CLDC) as its lowest common denominator, meaning that it can extend both CLDC- and CDC-based profiles.
The interfaces for the messaging API have been defined in the javax.wireless.messaging package.
Permissions for MIDP 1.0 Platform
When the JSR120 interfaces are deployed on a MIDP 1.0 device, there is no formal mechanism to identify how a permission to use a specific feature can be granted to a running application. On some systems, the decision to permit a particular operation is left in the hands of the end user. If the user decides to deny the required permission, then a SecurityException can be thrown from the Connector.open(), the MessageConnection.send(), or the MessageConnection.receive() method.
Von
http://kissen.cs.uni-dortmund.de:8080/devicedb/index.html