J2ME Tips, Tricks, & Best Practices

1. J2ME Tips, Tricks, & Best Practices

2. Who is Sue? • President of Switchback Software LLC • 18+ years hands-on enterprise and mobile application development experience • Author, technology columnist, magazine contributor, JSP 2.1 EG member

3. Objective Provide some experience sharing of things that you want to do and things you don’t want to do when dealing with mobile devices.

4. Content • Development tactics • MIDlet programming • Designing UI • XML Parsing • Optimizing

5. Development Tactics

6. J2ME – The Real Questions • Ask yourself these 3 questions each time you write a method: • How can I reduce it? • How can I reuse it? • How can I eliminate it?

7. Main Areas of Size • The code size of the MIDlet for device loading • Runtime size • Runtime behavior – use of processor usage

8. Development Tactics Tips • JAR > 50K might not load • Tradeoffs must be made • Don’t over-abstract • Interfaces, classes should be scrutinized • Consider cost of fine-grained methods • Be careful when using String • Immutable, causes more garbage collection, slower performance • Pay attention to Heap • Reuse and pool objects when possible • All I/O is very slow • Threading when appropriate

9. MIDlet Programming Tips

10. MIDLet Programming Tips • Use Scalar types where ever possible instead of Java Objects • Release resources early: Network Connections, RecordStores, Resource Streams • Be aware of the Garbage Collector • Setting unused objects to null • Use Exceptions only when needed, as each Exception throws an Exception object • Lazy Instantiation

11. More Tips • Use Local Variables • It is generally faster to access local variable than class members. • Wherever possible, you can assign a class member to a temporary local variable and use it for repeated use. • Avoid String Concatenations. Use StringBufferinstead.

12. MIDLet Suites • Keep MIDlets simple. • If you’re application is complex, delivery it as separate MIDlets in a single suite. • MIDlet to MIDlet communication via the RecordStore vs. large MIDlet using lots of global variables • When loading a single MIDLet, it will only load the classes that it needs vs. loading classes that only used by a portion of a larger MIDlet

13. Designing UI

14. Designing Tips for UI’s • Make it usable on all devices • Try and use Abstraction over Discovery techniques • Keep target in mind • Alphabetic input difficult • Use lists or buttons • Small screen • Not all devices have pointing device • Be consistent with key use • Use either Displays or Forms

15. CommandListener Design • In simple applications, the MIDlet can be the CommandListener • However, the object-oriented way is to create a CommandListener for each Displayable • Each If body statement should be as short as possible making a call to a support or utility routine, whenever possible • Utilities routines are shared among all CommandListeners

16. XML Parsing

17. XML Parsing • Different options • Consider doing parsing on the Server instead of client • Use XSLT on server to compress<Choice name="Apples"/> to <C n="Apples/> • Introduce persistence on the server • Reduce message sizes • Supporting multiple clients

18. Message Formatting • Different mechanisms available for doing message formatting • kXML-RPC is very easy to use and fast • kSOAP is another alternative • Let’s look at the difference between XML-RPC vs. SOAP

19. XML-RPC vs. SOAP* • SOAP is asynchronous, XML-RPC is not • SOAP supports request routing and pre-processing of requests via SOAP headers • XML-RPC is lighter, taking up less bandwidth, and requiring less processing power • SOAP is namespace-aware (in fact every element must be namespace-qualified) • SOAP has a heavy-weight, robust data typing mechanism based on XML Schemas • XML-RPC is easily sent and consumed, and is easily readable by humans • SOAP messages have a considerable amount of packaging contained in the envelope, but this allows for flexibility in the messaging paradigm used (publish-subscribe, point-to-point, etc.) *Source: kXML-RPC FAQ

20. When to use kXML-RPC* • Speed is of greater importance than flexibility • Memory usage is a critical factor • Program size must be very small ( < 8kb ) • The data being exchanged is simple, or at very least the relationships between the data are simple • You need a neutral, standardized, lightweight mechanism for exchanging data, or remotely invoking some network service *Source: kXML-RPC FAQ

