Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 60
Текст из файла (страница 60)
The developer has little control over look and feel, so the UIretains the look and feel of native applications.One exception within the high-level API is CustomItem, a component that allows developers to define their own Form object. Althoughit is a high-level component derived from Item, it behaves more like aCanvas. Whereas the other high-level Form objects let the implementation manage user interaction and object traversal, the class extending theabstract CustomItem class is responsible for implementing this behavior.The Sony Ericsson P900 and the Nokia 6600 implement CustomItemdifferently, reflecting the different user interaction paradigms of thetwo phones. It is possible to extend CustomItem by redefining thekeyPressed(), keyReleased(), and keyRepeated() methods forthe Nokia 6600 and the pointerPressed(), pointerDragged(),and pointerReleased() methods for the Sony Ericsson P900.
Inthis way the extended CustomItem should behave correctly on bothplatforms.330MAKING JAVA CODE PORTABLE6.3.4 Adapting to Proprietary and Optional APIsMIDP 2.0 has evolved to its current state with the co-operation ofmany interest groups such as device manufacturers, network operators,and operating system developers including Symbian. In some cases, inorder to facilitate the next generation and sometimes in anticipation offorthcoming technology, devices are released with proprietary APIs whichprovide developers with the ability to create more complex applicationsusing APIs which have not yet (or may never) be standardized.
Forexample, Nokia created a proprietary API for broadcasting SMS messagesand a proprietary UI API gave game developers for Nokia MIDP 1.0devices control of a full-screen canvas. In both cases this functionalityhas since been incorporated into the standards. JSR 120 supports SMSand MIDP 2.0 provides Canvas.setFullScreenMode(). In thesecircumstances, the Nokia UI API is deprecated, although implementationsstill ensure backward compatibility.Developers should be aware of the capabilities of the target devicebefore assuming that all the classes they have used are standard.
Codeshould be written defensively so that when an API is not available theMIDlet will still run, while taking an appropriate action, and not just closethe application unexpectedly. It would be even better for the developerto be aware of the device’s libraries and perhaps make positive decisionsabout the functionality of an application prior to release on a new device.This, however, leaves developers with a quandary. Do they only targetparticular devices and operators that suit their needs, or do they try tocode around the limitations of devices to achieve the same result? Wouldit be possible, for example, to change the screen layout or menu order toreflect a smaller screen size?Another area where devices differ in capability is their multimediasupport.
For example, the MIDP 2.0 Media API (discussed in Chapter 3)provides limited capabilities as a lowest common denominator. Wheredevices have good native multimedia functionality, such as onboardcameras and microphones, developers would reasonably expect to beable to manipulate the media data. However, at present only some ofthe more powerful phones, such as the Nokia 3650 and Nokia 6600,implement the fully-featured Mobile Media API (JSR 135), which enablesrendering and recording of media data, such as audio and video playbackand photo capture.
This API enables an application such as the PicturePuzzle MIDlet discussed in Chapter 5 to capture an image from itsonboard camera, manipulate it and store it for future use. However, thereach of the application is obviously limited to those devices that supportthe MMAPI and implement the photo capture functionality (optionalunder JSR 135).Fragmentation in the CLDC/MIDP API space is widely acknowledged as a serious issue. The Java Technology for the Wireless Industry(JTWI) expert group was created to address this problem (http://jcp.org).PORTABILITY ISSUES331Chapter 3 introduced the JTWI and concentrated on the component JSRsthat make up Release 1 of the JTWI roadmap.
One of the goals of the JTWIis to provide a lowest common denominator set of APIs and functionalitythat compliant devices must implement. By targeting their applicationsat the JTWI platform, developers can be confident that these applicationswill run on the widest possible range of devices. JTWI also specifiescertain minimum requirements both in terms of performance and theimplementation of optional functionality within a specific componentJSR. This is discussed in more detail in Chapter 3, but here are a fewpertinent examples:• devices should allow JAR files up to 64 KB, with a JAD file of 5 KBand 30 KB of persistent storage• for graphics, it adds JPEG format files to the PNG support, providinggreater flexibility• a minimum screen size of 125 × 125 pixels with 12 bits of color depthshould be adopted• devices on GSM/UMTS networks must support SMS push, whichworks with the push registry to awaken MIDlets upon receipt of anSMS message.Symbian was a member of the JSR 185 expert group and Symbian’sJava implementation is JTWI-compliant from Symbian OS Version 8.0.The ratification of Release 1 of the JTWI postdates MIDP 2.0, but thevast majority of MIDP 2.0 devices are expected to conform to the JTWIinitiative in the future.6.3.5Download LimitationsSymbian OS devices such as the Nokia 6600 and the Sony EricssonP900 do not specify limitations on the maximum MIDlet JAR file size;rather, the JAR size is limited by the available persistent storage theyhave on the device.
Typically, Symbian OS devices start with 16 MB, butafter the operating system and applications have been added they havearound 8 MB. Some devices have memory sticks and MMC cards, so thisdoes, of course, vary. Other considerations include limitations imposedby operators on WAP gateway downloads.
An application that is toolarge will not sell, as no one can download it! Obfuscation (discussed inChapter 7) provides one way to reduce JAR file size.Looking further across the market, developers should be aware thatsome devices impose a maximum download limit. Nokia Series 40devices have a maximum 64 KB limit, while the Sony Ericsson T610allows a JAR file size of 60 KB. This gives an idea of where final JAR filesizes should be pitched for the best portability.332MAKING JAVA CODE PORTABLEThe size is, of course, governed by what is inside the file, so it’s worthconsidering exactly what we include.
Do sound files really need to beadded? For example, the new target device may not be capable of playingcertain sounds, or it may not be capable of rendering certain images. Toport to a different device we may be able to leave out these extras. Playinga sound on a device with a lower specification may have unwanted sideeffects on the speed of the MIDlet and the device memory.It may be that a smaller JAR file size means a smaller game world.Maybe we should consider cutting back on the number of levels for theuser to play?Obfuscation, as well as scrambling the code from prying eyes, has theside effect of reducing the final JAR file size and can improve efficiency,particularly with older VMs.
Some obfuscators are more efficient and canreduce the JAR file more dramatically than others, so shop around and tryout different ones (Chapter 7 looks briefly at two that are supplied withSun ONE Studio, Mobile Edition).6.3.6 Heap MemoryThe developer needs to be aware of heap memory, especially whenporting to a different device.
The heap memory holds all the runtimecode, graphics and other objects associated with the MIDlet. Failureto keep within the limits will cause an OutOfMemory error and theMIDlet will cease to execute. Too many graphics in a MIDlet maymean not enough heap is left to execute the code. For example, a tiledbackground needs to be optimized in terms of off-screen buffer for thedevice in question.Symbian OS devices typically do not specify a limit on heap memory,leaving the developer with a lot of room to play with. Both the Nokia6600 and the Sony Ericsson P900/P908 allow for expandable memoryup to an 8 MB heap.
Of course, the phone’s other applications also sharethat memory space and the application management software may take adifferent view of what can and cannot be run at any one time. Developerscan adopt certain strategies to minimize memory usage. Flyweight designpatterns, object factories and object recycling minimize the number ofobjects in memory at any one time and ensure memory is freed by theapplication when objects are no longer used, rather than relying on thegarbage collector to manage memory.Porting MIDlets to smaller or different devices may present a differentset of challenges. These devices may set a much lower limit on heapmemory and developers should be aware of this.
An important point toremember here is that the size of the graphics files used to create theapplication images has a direct impact on the amount of heap used atruntime. A compromise in graphical content may be needed to reducethe overall memory consumption, for instance, by reducing the qualityand detail within sprite graphics.SUMMARY333In addition, lower heap memory may cause the garbage collector tokick in more frequently, adversely affecting the overall performance ofthe MIDlet.6.4 SummaryIn this chapter we have reviewed the techniques and models you shouldemploy to maximize revenue generation by creating flexible and portableapplications for mobile devices.
We have looked at some of the designpatterns you may choose to use and the porting issues you face whenwriting MIDP 2.0 code. You need to consider the user interface and, inparticular, graphical content. We have also looked at some issues arisingfrom using the low-level APIs in game development.In Chapter 7 we will investigate another important issue in developing applications for constrained devices: optimizing code for theJ2ME platform.7Writing Optimized Code7.1 IntroductionThis chapter looks at how wireless Java MIDlet developers can getthe most from their applications. Optimization is always important, butespecially so on mobile phones and other constrained devices such asPDAs. We shall address both improving performance and minimizingmemory requirements.In this chapter we try to help you develop high quality Java applicationsfor Symbian OS.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
