Creating the RUN.XML File
To run the emulator, you have to create a XML file. The emulators have to be installed in the directory
wtklib\devices of the WTK. You have to use the device name displayed in WTK (the directory name for the device) and specify it in the following line in the attribute device:
<wtkrun jadfile="output\bin\${midlet.name}.jad" device="DefaultColorPhone"/>
Table 4's left column explains the code for the RUN.XML file, shown in the right column.
|
<?xml version="1.0"?>
|
|
<project name="MyMidletProject"
default="build" basedir=".">
|
|
<property name="wtk.home"
value="c:\WTK23\"/>
|
|
<property name="midlet.name"
value="MyFirstMidlet"/>
|
|
<property name="midlet.home"
value="${wtk.home}/apps/${midlet.name}"/>
|
|
<property name="wtk.wma.enabled" value="false"/>
<property
name="wtk.mmapi.enabled" value="true"/>
<property
name="wtk.optionalpda.enabled" value="false"/>
<property name="wtk.java3d.enabled"
value="false"/>
<property
name="wtk.bluetooth.enabled" value="false"/>
<property name="wtk.j2mews.enabled"
value="false"/>
|
|
<property name="wtk.cldc.version"
value="1.0"/>
|
|
<property name="wtk.midp.version"
value="1.0"/>
|
|
<taskdef resource="antenna.properties"/>
|
|
<target name="build">
|
Run the emulator (WTK, Nokia Serie40 or Nokia Serie60)
:
-
For WTK : <wtkrun
jadfile="output\bin\${midlet.name}.jad"
device="DefaultColorPhone"/>
-
For Nokia Serie40 Edition 1 :
<wtkrun jadfile="output\bin\${midlet.name}.jad"
device="Nokia_7210_MIDP_SDK_v1_0"/>
-
For Nokia Serie60 <wtkrun
jadfile="output\bin\${midlet.name}.jad"
device="Series_60_MIDP_SDK_for_Symbian_OS_v_1_2_1"/>
|
<wtkrun jadfile="output\bin\${midlet.name}.jad"
device="DefaultColorPhone"/>
|
|
</target>
</project>
|
This example supports basic sounds and backlight for some devices. But in reality, you'd also have to support other features like keyboard constants, fullscreen support, screen refresh loop, regulation of frame rate, and image and sound formats.
Addressing the Complete Chain of Production
Remember that deployment and testing are also very important. Because each small, manual action has to be repeated for each device model, mobile development can quickly becomevery tedious. Imagine renaming all the .jad files, the .jar files, and modifying the content of each .jad file, which includes the name of the .jar file. Or imagine that your upload to the test WAP server for test purposes is manual, forcing you to use your FTP client for 300 or 400 devices!
As strategic as porting is, it's always good to take into account all the optional APIs (like Bluetooth, 3D, file connection, SMS, MMS, etc.) and the optional parts of APIs (like camera support, audio recording, .jpeg, etc.). You shouldn't continue to produce the same application on all the devices while some devices can propose more powerful features.
While porting is a fundamental problem, it's not a deal breaker for producing optimized and rich mobile applications. Ultimately, a completely interoperable mobile application is not possible due to mobile device structure. The trend is to embed more and more increasingly complex software, which means that implementations will always have problems.