[General Topics] Menneisyys:
3.4 Runtime issues: concurrent (parallel) and background execution

The KVM’s slightly differ in how they handle concurrent execution of MIDlets – or, simply running something in the background. Some (TAO and J9) allow for the concurrent execution of MIDlets, while the rest don’t. This means the, otherwise, excellent Esmertec KVM’s will only run one MIDlet at a time, while the certainly, in most respects, inferior J9 and TAO Intent will run any number of them. TAO, in addition, also supports the in-environment switch between running MIDlets, unlike J9.

Support for parallel MIDlet execution can be very useful; for example, the Gmail MIDlet could continuously check Gmail for incoming messages, while, in another MIDlet, you could browse the Web. You can find some other uses for example HERE, in the comment section (the comments HERE are also pretty instructive and shed light on related issues).

The ability to execute a MIDlet in the background is also very important. Just an example: you start downloading a Web page in Opera Mini but quickly realize the download will take ages. In order to save time and do something useful in the meantime, you decide to minimize the Opera Mini task, do something else in another program and only return later, expecting Opera Mini has already finished downloading and rendering. All the tested WM and Symbian KVM’s support this kind of operation; the only exception is Jblend, which immediately pauses when it loses the focus. Incidentally, Jblend’s behavior also has some other consequences; for example, in no way can you use external character injectors to it (unless they’re continuously running and, therefore, don’t result in executing a new process; PQzII is one of these) and you will even have problems uploading Jbenchmark results to the server (because it constantly thinks the MIDlet has been paused and prompts you for resuming).

I also recommend Solnyshok’s excellent article for more information on the advantages of parallel execution of some MIDlets. Also note that the article contains an excellent hacking tutorial on how multiple instances of the same MIDlet can be executed at the same time.

4. The main chart

Again, this is where you’ll find most information. It contains an order of magnitude more information than the article you’re just reading in a well-condensed, tabular, easy-to-compare form, packed with tons of screenshots helping in finding out how a given feature should be enabled / used.

I’ve already elaborated on several (for example, security-related) of the rows this chart has; now, let me elaborate on the rest.

In the “Price / availability” row, as has already been stated, you’ll find where to get / download the given KVM from.

In the “Platform compatibility” group, I’ve listed three rows: compatibility with non-phone Pocket PC’s, Pocket PC Phone Edition devices and, finally, touchscreen-less Smartphones (abbreviated as SP’s).

As has already been pointed out, you MUST apply the SMS/Phone DLL hack explained in the Jeodek column if you have a phone-less, “classic” Pocket PC. Also, if you have a MS Smartphone (as opposed to Pocket PC’s), pay special attention to the compatibility remarks here as, unfortunately, not all titles are Smartphone-compliant or, if they are, you may encounter some problems when trying to run them.

The “Generic compliance with standards” group is more for techies: people that would like to know everything about the standards support of the given KVM. As can clearly be seen, the Nokia N95 KVM blows all the other KVM’s out of the water (in this respect too); this is particularly true of, under Windows Mobile, never (except for some very old and long-discontinued IBM J9-specific add-on projects I’ve elaborated on HERE) implemented, for, for example, multiplayer gaming (give a try to the MIDlet version of 3D Constructo Combat in multiplayer mode on even slower / older Nokias like the 6680 – you’ll LOVE it! The same stands for for example the infamous Naval Battle: Mission Commander) Bluetooth support. The same stands for other goodies like support for camera: all WM KVM’s lack the support for it, as can clearly be seen in the “MMAPI Video-capture” cell of the “JVM Multimedia (JSR 135)” row. It could be VERY useful; see for example the posts HERE, seeking for support for barcode reader applications. Audio capture (which isn’t really supported by many apps either) is also pretty useful; see for example the TellMe MIDlet for a real-world usage example. Yeah, you can clearly see MIDlets are in no way for gaming only – there have a LOT of enterprise uses and are particularly useful when you have a lot of different platforms you need to quickly develop a business solution for!

In the “JVM Memory” row, I’ve listed the appropriate heap (free memory) size available for each KVM. The more, the better for running memory-hungry MIDlets – unless the given KVM uses dynamic (de)allocation of memory when the need arises. Then, it’ll be able to run even the most memory-hungry MIDlets (for example, a full JBenchmark category, in High Quality, packed into one JAR). Unfortunately, only Nokia’s KVM and Jbed support the latter. Also note that you can set the memory allocated for Jblend in the Registry.

Support for “JVM M3G”, that is, the Mobile 3D Graphics API is the dream of most Java MIDlet gamers. As can be seen, several KVM’s support it. (Speed, without hardware acceleration, is another question.)

The “JVM File Connection” group is also very important, particularly with applications like Opera Mini Mod, the unofficial (and, unfortunately, illegal; therefore, I cannot provide a link to it either) “hack” of Opera Mini, adding a lot of goodies like (pretty rude, but still working) page saving and IEM favorite import / export. These all require access to the file system, which, unlike with real Java, isn’t built-in or required by the basic standard. This is why so few WM KVM’s support it: IBM J9 with an additional hack (I’ve elaborated on the installation in the chart) and Jbed. Interestingly, some real-world tests were failed by Jbed, while IBM J9 passed all of them. The support for accessing the local file system is certainly a big plus with IBM J9 – one of the very few advantages of the environment, along with, for example, the ability to run several MIDlets at the same time.

The “Storage usage” group is very important because internal storage memory is doomed to fill up very quickly (especially with low-end WM devices only having 64M of Flash ROM – an example is the HTC s310/Oxygen WM5 Smartphone), particularly if you install sizable games (current games are 300-600 kbytes in size). In this group, I’ve explained the following:

Where can a given MIDlet manager KVM be installed to – that is, can it be installed to a storage card? All of them can (note that we’re, mostly, dealing with XDA-Dev-created installers and hacks in here!), except for Jbed, which MAY require some additional manual file copying (also explained in the chart).

Where the deployed MIDlets are kept: This is also highly important. Fortunately, it’s only IBM J9 that is doomed to store the deployed MIDlets in the internal storage (I’ve tried to hack it to a card very hard – see my related article – but in vain); other MIDlet managers, when installed to a storage card, don’t. Note that, should Jblend and TAO be an OEM-installed KVM on your handset, you can still easily “hack” them to store their MIDlets on a storage card with a simple Registry edit.