Random-access data object in J2ME

Question

Hello,

I'm planning to develop a small J2ME utility for viewing local public transport schedules using a mobile phone. The data part for those is mostly a big bunch of numbers representing the times when the buses arrive or leave.

What I'm trying to figure out is what is the best way to store that data. The representation needs to

1. be considerably small (because of persistent storage limitations of a mobile phone)
2. fit into a single file (for the ease of updating the schedule database afterwards over HTTP) fit into a constant number of files, i.e. (routes.dat, times.dat, ..., agencies.dat), and not (schedule_111.dat, schedule_112.dat, ...)
3. have a random access ability (unserializing the whole data object into memory would be just too much for a mobile phone :))
4. if there's some library for accessing that data format, a Java implementation should be present

In other words, if you had to squeeze a big part of GTFS-like data into a mobile device, how would you do that? :)

Google Protocol Buffers seemed like a good candidate for defining data but it didn't have random access.

What would you suggest?

Thanks in advance.

--

Linas

Answer 1

I made app like this and I used xml-s generated with php. This enabled us to have a single provider for 3 presentation layers which were:

• j2me app
• website for mobile phones
• usual website

We used xslt to convert xml to html on websites and kXML - very light pull parser to do it on j2me app. This worked well even on very old phones with b/w screens and small amounts of memory.

Besides on j2me there is no concept of file. You have the db in which you can store information. This is a link to "mobile" website. http://mobi.krakow.pl/rozklady/

and here to the app: http://www.mobi.krakow.pl/rozklady/j2me/rjk.jar

This is in polish, but I think it's not hard to figure out what's this and that.

If you want, I can provide you with more help and advice or if this is a commercial product then I think we can figure out something too ;)

Answer 2

I think your issue is requirement 2.

Updating 10MB of data just because 4 digits changed somewhere in the middle of the file seems highly inefficient.

Spliting the data into several files allows for a better update granularity that will be well worth the added code complexity.

Real-time public transport schedules are usually modified one bus/train/tram line at a time.

Answer 3

Persistent storage on J2ME is a tricky business; see this related question for more general background: Best practice for storing large amounts of data with J2ME

In my experience, J2ME persistent storage tends to work best/most reliably with many small records rather than a few monolithic ones. Think about how the program is going to want to access the data, then try to store it in those increments in the J2ME persistent store.

I'd generally recommend decoupling your client-server protocol for downloading updates from the on-device storage format. You can change the latter with every code update, but you're pretty much stuck supporting a client-server protocol forever, unless you want to break older clients out in the field.

Finally, I know there are some people on the Transit Developers group who have built offline transit apps in J2ME, so it's worth asking for tips there.