Midlets midlet suites download

See Chapter 6 for more information. To properly test a MIDlet suite, install it into the toolkit's emulator or a real device. When you press the Run button in the user interface, the MIDlet suite is not installed into the emulator.

Instead, the emulator runs the MIDlet classes directly. The emulator also can install applications into its memory in a process that resembles how applications are transmitted and installed Over the Air OTA on real devices.

The emulator's software is an example of the type of software that real devices must have to manage MIDlet suites. Choose Apps to go to the main list of installed applications. Select Install Application and press the select button on the emulator. The emulator prompts you for the URL location of the application you want to install.

The URL is already completed for you. From the menu, choose Go to begin the installation. The emulator shows a list of the applications it finds at the URL. Choose the only one and select Install from the menu. The emulator gives you one last chance to confirm your intentions. Choose Install again to finish the installation. You are returned to the emulator's installed list of applications, which now includes the application you just installed.

Some features must be tested using this technique, including the push registry and the installation of signed MIDlet suites.

If you want to test your MIDlet suite on a real device, you must install it first. How this happens depends heavily on the device you are using. The following two possibilities are most likely:. Once the application is installed, choose the application from the list and choose Launch from the menu. Running an application on a real device depends heavily on the device itself. Consult your device documentation for information. This is useful for running MIDlet suites from the toolkit user interface even when you don't have the source code available.

You can use the toolkit to easily manipulate the attributes in the descriptor, or you can run the project and use the toolkit's monitoring tools described in Chapter 5 to scrutinize its behavior. Navigate to the descriptor you wish to use and click Open. Note that the descriptor and the JAR file must be in the same directory. An obfuscator is a tool that reduces the size of class files. MIDlet suites need to be compact, both to minimize download times and to comply with sometimes stringent limits on JAR file size imposed by manufacturers or carriers.

You can use an obfuscator in the packaging step of the development cycle. All you need to do is download ProGuard and put it in a place where the toolkit can find it. If you are comfortable with the terms of the license, you can download and use ProGuard free of charge. Follow these steps to install ProGuard:.

Uncompress the proguard. In some cases, you need to provide a script file that controls how the obfuscator works. If you are loading classes using Class. To call the script file you must be able to modify your own copy of the file ktools. Create a script file using a text editor, then save it under the project's main directory.

Consult the ProGuard documentation for information on script files. Next, tell the toolkit how to find this file. Each device is presumed to implement the functions required by its users to install, select, run, and remove MIDlets. The term application management software is used to refer collectively to these device specific functions. The application management software provides an environment in which the MIDlet is installed, started, stopped, and uninstalled.

It is responsible for handling errors during the installation, execution, and removal of MIDlet suites and interacting with the user as needed. The MIDlet is the entity that is launched by the application management software. A new instance of the MIDlet is created by the application management software and used to direct the MIDlet to start, pause, and destroy itself. The MIDP 1. That sandbox concept is used in this specification and all untrusted MIDlet suites are subject to its limitations.

MIDP 2. If and when a device determines that a MIDlet suite can be trusted the device allows access as indicated by the policy. Security for MIDP Applications section describes the concepts and capabilities of untrusted and trusted applications. The application management software initiates the applications and makes the following available to the MIDlet:. The CLDC and Java Virtual Machine provide multi-threading, locking and synchronization, the execution of byte codes, dispatching of methods, etc.

A single VM is the scope of all policy, naming, and resource management. If a device supports multiple VMs, each may have its own scope, naming, and resource management policies. The implementation MUST ensure that the application programmer cannot override, modify, or add any classes to these protected system packages.

All of the classes within these three scopes are shared in the execution environment of the MIDlets from the JAR file.

All states accessible via those classes are available to any Java class running on behalf of the MIDlet. Each library will specify how it handles concurrency and how the MIDlet should use it to run safely in a multi-threaded environment.

The class files of the MIDlet are only available for execution and can neither be read as resources nor extracted for re-use. The files from the JAR file that are not Java class files are made available using java. For example, the manifest would be available in this manner.

The contents of the MIDlet descriptor file, when it is present, are made available via the javax. The developer is responsible for creating and distributing the components of the JAR file as appropriate for the target user, device, network, locale, and jurisdiction. For example, for a particular locale, the resource files would be tailored to contain the strings and images needed for that locale.

The JAR manifest defines attributes that are used by the application management software to identify and install the MIDlet suite and as defaults for attributes not found in the application descriptor. The attributes are defined for use in both the manifest and the optional application descriptor.

The predefined attributes listed below allow the application management software to identify, retrieve, install, and invoke the MIDlet. The version number of the MIDlet suite. Version numbers are formatted so they can be used by the application management software for install and upgrade uses, as well as communication with the user. The first missing entry terminates the list.

Any additional entries are ignored. Leading and trailing spaces in name, icon and class are ignored. The minimum number of bytes of persistent data required by the MIDlet. The device may provide additional storage according to its own policy.

The default is zero. The J2ME profiles required, using the same format and value as the System property microedition. The device must implement all of the profiles listed. If any of the profiles are not implemented the installation MUST fail. Zero or more permissions that are critical to the function of the MIDlet suite. Zero or more permissions that are non-critical to the function of the MIDlet suite.

Register a MIDlet to handle inbound connections. Note: The methods on this interface signal state changes. The state change is not considered complete until the state change method has returned. It is intended that these methods return quickly. Method Summary int checkPermission String permission Get the status of the specified permission. String getAppProperty String key Provides a MIDlet with a mechanism to retrieve named properties from the application management software.

Methods inherited from class java. In the Active state the MIDlet may hold resources. The method will only be called when the MIDlet is in the Paused state. Two kinds of failures can prevent the service from starting, transient and non-transient.

For non-transient failures the notifyDestroyed method should be called. Its destroyApp will be called allowing the MIDlet to cleanup.

In the Paused state the MIDlet must release shared resources and become quiescent. This method will only be called called when the MIDlet is in the Active state.

In the destroyed state the MIDlet must release all resources and save any persistent state. This method may be called from the Paused or Active states. MIDlet s should perform any operations required before being terminated, such as releasing resources or saving preferences or state.

This is only a valid response if the unconditional flag is set to false. If it is true the MIDlet is assumed to be in the Destroyed state regardless of how this method terminates. This request may be honored and the destroy method called again at a later time.