New Jumplets Available for Jump 2008

New Jumplets Available for Jump 2008

We are always adding Jumplets that increase our support for new handsets and mobile technologies. Below is a listing of the latest Jumplets available as of March 31st, 2008:

Modify Icon (Issue: Modify Icon)

This Jumplet will automatically resize the icon to the target device's proper size. It can also optionally remove the leading slash from icon entries in the JAD file.

Resource Packing Tool (Issue: Jar Size Optimization)

Use this Jumplet to pack specified resources into a binary file. This file will be read at runtime to load the files. This Jumplet will reduce the number of files in the JAR. An option parameter can store a cache of the bin file which results in faster load times but will use more heap memory.

Stub Print Statements (Issue: Jar Size Optimization)

This Jumplet will stub all print and println statements in the application. It will optionally also stub any other statements specified by the user.

Compile Blackberry COD (Issue: Blackberry Application Packaging)

Compiles a JAR file to a RIM COD file

Sign Blackberry COD File (Issue: Blackberry Application Packaging)

Signs a COD file with the RIM signing tool. To use this tool you must:

1. Setup a Jump Environment Variable called 'rim_sdk_dir' and point it to the RIM JDE directory
2. Place in bin your files for signing (sigtool.db,csk,set)

Blackberry Class Size Validation (Issue: Blackberry Application Packaging)

Any midlet class should not exceed the specified size, by default 60k, or the Jump will fail, and tell you which class is too large.

JAD Manifest Validation (Issue: Application Packaging)

Validates that any entry that exists in both the JAD and Manifest are the same values. The Jumplet will cause the Jump to fail and provide a warning if this situation is caught. The Jumplet can optionally fix the mismatches by either modifying the JAD or Manifest to match. Note that the Change Midlet Properties Jumplet could also be used to fix JAD or Manifest entries.

Event Queue and Canvas Proxy (Issue: Event Queue and Canvas Proxy)

1. It acts as a Canvas Proxy, which means say for N Canvases being used in the application. It acts as a layer between these canvases and the application so that the application only ever uses 1 real Canvas. All calls to setCurrent are mapped to the Proxy which handles switching between the old canvas.
2. It optionally has the ability to invoke an Event Queue. The event queue handled all system events (keypressed, hide/showNotify, etc) in an application thread. This helped issues dealing with crashing on system events very well.

Samsung Sound to MMAPI Sound (Issue: Map Samsung Sound to MMAPI )

Maps Samsung AudioClip API to MMAPI sound. Optionally, you may use this Jumplet with the Convert Sound Jumplet and configure it to map SMAF files to MIDI.

Parameters: Map MMF to MIDI - Whether to map calls to play MMF files to MIDI file types instead. This should be turned ON if using with the Convert Sound (SMAF->MIDI) Jumplet.

Map Samsung Sound to Sprint (Issue: Map Samsung Sound to Sprint )

This Jumplet maps Samsung's sound API (AudioClip) to the Sprint native player.

Issue: Helio Sky Sound - API mappings and fixes for Helio Sky Sound

Jumplets:

• MIDP2 to Helio Sky Sound - Maps MIDP2 sound to the device's native sky sound.
• Nokia Sound to Helio Sky Sound - Maps Nokia sound to the device's native sky sound.
• Fix Helio Sky Sound - Fixes Helio sky sound.
• Import Helio Library - Adds the Helio library to the classpath when compiling the target.

Rogers MRC Integration (Issue: Rogers MRC Integration)

Use this Jumplet to integrate with ClearMode (Rogers) MRC service. It acts like the Sprint MRC Jumplet in that it will change your code to call validateLicence on startup.

String Without Encoding (Issue: String Encodings Not Supported)

Some Sprint phones crash if a new String object is created using one of the constructors (below) that take an encoding as a parameter.

String(byte bytes, int off, int len, String enc) or 
String(byte bytes, String enc)

Obfuscation (Issue: Application Packaging)

Added argument blank to enter classes to exclude from obfuscation, and an option to Analyse Dynamic Classes - dynamically analyzes your class files for instances of Class.forName() calls. Will also dynamically check your class files for occurrences of "com.package.ClassName" and ignore those class names for obfuscation.

Modify FileConnection Root (Issue: Modify FileConnection Root)

JSR 75 devices have different roots from which they read local files - this Jumplet provides an option to specify the root through a param, or read the device db for the root info and automatically change the target src based on the target device's root path.

This Jumplet will by default map to both main memory and the memory card (if available).

If the user specifies a root, that takes precedence over the DB Property. Otherwise it will map from the Reference Root , ie

C.open("file:///<refdeviceroot>/appdir") to
C.open("file:///<targetdir>/appdir")

Split RMS Storage (Issue: Split RMS Storage)

Use this Jumplet if you are having problems with a device that has a maximum record size. Adds a wrapper to the RecordStore API. Uses JAL to replace all calls to RecordStore to RecordStoreWrapper which is injected by the Jumplet.

The implementation of RecordStoreWrapper manages records such that no record is larger than the size specified in the device DB property 'RMSMaxRecordSize' or optionally you can set the value in the jumplet argument 'Maximum Record Size'.

The RecordStoreWrapper basically splits the original records into the mini-records. The first record in the RecordStoreWrapper holds the number of original records. The second record hold the nextRecordId based on the original records.

When the original record is added, it is broken up into smaller records, and placed into the recordStore. At the head of this block is the number of records that the original record was split into. At the tail of this block of records, a record is added with the location of the next block of records that contains the original record.

eg of the RecordStore that is managed by the RecordStoreWrapper:

<number of records><next record Id>

<number of records in first block><record 1 of original record 1><record 2 of original record 1>..<record n of original record 1><location of next record block for original record 1>

<number of records in block 2><record 1 of original record 2><record 2 of original record 2>..<record n of original record 2><location of next record block for original record 2>

<number of records in third block><record n+1 of original record 1><record n+2 of original record 1>..<last record original record 1><location of next record block for original record 1 (0 since last block of record 1)>

The necessity of the maintaining multiple blocks is required for the case that original record 1 is added. Original record 2 is added. Original record is set such that it is bigger than when it was added. The first block of records are reset, and the additional bytes are added at the end of the record store (in a new block).