"midp 3.0 master class"
DESCRIPTION
Slides for the "MIDP 3.0 Master Class" presentation given by Paul Su, Oscar Gutierrez, and Lakshmi Dontamsetti.TRANSCRIPT
over
the
air
Mobile Java MasterClass
Developing with MIDP 3.0
over
the
air
Presentation• Oscar Gutierrez:Working in Vodafone R&D from 5 years ago. Mobile Java Specialist, EG
member in MIDP 3.0 as well as MSA spec leader collaborator
• Paul Su:Director of R&D, Aplix Corporation. Aplix MIDP 3.0 EG representative.
Lead architect for the Aplix MIDP 3.0 implementation.
• Lakshmi Dontamsetti:Software Engineer, Aplix Corporation. MIDP 3.0 UI subject matter
expert & designer
over
the
air
Introduction to MIDP 3.0
• Next evolution of MIDP. Includes additional functionality and improved components to keep MIDP a competitive development platform while retaining backwards compatibility with MIDP 1.0/2.x applications.
• 72 members in the expert group. 23 participant companies, 38 observer companies and 11 individual contributors.
over
the
air
New MIDP 3.0 functionality• CLDC 1.1.1• Mandatory JSR 135 v1.1
complianceMandatory concurrencyLIBlets/Shared LibrariesEventsInter-MIDlet communication
• Notification manager• Application Access Authorization• Extended Permission model
Auto-start MIDlets• Screensaver MIDlets
Idle screen MIDlets• User restrictions on application
lifcycle control
• IPv6 supportRecord store interchange format
• Record store encryption• Mandatory PNG, GIF, JPEG, &
SVG support• Multiple-screen support• Mutable Images• Animated Images• Application-defined fonts• TabbedPane• Menu• Layout policies for Forms• Application-specified splash
screens
over
the
air
Concurrency
• MIDP 1.0/2.x did not prohibit concurrency, but did not standardize behavior
• There are concurrency implementations in the market today, but behavior is fragmented
• MIDP 3.0 not only defines expected concurrency behavior but makes it mandatory and adds additional functionality that allows MIDlets to run together intelligently, not just at the same time
over
the
air
EventsEvents are a mechanism for notifying an application of changes in
system state and for application to application communication.
Two types of events:• System events are predefined events that are sent by the
system to registered applications.• App-to-app events are custom events defined and sent by
applications. Other applications can register to receive these events.
Access to these events can be constrained through the application level access mechanism.
over
the
air
EventsApplication may be launched automatically in response to
events. • Static registration through a JAD attribute:
MIDlet-Event-Launch-<n> :<Classname>;<AuthorizationMode>;<Launch-Condition>
Where:
<Classname> = The fully-qualified name of the class to launch.<AuthorizationMode> = true|false. <Launch-Condition> = The condition that should cause the application to be launch.
• Dynamic registration during executionAn application can dynamically register to be launched by calling
EventManager.registerApplication()
over
the
air
Events – transaction diagramAddress Book
MIDlet
Instant Messenger MIDlet
Event registry
2: Post App event “New Contact”
1: Register for App event “New Contact”
3: Receive App event “New Contact”
Instant Messenger: App event “New Contact”
over
the
air
Events tutorial• Registering a Listener for an event• IMClient.java• EventDataListener edl = new EventDataListenerImpl();• EventManager em = EventManager.getInstance();• em.addEventListener("midp30.demo.AddContact", edl, false);
• Creating and posting an Application-to-Application event
• AddressBook.java• EventManager mgr = EventManager.getInstance();• EventData eventData = new EventData("midp30.demo.AddContact", 10, eventString,
null);• try {• mgr.post(eventData, false);• } catch (Exception e) {• e.printStackTrace();• }
over
the
air
IMC: Inter MIDlet Communication• This API provides asynchronous bi-directional stream
connection between MIDlets
• Very similar to socket protocol, the imc protocol allows two types of connections:– Client connection– Server connection
• Access to these connections can be constrained through the application level access mechanism
over
the
air
IMC Client• IMC client MIDlets can open a connection to a server
MIDlet by using Connector.open() with a IMC client URI:
imc:// <MIDlet UID>/”*” : <server name> : <server version> ; [<authmode>]
• Client MIDlets can specify a specific server MIDlet to connect to or can use the “*” wildcard to connect to any server MIDlet that provides the same IMC service.
over
the
air
IMC Server• IMC server is identified by MIDlet UID, imc server name and
version
• A MIDlet acting as an IMC server can use Push register to be automatically launched when a matching client connection request is made.
MIDlet-Push-<n>: imc://:<server name> :<version>;<authmode>, <MIDlet UID>
• An IMC server has the ability to restrict the set of clients that are allowed to connect to it (Application Level Access Authorization)– Domain– Vendor– Signer
over
the
air
IMC Client-Server
IMCConnectionconn = (IMCConnection)Connector.open( "imc://*:com.vodafone.audioServer:1.0; authmode=false");IMCConnectionconn = (IMCConnection)Connector.open( "imc://*:com.vodafone.audioServer:1.0; authmode=false");
MIDLet Client:
MCServerConnectionserverConn = (IMCServerConnection)Connector.open( "imc://:com.vodafone.audioServer:1.0;authmode=false);MCServerConnectionserverConn = (IMCServerConnection)Connector.open( "imc://:com.vodafone.audioServer:1.0;authmode=false);
MIDLet Server:
MIDlet-Push-1: imc://:com.vodafone.locServer :1.0;authmode=false, VodafoneAudServer,*MIDlet-Push-1: imc://:com.vodafone.locServer :1.0;authmode=false, VodafoneAudServer,*
over
the
air
LIBlets/Shared libraries• LIBlets are independently packaged sections of code
and resources that can be shared between two or more MIDlets. LIBlets can depend on other LIBlets. All LIBlets run within the execution context of a MIDlet.
• LIBlets cannot be deployed separately from a MIDlet or executed as an independent entity. They are not dynamic services and cannot be updated independently from the dependent MIDlet.
over
the
air
LIBlets - Dependencies
• Dependencies can be declared on LIBlets, standards, or proprietary extensions.
Dependency-<n>: dependency name, Vendor name, LIBlet version, <type of dependency>, level of dependency
• LIBlet dependencies must also include the exact hash of the LIBlet.
LIBlet-Dependency-Jar-SHA1-<n>
LIBlet-Dependency-JAD-URL-<n>
over
the
air
LIBlets tutorial• LIBlet dependency declaration in the application JAD
file• Showtimes.jad• Dependency-1: mapservice, Aplix Corporation Inc., 1.0, liblet, required• LIBlet-Dependency-Jar-SHA-1: 601FD2020CF43821D33F85BA9021E273C4B22D26• LIBlet-Dependency-JAD-URL: mapservice• MIDlet-1: Showtimes, Showtimes.png, Showtimes• MIDlet-Jar-Size: 7654• MIDlet-Jar-URL: Showtimes.jar• MIDlet-Name: Showtimes• MIDlet-Vendor: Unknown• MIDlet-Version: 1.0
• LIBlet JAD file• Mapservice.jad• LIBlet-Jar-URL: mapservice.jar• LIBlet-Name: mapservice• LIBlet-Vendor: Aplix• LIBlet-Version: 1.0
over
the
air
Auto-start MIDlets• MIDP 3.0 allows developers to have greater control over the
lifecycle management of the MIDlet. With the Auto-Start feature, developers can have their MIDlets automatically launched upon power-up of the phone
• To protect the phone from malicious auto-start MIDlets, only MIDlets that have the javax.microedition.midlet.AutoStartPermission is allowed to auto-start.
• AMS MUST attempt to restart Auto Start MIDlets on exit/termination of the MIDlet.
over
the
air
Idle screen MIDlets
• Idle Screen (Home Screen): A default display which is presented to the user when no other activity is taking place on the device.
over
the
air
Idle screen MIDlets• Idle Screen MIDlet is a normal MIDlet that
has an additional UI component (IdleItem), which is rendered on the idle screen.
• The platform decides how Idle Screen MIDlets are positioned on the idle screen.
• Access to the idle screen is controlled by the security policy of the device.
• Idle Screen MIDlet is identified with JAD attributeMIDlet-Category-<n>: IdleScreen
over
the
air
RMS Data Interchange• MIDP 3.0 introduces support for a standalone secure
binary file format that can be provisioned to a device
• RecordStores can be shared between different MIDlets
• A MIDlet may control access to the share record store using the application level access control mechanism
over
the
air
RMS binary file format• The RecordStore class supports serialization/deserialization of
RMS data into this file format with optional encryption
• Binary file format must support:– Algorithms: AES 128-bit– Algorithm Mode: CBC– Padding Scheme: PKCS5Padding– Message Digest Algorithm: SHA-1– Password Based Key Derivation : PBKDF2 (part of PKCS#5 v2.0)
• RMS data files related to the application are identified in the application's JAD file using:
MIDlet-Persistent-Data-URL-<n>:<dataURL> [" “ overwrite] [" " encryptLocally]
over
the
air
RMS Data Interchange example
MIDlet-Persistent-Data-URL-1:Initdata.rms overwrite encryptLocally MIDlet-Persistent-Data-URL-2: http://vendor.com/data/Onlinedata.rms
MIDlet JAD file
MIDlet JAR file
Initdata.rmsInitdata.rmsOnlinedata.rmsOnlinedata.rms
http://vendor.com/data/Onlinedata.rms
MIDlet-Persistent-Data-URL-1 MIDlet-Persistent-Data-URL-2
over
the
air
ContactOscar Gutierrez IsiegasVodafone GROUP R&D.ES
T + 34 610 513921
Paul SuDirector of R&D, Aplix
Corporation of America
Lakshmi DontamsettiSoftware engineer, Aplix
Corporation of America
T [email protected]@aplixcorp.comwww.aplixcorp.com
over
the
air
Thanks!
Q & A