Skip to main content

About deploying extensions

3 replies [Last post]
lantonello
Offline
Joined: 2007-07-11
Points: 0

Hi all,

I am a developer for a small company and have some question.
We write a custom API thats take care of all gui implementation of our applications.
This API is a single JAR file. The target is to make an extension, available for all applications.
But the problem is: How to deploy an extension in a mobile device?

In desktop environment this task is simple: just copy the extension to bin/ext folder.
But how to do this in a mobile?

And more... there are some way to tell the JVM to download the required extension(s)?

Thanks a lot!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Hi,

An important piece of information is whether you are deploying this to a CDC-based stack or to a CLDC-based stack. The feature that your are looking for is better kown as a "module system" or "shared libraries" and the availabiity of such a mechanism depends on the platform.

The CDC stack is based based on Java 1.4.2 so the flexibility of custom class loaders and adding and replaces classes is available on CDC. Different CDC stacks may have different frameworks to support module systems or shared libraries. I can't give you a generic answer here.

The CLDC/MIDP stack is very different from CDC from a security perspective. On MIDP there is no way for you to add or replace classes or libraries on the system class path for security reasons. This means you cannot add a module or library (extension) to the system and make that available to multiple applications. There is also no way for you to tell the JVM to do that, again for security reasons. Only the vendor of the CLDC/MIDP stack is allowed to make such modifications or extensions.

The only exception to this rule is that multiple applications within the same MIDlet *suite* can share a library or common extension code. But all applications within a suite are deployed as a unit at the same time. It is not possible to install parts of MIDlet suites successively to achieve what you want to do.

So how do developers deal with this currently on MIDP? Really there is no other way than to include the module or shared library with each application. That is not ideal but works and the drawbacks (duplicate code, storage space, download time) are usually acceptable.

PS: MIDP 3 (http://jcp.org/en/jsr/detail?id=27) has a shared library feature which will do what you want. But MIDP 3 is not available yet in devices.

Hope this helps,

-- Terrence

lantonello
Offline
Joined: 2007-07-11
Points: 0

Hi Terrence,

Thanks for this information.

We uses MIDP / CLCD as a stack. The problem is that for each modification in shared library, we have to re-compile all applications that uses the library...

If I deploy my shared library in the same way that others apps, it's will be available for all applications, like a extension or not?

Thanks a lot for your reply!!!

PS. Sorry about my english... I'm brazilian. :)

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Hi again,

I'm not sure I fully understand your last questions but I'll try:

If you modify a shared library in a way that is not visible to the callers of the library then you don't need to recompile all your applications. You just need to rebuild the jar file by replacing the old version of the shared library with the new version.

The deployment context of a shared library is the MIDlet suite so a shared library is useable by all applications in that suite but not by other applications outside that suite. Here is an example:

Suite A contains:
- MIDlet1
- MIDlet2
- shared_library1

Suite B contains:
- MIDlet3
- shared_library2

MIDlet1 and MIDlet2 can both use shared_library1, but MIDlet3 cannot use shared_library1. This is true even if both suites are installed on the same phone at the same time. MIDP security defines that suiteA and suiteB cannot see each other.

PS: Lots of Brazilians around these days here and on Java ME in general! ;-)

-- Terrence