Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 6
Текст из файла (страница 6)
This approach means abstractions withinapplication modules remain the same when communication changesfrom one form to another. Essentially, the binding of the protocols is12INTRODUCTION TO J2MEcarried out at runtime. At implementation level, the open() parameter(up to the first ”:”) instructs the system to obtain the desired protocolfrom the location where the protocol implementations are stored. Thislate binding allows an application to dynamically adapt to use differentprotocols at runtime.1.2.1.4 SecurityImplementing a full J2SE-style security policy requires a large amount ofmemory that is not available to typical CLDC devices. CLDC thereforeimplements a simpler domain-based security model, which specifies:• Java classes are properly verified and guaranteed to be valid Javaapplications; the classes are pre-verified at build time, which meansthat the CLDC implementation has much less to do to verify a JAR file• only a limited, predefined set of Java APIs is available to theapplication programmer: those defined by CLDC, the profiles andoptional packages• the downloading and management of applications on the devicetakes place at the native code level inside the virtual machine; nouser-definable class loaders are provided• the set of native functions accessible to the virtual machine is closed,meaning that the programmer cannot download new libraries containing native functionality; native functions other than those associatedwith the Java libraries provided by the configuration or profile cannotbe accessed• the programmer cannot override the system classes provided in thepackages java.*,javax.microedition.* and other profile orsystem-specific packages; this is governed by a class lookup whichis performed during class verification and provides the reason for thepre-verification stage of MIDlet (the basic MIDP application structure) packaging.Further security measures may, of course, be implemented by the profile,as shall be seen in Section 1.2.2.1.2.2 MIDPThe Mobile Information Device Profile (MIDP) combined with CLDCprovides a more focused platform for mobile information devices, suchmobile phones and entry-level PDAs.
MIDP provides the vertical integration required to make the Java runtime environment applicable tothese devices by providing direction for the base environment providedby CLDC.The MIDP specification has been revised under JSR 118 (Symbian isone of the contributors to the JSR 118 expert group). MIDP 2.0 extendsCLDC AND MIDP13the original definition in a number of ways and provides a platform whichenables developers to create highly graphical, audio-capable, networkedapplications for mobile devices. A maintenance release, MIDP 2.1, isbeing specified.Supported by many integrated development environments, MIDP hasbecome a widely-accepted platform and has been deployed on manymobile devices around the world.
If developers take the approach thatthey can ”write once and tweak everywhere”, they can leverage theunderlying technology to distribute enterprise, utility and entertainmentapplications to a wide and varied audience.The introduction of over-the-air provisioning has standardized themethod by which applications may be deployed to end-users.
Users canbrowse web or WAP sites to locate applications and the ApplicationManager System (AMS) checks for versioning and compatibility with thehost device and manages local installation. MIDP is also optimized toprovide a graphical user interface for mobile devices, regardless of inputmethod and screen size.1.2.2.1 MIDP PackagesThe MIDP 2.0 specification offers developers seven packages with whichthey may create applications. The packages are derived from CLDCas well as providing additional classes, which can be found underjavax.microedition.*.
This follows the rule that all packages andclasses inherited from J2SE must follow the same naming conventions.All new classes not inherited from J2SE must be given a new namingconvention, hence the creation of the javax.microedition packagenomenclature.Inherited classesThese classes are inherited from J2SE via CLDC:• java.lang• java.io• java.utilMIDP 2.0 classesThese classes extend the CLDC environment and provide user interface,gaming, MIDlet application framework, persistent storage, multimedia,network and security classes.
Details of these classes can be found inAppendix 2:• javax.microedition.io provides networking support basedupon the Generic Connection Framework defined in CLDC• javax.microedition.lcdui provides a standard set of user interface classes14INTRODUCTION TO J2ME• javax.microedition.lcdui.game is new to MIDP 2.0 andprovides a game development framework aimed at speeding up thegame development process• javax.microedition.media is new to MIDP 2.0 and providesbasic audio functionality such as playback and simple tone generation• javax.microedition.media.control is new to MIDP 2.0 anddefines the specific Control types that can be used with a mediaPlayer• javax.microedition.midlet provides the MIDlet framework• javax.microedition.rms provides persistent storage for applications, even when the MIDlet is not running; a ‘‘best effort’’ is alsomade by the device implementation to retain data during power loss• javax.microedition.pki is new to MIDP 2.0 and provides endto-end security for MIDlets by the introduction of registered domains;trusted MIDlets can be installed and given extra access to the device.1.2.2.2 Core FunctionalityMobile User Interface (LCDUI)MIDP provides a set of standard components to aid the creation ofportable, intuitive user interfaces.
These classes reduce the developmenttime and also reduce the size of the final application.The standard classes include screen objects, which hold objects suchas choice groups, lists, pop-up alerts and progress bars. Forms can becreated to capture user input via text entry components, read-only fieldsand custom items. All screen and form objects are device-aware andprovide support for native display, input and navigation techniques.MIDP 2.0 also sees the introduction of the CustomItem class, whichallows developers to define their own form items.Multimedia and Game FunctionalityMIDP provides an ideal opportunity for developers to create game andother entertainment content for mobile devices. A set of low-level APIsallows the developer to take control of the screen at pixel level.
Graphicscan be animated and user input can be captured. The Game API addsgame-specific control over animation with its framework implementation managing sprites, collision detection, layers and tiled layers. Built-inmultimedia support is also provided with the Mobile Media API (MMAPI),an optional MIDP package that adds video and other multimedia functionality. MIDP also has a subset of the MMAPI which provides supportfor simple tone generation and playback of WAV files.The Game API has been added as part of MIDP 2.0 and furtherconsolidates the case for Java being a game development platform formobile devices. Coupled with over-the-air provisioning, this offers aCLDC AND MIDP15strong business case for generating revenue streams from users obtainingentertaining applications whilst on the move.
The provision of this gamedevelopment framework leaves the designer more time to work on gameplay, rather than having to repurpose home-made animation classes tosuit another application. This also reduces application size and optimizesanimation routines by permitting extensive use of native code, hardwareacceleration and device-specific image data formats, as required.The Game API provides a manager for sprites and layers, as well asproviding an implementation for creating complex tiled layers.
The layermanager keeps an index of all screen objects registered with it and rendersthem on screen as required when calls are made to its paint() method.The Media API has been created for MIDP 2.0 as a subset of thelarger Mobile Media API (MMAPI), developed under the Java CommunityProcess JSR 135. When the MMAPI was developed it was recognizedthat smaller constrained devices, such as mobile phones, would not beable to accommodate its full complement.
Wisely, it was recognized thatnot all mobile devices would, for example, have cameras so making thiscompulsory would be ineffective. The MIDP 2.0 Media API thereforesets out to provide upwards audio compatibility with MMAPI. The MediaAPI provides the ability to perform simple tone generation, audio playback of WAV files, and general media controls such as start, stop andvolume control.Extensive ConnectivityDevelopers can enable their applications to communicate over a networkas required (see Section 2.1.3.2). Interfaces are available for communication over http, https, datagrams, sockets and serial ports. MIDPalso supports the SMS capabilities of GSM and CDMA networks throughthe optional Wireless Messaging API (WMA).
WMA 2.0 even supportsMMS capabilities. A specific device may not provide support for all ofthese protocols.Communication with third parties can also be created using an eventbased networking model. MIDP supports a server push model basedupon a push registry which keeps track of registered third party inboundcommunications from the network. When information arrives, the devicecan start the registered MIDlet (this may depend on user approval). Thisenables developers to create turn-based games, for example, or to createenterprise applications which receive alert-based data such as financialor field sales information, and integrate that information directly with anapplication.Over-the-Air ProvisioningAlthough MIDP 1.0 did not officially encapsulate an over-the-air provisioning (OTA) definition, it did recommend a practice that was adopted asan addendum to the original specification and has now been made a partof the MIDP 2.0 specification.
This means that deployment and updating16INTRODUCTION TO J2MEof applications over-the-air now falls within the MIDP specification. It hastherefore been standardized and defines how applications are discovered,installed and removed on MIDP devices.
The most useful consequenceof this is that status reports can now be produced. This greatly enhancesthe revenue model for MIDP applications because applications can betracked as they are installed, updated or removed.Persistent StorageMIDP also implements a simple record-based database managementsystem. The data will remain present across multiple invocations of aMIDlet. The platform is responsible for making its best effort to maintainthe integrity of the data throughout normal use of the device, includingrebooting and battery changes. However, when the associated MIDletsuite is removed, so are the record stores. MIDP 2.0 now allows explicitsharing of data across MIDlet suites, assuming the serving data store hasgiven permission for this sharing.End-to-End SecurityWith greater network connectivity and the nature of common applicationinstallation methods, a robust security model has been specified.
HTTPSleverages existing standards such SSL and WTLS and enables the transmission of encrypted data. Security domains are used to identify trustedand untrusted MIDlets. By default, all applications are untrusted and areprevented from accessing any privileged functionality. Access can begained by signing the MIDlet to specific domains defined on the deviceusing the X.509 PKI standard.This allows mobile phone operators and manufacturers to improvethe user experience by limiting the capabilities of unknown applications.Developers see application credibility and user confidence increased byhaving their applications reviewed, and deemed trusted, by operatorsor manufacturers in order to access advanced capabilities.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
