Lessons from a life of startups, coding, countryside, and kids
According to Tom Park, MIDP applications need scripting languages. I can see the advantages of being able to rapidly update a midlet but I not sure if downloading an updated script to a mobile can/will allow this. MIDP won’t allow you to download and update individual classes so updating a script sounds like a good idea. But there are problems (as always?)…
First, it is unlikely that a scripting language will form the majority of your MIDlet code. A scripting language interpreted in Java will be even slower than the Java bytecode being interpreted by the JVM - mmm, double interpretation doesn’t sound like a performance winner. So more likely, is that you will tie together the core Java classes with a script. Of course, this makes it difficult to fix bugs by updating the script since the bugs probably lie within the core Java classes. However, I can imagine using a script to control the user interface by manipulating the core screens and objects as this would allow a new script to rapidly add new functionality to your MIDlet.
The other problem is where is the script stored? It can’t be stored within the Midlet archive since it cannot then be updated. Probably the best strategy is to ship a script inside the MIDlet and on first execution copy this script into a RecordStore. This script can then be executed by reading it from the RMS and updated by downloading a replacement (via, HTTP) and replacing the database entry. Sounds cool enough?
Of course, the other problem is that creating your own MIDP language takes time, effort and quite a bit of knowledge which isn’t relevant to the application your trying to create. To date, the only MIDP scripting language available is SimKin. Definately worth a look but I think some serious performance testing would be required before you commit yourself.