Question

How it currently is:

I’m making a small application for Java-enabled phones (MIDlet-based “dumb-phones”, not Android). The application is structured like this:

1. “Infrastructure”, with core functionality
2. Modules of type A (classes implementing interface ModuleA)
3. Modules of type B (classes implementing interface ModuleB)

Modules of type A and B are basically classes which get instantiated in the Infrastructure based on what the user chooses from a list, and they do stuff in their own specific way. Think “Strategy pattern”. When the user is using the application, she explores the screens provided by the Infrastructure, then comes to a list of Modules of type A (sees their titles). Then she picks one of the modules, which gets instantiated and does something for the her.

What I’m wishing for

I was wondering if it’s possible (and if yes, how) to package the entire Infrastructure in a JAR file, but keep Modules of type A and Modules of type B in other JAR files, which can be installed on the device in the future (like add-ons for the Infrastructure). I’m thinking of this scenario:

1. User installs the Infrastructure
2. User installs the “Starter” add-on, which is available at the same time as the Infrastructure
3. Weeks later, a new add-on is created by the developer, like “Special Christmas Modules”, which the user could install, so the Infrastructure, already installed on her device, will list the Modules in the add-on
4. One year later, another add-on is published, containing modules with other features and ideas

First, can such add-ons be installed on a mobile device? Do they have to contain a MIDlet class (doing nothing or notifying the Infrastructure)? Could the Infrastructure detect those JARs that contain add-ons for my application? Or could the Infrastructure interact with the classes packed in other JARs?

Note: only the Infrastructure JAR would contain a useful MIDlet class. Also, add-ons would contain any combination of Modules of type A and Modules of type B.

Possible solution? (incomplete, though)

Maybe the add-ons can look, act and smell like a MIDlet application for the device itself, so they can be installed as any normal MIDlet application. The add-ons could declare themselves as part of the same suite as the Infrastructure, so they can notify their presence to the Infrastructure by writing to its Record Storage (I understand that there’s a Record Storage per MIDlet suite). The Infrastructure reads the new Records and knows it has extra modules now. Could it access the classes bundled in the add-on MIDlet JARs and instantiate them?

Answer 1

What you are describing to achieve is not supported by the MIDP specifications. Among other things, you can’t have several JARs belonging to the same MIDlet suite.

If you want to achieve some kind of modularity, you need to use a different runtime. One that you define yourself and that can be implemented inside one MIDlet.

You can write a MIDlet that downloads binary files when they become available. That same MIDlet can interpret these binary files. The binary files can contain commands that change the behavior of the MIDlet. The MIDlet needs to support all possible actions that the binary files ask it to perform (a MIDlet can be upgraded, though).

Basically, inside your MIDlet, you need to code a virtual machine that is an implementation of a runtime for whatever new programming language you define.

This is going to be a lot of work. You may very well end up making a MIDlet that is too big to be installed on a lot of phones.