Artikel getaggt mit pattern

J2ME Pattern: ActiveRecord

Though J2ME forces you to be close with adding classes, type-safe & convenient persistence might be something you don’t want to miss.

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.

Tags: , ,

J2ME Pattern: RMS Migrations

Inspired by RoR Migrations I’ll summarize how to gain similar benefits in the J2ME world with respect to it’s special needs:

  • 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.

Tags: , ,