程式師世界 >> 編程語言 >> JAVA編程 >> J2ME >> J2ME MIDP Device Fragmentation Tutorial with Marv The Miner(2)

J2ME MIDP Device Fragmentation Tutorial with Marv The Miner(2)

編輯：J2ME

Building and Executing the Application

　　At this point, we should be able to compile and run the program for all of our configurations. Clicking any of the icons in the main toolbar will execute the selected action for the Active configuration.

　　In the main menu, select Build > Build All Main Project Configurations.

　　Assuming everything is set up correctly, all configurations should now be built.

　　If you did not have Access to one or more of the emulator platforms containing the correct APIs, this step might fail. If that is the case, you should manually comment out any line making a call to an API that you don't have.

　　Preverification will fail for the Motorola configuration if you have not followed the steps to manually install the motoral emulator described in the section for non-UEI emulators. To make this configuration compile without manually adding the emulator, you can comment out all motorola API calls and remove the motorola libs from the LibrarIEs & Resources panel.

　　Select the Files tab in the upper left hand side of the IDE and expand the dist folder. In this folder you should have directorIEs containing Jar/JADs for each configuration that was successfully built, as well as a Jar/Jad that represents the DefaultConfiguration build.

　　Press F5 to run the program for the currently selected configuration. You can switch configurations and press F5 again to run multiple versions of the program at the same time.

　　Exploring Configurations Further

　　This tutorial should have given you a good understanding of how you can import your existing MIDP projects into the NetBeans environment, but it does not cover all of the Device Fragmentation issues solved by the IDE. Below are some more examples of common problems and how they can be solved within the IDE.

　　Each panel in the project propertIEs page can be configuration-specific (except the General page). This gives you a great amount of flexibility. For example, you can have different MIDlet-Version values (Application Descriptor panel) for each configuration's uniquely named (Creating Jar panel) distribution Jar.

　　When setting up dependencIEs between projects, especially when using Project Configurations, make sure to select the correct output jar in the Project Jar Files list box of the Select Project dialog. A project Jar will appear for each configuration in the project you have selected.

　　If, for example, you have two projects MyLibrary and MyApplication, both containing two configurations ReleaseConfiguration and DebugConfiguration, then you would take the following steps to set up the dependency correctly:

　　Open Project PropertIEs for MyApplication. Select ReleaseConfiguration in the Project Configuration combo.

　　Select LibrarIEs & Resources panel, and click the Add Project button.

　　Navigate to the location of MyLibrary project. The Project Jar Files listbox will now contain three Project Jars. Select the one in path dist/ReleaseConfiguration/ and click Add Project Jar Files

　　Switch to DebugConfiguration and repeat these steps, except this time add the project jar located in dist/DebugConfiguration/

　　This is the manner in which you should set up dependencIEs between projects when configurations are involved.

　　The solution is VCS-friendly. All source files will always be saved to the hard drive as if DefaultConfiguration was selected. This prevents conflicts during VCS check-in or update resulting from have a different active configuration. Be sure to also share your project.propertIEs file (located in {projecthome}/nbproject)!

　　Projects can be run from the command line without the use of the IDE. Just type ant run in the project home directory and the project will be run using the active configuration. You can pass a different configuration to the ant script by typing ant run -Dconfig.active={config_name}

　　Projects that used existing preprocessor solutions should be easy to import. Though the NetBeans preprocessor is less complex than some, any situation can be expressed using the provided directives.

　　The LibrarIEs & Resources panel or the Filtering panel can be used to determine which version of a resource should be deployed to a distribution Jar.

　　LibrarIEs & Resources: Create multiple versions of a Jar file containing all resources for the application and then point to the correct version of the Jar for each configuration. So you might have 3 jars: large_res.Jar, medium_res.Jar, small_res.Jar each containing resources of the same name, but different resolutions. Then point your Nokia_large, Nokia_med, Nokia_small configurations at the correct version.

　　Filtering: Include your resources directly in or under the src directory then use the Filtering tree to control which version of the resources are included in the distribution Jar.

　　Using Non-UEI Compliant Emulator Platforms

　　Though only 3rd party emulator platforms that follow the UEI specification can be automatically detected by the IDE, non-UEI complIEnt emulators can still be used. This section describes how it can be done.

　　Adding Non-UEI Compliant Emulators

　　In your userhome directory (the Windows default is C:Documents and Settings{username}.netbeans and the Linux default is /home/{username}/.Netbeans), examine the {userhome}configServicesPlatformsorg-netbeans-api-Java-Platform directory.

　　This directory contains xml files that define the installed emulator platforms. You can manually create these files for any emulator which is not UEI-compliant. The DTD for this XML file can be found at http://www.Netbeans.org/dtds/J2ME-platformdefinition-1_0.dtd

　　Save the following as SDK_4.1_MRI_7.5.XML to use the Motorola 7.5 emulator needed for this tutorial. Note that the use of " is intentional, and should be saved as such.<?XML version='1.0'?> <!DOCTYPE platform PUBLIC '-//NetBeans//DTD J2ME PlatformDefinition 1.0//EN' 'http://www.Netbeans.org/dtds/J2ME-platformdefinition-1_0.dtd'> <platform name="Motorola_7_5" home="C:WTKMotorolaSDK v4.1 for J2MEEmulator7.5" type="custom" displayname="Motorola 7.5" srcpath="" preverifycmd=""{platformhome}/bin/preverify.exe" -classpath "{classpath}" -d "{destdir}" "{srcdir}"" runcmd=""> 　　<device name="Motorola_7_5" securitydomains="trusted,untrusted" 　　description="Motorola_7_5"> 　　　　<configuration name="CLDC" version="1.1" displayname="CLDC" 　　　　classpath="${platform.home}/lib/cldc.zip" 　　　　dependencIEs="" default="true"/> 　　　　<profile name="MIDP" version="2.0" displayname="MIDP" 　　　　classpath=";${platform.home}/lib/midp.zip" 　　　　dependencIEs="" default="true"/> 　　</device> </platform>

　　You will need to restart the IDE after saving this XML file. Once you have done so, you will be able to choose Motorola 7 5 as a platform and Motorola_7_5 as a device. You should associate the Motorola configuration with this new platform. Note that you may need to delete the cache files located in {userhome}varcache in order for the manually installed platform to be detected. Also, you should not delete the mdrstorage folder that may also be located there.

　　Notice that the runcmd attribute is set to empty string. This is because the command to start this Motorola emulator takes the MIDlet to execute as one of its parameters. This is nothing like UEI standards, and cannot be directly supported in the IDE. However...

　　If the emulator platform you're using does not require more information than that provided to UEI emulators, then you can skip this step. The following information is provided to UEI emulators:

　　Security Domain

　　Platform Type

　　Platform Home

　　Jad Location

　　Jad Destination Directory / Jad Name

　　If your emulator requires additional information (such as the location of project Jar or the name of the MIDlet to execute), you can execute emulators by modifying the build.XML file located in your project home directory.

　　This file controls all project actions. We can create a new target here that executes the motorola emulator and passes all appropriate data whenever the Run action is invoked on the Motorola configuration.

　　Add the following code your project's build.XML:

　　So the run_motorola target will be run whenever the active configuration is Motorola. Otherwise, the run_normal target (which uses the normal emulator execution) will be invoked.

　　This concludes the Marv the Miner tutorial.