XML on a mobile phone

Java on Mobile Devices J2ME
#1

I have just bought the new Sony Ericsson K700 and is quite impressed with it. The JavaVM is really fast and stable so the following is probably quite feasible but the question is whether it is a good idea.

I wrote an XML parser (see http://vredungmand.dk/programming/sjg_xml/) a while back that I use to parse configuration files in my applet games. The configuration files are more or less the backbone of my framework (see http://vredungmand.dk/programming/sjg/) and I get a really nice and flexible architecture from it.

The question is: Should I port the XML parser and use a similar scheme on J2ME? I can see the following alternatives:

  1. Port the XML parser and let it work similar to the applet framework.
  2. Write a step in the build process that convert the XML files into something that can be read faster (a binary data file).
  3. Do configuration in the Java code. (I.e. mazes.add(“maze1”, “…x…x…xxxx…”); ) possible generated by a build step.

I would like to program games for slightly less capable phones as well.

Any advice? Do you guys always sacrifice good architecture/design for speed when it comes to J2ME?

#2

[quote]Any advice? Do you guys always sacrifice good architecture/design for speed when it comes to J2ME?
[/quote]
Short answer:
[i][u]YES![/i][/u]

Long answer:
Depends on how many devices you want to support, and how large your game is. But basically you’ll want to avoid classes, accessor methods and so forth - make fields public instead of set/get and avoid anonymous classes (typically threads). You need to optimize graphics and the resulting jar file too - oh and get proguard, can’t live without it.

Doing a basic shootemup or puzzle you could probably squeeze in an xml parser (of which there are many others). However, I would not recommend it. Depending on the dynamic nature of the game you want, you should try to preprocess the configuration into the game at compile time.

#3

Short answer:

OH NO

I ported everything yesterday. The XML parser, the scripting engine and the decoupled-GOF-state-design-pattern-based-game-loop-screen thingee. Setters, getters, inner classes, threads? You bet. It is actually working but I think I will move the XML parsing to compile time as you suggest.

My target platform is the newest Nokia and S/E phones with minimum 128x128 screens. Basically I plan to take my full collection of applet games and port it to J2ME. Then sell them to the chinese and make a million dollars.

#4

In short, I will code as usual and then optimise later.

#5

As I said, it all depends on what you actually have of code resources.
Sure if you’re doing “simple” games you could possibly store it all in the 64kB limit (Nokia, S40) - however for larger games this really becomes an issue!
The stuff I currently work on is a Multiplayer gaming platform with lobby support (private/public chat, ignore invitations etc.) and multiplayer games (including back end server). And let’s just say that the amount of work done to cram this into 64kB jar (and 200 kB heap) is not insignificant. Using ~10k for config parsing is not an option for these situations.

#6

[quote]In short, I will code as usual and then optimise later.
[/quote]
Aye, but do get accustomed with a refactoring tool :wink:

#7

java.lang.OutOfMemoryError … hmmm …

#8

The problem is not really the extra code. The parser is document based rather than a SAX parser. This means that the structure of the XML document is mimicked by an object graph, at least tripling the memory needed (the data file, the XML object graph and the actual objects (sprites, mazes, frames whatever)).

Anyway I got the applet Taleban vs. Robot (game: http://vredungmand.dk/games/taleban/ design doc.: http://vredungmand.dk/programming/sjg/taleban/) ported with the exact same design as the applet version. It runs perfectly but I can tell that I am definately pushing this little poor thing with XML stuff.

The jar size is 60 KB. I will move the parsing to compile time tomorrow. I am really happy that J2ME phones today are so good that you can actually do this sort of thing.

http://bentzonsvej.dk/photos/k700-2.jpg

(Yeah - it was such a big moment that I had to take a photo of it.)

#9

The real issue with phones these days is that though you can do 90% of what you want properly - you’ll also be spending 90% of your time pulling hair out because of some crappy j2me implementation. I have yet to meet a phone without somekind of weird issue - some worse than others :confused:
Whats really great is that if you can choose to only support x number of phones - alas, you’ll probably need to be a corporate troll for that to be possible.