21. When to use kSOAP* • Flexibility and a robust feature-set are a high priority • Program size and memory usage are less important than advanced networking features • The data being exchanged is complicated, the relationships between the data are complicated, or is it important to define custom data types • If you are uncertain which protocol will be used by potential clients and partners (SOAP is more popular, and thus a better bet in an uncertain situation) *Source: kXML-RPC FAQ

22. Over the Wire consideration • Don’t poll! • Message formats • HTTP conditional GET to avoid unnecessary traffic • SMS, take advantage of push • Security • Encryption and using HTTPS comes at a performance price • Support off-line work as much as possible • Take advantage of data synchronization, on-device persistent storage (RMS) • Reduce network round-tripping

23. Optimizing

24. Battery considerations • Try not to busy-wait. • Most devices will go into sleep mode anyway… • Keep aware if there are APIs that are battery intensive (e.g. NMEA, backlighting, etc.)

25. Using Arrays • Arrays are faster and leaner than the Collection Objects • Vector is just a wrapper for Array anyway… • For MIDlets, if you do decide to use Vectors and HashTables, try to size them correctly • Both Vector and HashTable grow as needed • Default is 100, which is usually way more than you need • Vector creates an internal array and copies elements from the old to the new Array • HashTable performs computationally intensive rehashing

26. Data Access Strategies • For every row type, create a utility to encapsulate and isolate the complexity of record management. • Have a single place that reads and a single place that writes • Order and type are critical because the data is stored in a ByteArray

27. Optimizing Resources • Try and reuse Object as much as possible • Reusing existing instances • Avoid allocations when possible • Reduces memory usage • Produces less garbage when the GC runs • Possibly create a cache • Utilize whatever optimization tool you’re working with: Jbuilder OptimizeIt, WTK 2.0 Profiler, Motorola SDK

28. Threading • Whenever doing any task that is longer that X amount of time, execute it in a separate thread • The main thread primary responsibility is to handle hardware interaction and event management • If you lock your main thread up with something slow (like I/O, networking) your application appears to lock up. • Make use of thread priority

29. Optimize Deployment • Make the JAR as small as possible • Eliminate classes that you aren’t using • Don’t do an import com.myclasses.* • Try and partition classes functionally efficient. • That way when the class is loaded, everything in it will be used and not waste memory.

30. Use an Obfuscator • Use an Obfuscator to reduce the size of class files • Adds an extra element of security, by making class files hard to de-compile • Include an obfuscator task in the build.xml and try to make use of such tools as Proguard • Some Obfuscators allow for pruning of class which is good for reducing package sizes Caution: Don’t turn the Obfuscator on right before you are shipping a product! Make sure that you’ve tested with it because there are sometimes unexpected errrors…

31. Benchmarking • Get into the habit of measuring memory usage • Do it as part of the development process • Use: Runtime. getRuntime().totalMemory() andRuntime. getRuntime().freeMemory() • Can also measure the speed of the MIDlet usingSystem. currentTimeMillis() • Visit www.jbenchmark.com. This is a cool site for seeing how devices execution speeds compare and you can get an idea of how your MIDlet might run

32. Going Small – Bigger is Not Better • Use shorter names to reduce class file byte code or let the Obfuscator do it • Class/member renaming, prune unused classes & methods • Data caching when using RMS • Conditional compilations • If (Debug.ON) println(…) • Optimize: estimate size of Hashtables and Vectors upon construction

33. When Things Go Wrong • MIDlet works in emulator, but not on phone. Some things to check for: • Check to make sure the JAR size is correct in the JAD • Some devices (like Motorola) seem to require a 3 digit version 1.0.0. 1.0 might work in the emulator, but not on the device. • Make sure that emulator settings closely reflect performance metrics on the phone • Possible need to contact phone vendor to get suggestions • For example, i730 default setting in the SDK are very similar to the actual phone except for intensive GUI rendering • Play with different setting for things like network latency

34. Optimization tools • Provided in the WTK • Memory monitor – for device activity • Profiler – for code coverage • Network monitor – see what is in the packets • Others might be available depending on what your IDE might have.

35. Wrap Up • There are lots of small (no pun intended) details to pay attention too. • Code, tools, and techniques can make a difference between having an app that runs and having one that runs away.