And as RecordStores are the primary application persistence stores, there’s some boilerplate code you can refactor out into one single common base class.

Also – especially from a pattern standpoint – it’s a must and increases the unterstandability and maintainability of your code.

So what’s the design assumptions and decisions?

1. multiple RecordStores can be kept open at least as long as an application is active. So open them in startApp() and close them in pauseApp() and destroyApp(),
2. use the ActiveRecord pattern rather than ValueBean/DAO to keep the number of classes small,
3. never access RecordStores directly but shield them with ActiveRecords,
4. keep track of the ActiveRecord instances and update them via RecordListeners,
5. provide getBytes/setBytes instance methods to the ActiveRecords,
6. maybe make ActiveRecords even RecordListener Singletons and refill the data on usage,
7. maybe even use a single Hashtables subclass as ActiveRecords to even save more classes (requires very disciplined unit testing!),
8. create few multi-purpose RecordFilter and RecordComparator subclasses per RecordStore,

Check back later for sample code.

Or just don’t code persistence manually but use the floggy J2ME persistence framework. Looks interesting, but I didn’t try it out yet.

• attach a version marker to each RecordStore name,
• as there’s no callback at install time and at launch time things must be quick as possible, use a fall-back mechanism on opening RecordStores,
• therefore use a custom method to open RecordStores and give it a handler for RecordStoreNotFoundException,
• use methods rather than classes to implement migrations,
• only migrate forward,
• hardcode the migration methods into the RecordStoreNotFoundException handler – there’s no Reflection in J2ME.

=>

• you can change the RMS store names and storage byte semantics whenever you like without the fear of breaking anything,
• there’s impact on startup time only if the storage semantics changed and needs to be converted,
• you don’t add myriads of classes over time,
• you need to write a converter method for each version bump of each store.

Check back later for sample code.

Use the archetype like this:

$ mvn archetype:create -DarchetypeGroupId=com.pyx4me
-DarchetypeArtifactId=j2me-simple -DarchetypeVersion=2.0.3-SNAPSHOT
-DremoteRepositories=http://www.pyx4me.com/maven2 -DgroupId=org.example
-DartifactId=myapp

And if you develop against a nokia phone, it comes even better – there’s a gammu maven plugin, too!

Also check out this blog featuring maven2 & j2me.

Check your phone at mobile-utopia.

Running with storage root DefaultColorPhone
Warning: Failed to initialize WMA message routing support
Error: Can't remove a lock file: /opt/sun-j2me-bin-2.2/wtklib/comcon-server.port.lock
Warning: Failed to initialize Bluetooth (JSR 82) support
...
Warning: The attempt to finalize unexisting client.
java.lang.NullPointerException
at com.sun.kvem.midp.MIDP.run(Unknown Source)
at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown Source)
at com.sun.kvem.environment.EmulatorInvoker.runEmulatorSameVM(Unknown Source)
at com.sun.kvem.environment.EmulatorInvoker.runEmulator(Unknown Source)
at com.sun.kvem.environment.ProfileEnvironment$KVMThread.runEmulator(Unknown Source)
at com.sun.kvem.environment.ProfileEnvironment$KVMThread.run(Unknown Source)

give write permission to the wtklib folder inside the WTK:

$ sudo chmod o+w /opt/sun-j2me-bin-2.2/wtklib

The following disease

...
javax.microedition.rms.RecordStoreException: error opening record store file
at javax.microedition.rms.RecordStore.<init>(+428)
at javax.microedition.rms.RecordStore.openRecordStore(+109)
at name.mro.billard.Stats.findPlayers(+6)
at name.mro.billard.Stats.startApp(+4)
at javax.microedition.midlet.MIDletProxy.startApp(+7)
at com.sun.midp.midlet.Scheduler.schedule(+270)
at com.sun.midp.main.Main.runLocalClass(+28)
at com.sun.midp.main.Main.main(+116)
startApp threw an Exception
...

is cured by

$ sudo chmod o+w -R /opt/sun-j2me-bin-2.2/appdb

A Sun Forum Post provided the correct hint.

Ich habe also das “DefaultColorPhone” unter Beibehaltung des Namens (sic!) geklont (duplicate):

J2ME Device Management

und wie folgt eingestellt:

Edit DefaultColorPhone Definition

Anschließend läßt sich per “Eclipse > File > New > Project > J2ME > Midlet Suite” ein neues Projekt anlegen.

Vorsicht, daß auch wirklich das richtige DefaultColorPhone mit den richtigen CLDC und MIDP jars zugeordnet ist:

Package Explorer Ansicht

Und schon kann’s losgehen!

Evtl. sind die (nicht markierten) anderen jars noch nicht korrekt, aber Rom wurde auch nicht an einem Tag erbaut, oder?

1. JDK:

   $ sudo emerge dev-java/sun-jdk

2. Eclipse 3.4 herunterladen und auspacken,
3. J2ME Wireless Toolkit 2.2:

   $ sudo su -
   $ echo "dev-java/sun-j2me-bin ~amd64" >> /etc/portage/package.keywords
   $ echo "dev-java/sun-j2me-bin examples" >> /etc/portage/package.use
   $ emerge dev-java/sun-j2me-bin
   $ # USE-Flag "j2me" setzen, z.B. via "$ sudo ufed"
   $ sudo emerge proguard

4. J2ME Wireless Toolkit 2.5.2 heruterladen und installieren,
5. EclipseMe herunterladen und auspacken.