iSeriesMonitorME: Set Up a Wireless Development Environment

by Marc Logemann

[The code for this article is available for download.]

In this second article on development on wireless devices with the ToolboxME package from the JTOpen team and IBM, I will focus on setting up the development environment. After reading the first article, you should have a basic understanding of the libraries and classes involved. In the third, and final, article, I will develop the application, but for now, stay with me for important predevelopment information.

Requirements for Development

There are always different ways to reach a goal. This article tries to present some "best practices" when it comes to setting up your development environment for wireless projects. A Java IDE with good Ant integration is crucial for starting a wireless project.

Of course, writing for and being in the iSeries community, it's always clever to mention Eclipse or its commercial counterpart, WebSphere Studio Application Developer, with its appropriate Ant integration. But there are others to think about, too. Another IDE with superb ANT integration is IntelliJ IDEA, which comes with a recent version of ANT, so there's no need to grab it from the Apache Software Foundation manually.

The reason why I mentioning ANT integration is that wireless development has a more complex build process than Java 2 Platform Micro Edition (J2SE) development. There is not only compiling and JAR file creation; you will also have steps like "preverifying," "emulating," and perhaps "obfuscating." I will explain these steps below.

Test a Web Server for Over-the-Air Provisioning

Over-the-air (OTA) provisioning means transferring an application from someplace on the Internet to your phone. To test OTA, you will need a Web server that is available on the Internet, where your phone can connect to and download the application. Of course, the iSeries is also a perfect Web server for doing this kind of test, and you can use the shipped Apache Web Server for this purpose, which is recommended.

A Lot of Emulator Software

Depending on the estimated installations of your developed wireless application, you should consider installing emulators for the most used Java phones on the market. The various vendors, like Nokia and Siemens, have developer sites from which you can download software development kits (SDKs). If you are just doing the first steps, just use the emulator that comes with Sun Microsystems' Wireless Toolkit.

Obfuscator Software

Obfuscators are normally used for rewriting source code in a way that makes it almost impossible for someone to understand a decompiled version of your code. Even if you don't expect that someone will decompile your intellectual property, the nice side effect is that most obfuscators will shrink the size of the application. You can download ProGuard, a very dedicated obfuscator, from the sourceforge Web site.

Ant Basics

If your IDE of choice comes without Ant, you have to install it manually and check how to integrate it with your IDE. Ant is a Java-based alternative to the popular-make tool. Besides basic operations like compile and distribution, there are countless other functions, called tasks. With the Ant distribution, a lot of tasks are already bundled. To check out an overview of the tasks available, go to Apache's Ant Web site. A lot of external tasks, mainly for interaction with various products and frameworks, are also available. Besides the basic tasks for compiling (javac) and distribution (jar), I will use the Exec task, which enables me to perform a system call to any executable, and the java task, which will execute a Java class. With it, I will call the obfuscator and the preverifier. Since the obfuscator, ProGuard, used in our example, is itself a Java program, there would be no trouble coding an Ant task for it, but this is out of the scope of this article. Just keep in mind that creating Ant tasks is well-documented and doesn't involve too much trouble.

One or more tasks will be grouped in Ant targets. Targets are blocks, which can be executed from within the IDE or the command line. They can depend on other targets, and one target can be defined as a default target, which will be invoked, when you don't define a target to run on the command line.

An Ant Build File for Wireless Development

Let's start to define the different targets we need for our wireless project. Figure 1 shows a visual representation of our build file.

Figure 1: A visual representation of the build file

As you can see in the figure, I will define 5 targets. When I am finished with the build file, the developer only needs to execute one of the emulator targets to start the complete process, from compiling to emulating. For deployment on real devices, we will construct an alternate distribution target, which is capable of downsizing the application via an obfuscation routine.

Please download the complete build file; I will show only the most important parts in this article.

Each build file, which should be named build.xml, starts with a line like this:

<project name="iMonME" default="compile" 
   basedir="d:\development\iMonME">

Here is a brief explanation of the attributes:

• default defines the target that will be executed if nothing else is stated on the command line when executing Ant with the build. file.
• basedir is the path to the project folder in your filesystem.
• name is the name of the project.

To prevent too much hardcoding in your build file, it's advisable to use some user-defined properties. This way, you only need to do changes in one place and not everywhere inside your targets.

<property name="c55toolkit" value="d:\development\c55"/>
<property name="midp_lib" value="${c55toolkit}\lib\api.jar"/>
<property name="mobiletk" value="d:\development\
   j2me_toolkit2.0beta\bin"/>
<property name="proguard" value="d:\development\proguard\lib
   \proguard.jar"/>

Here we define the location of the Siemens C55 SDK, which contains also the MIDP emulator for this phone. Other necessary packages are the proguard JAR file, the MIDP library itself, and the Sun Mobile Toolkit location, which gives us the emulator provided by Sun. As you can see at the value of the midp_lib, you can use the variables also inside the property definitions.

This is a typical distribution target with the preverification included:

<target name="dist_normal" depends="compile">
    <mkdir dir="build/bin"/>

    <exec executable="${c55toolkit}\bin\preverify.exe">
        <arg line="-classpath ${midp_lib}"/>
        <arg line="-d build/classes"/>
        <arg line="build/temporary"/>
    </exec>

    <jar basedir="build/classes"
        jarfile="build/bin/${ant.project.name}.jar"
        manifest="meta/MANIFEST.MF">
        <fileset dir="${basedir}" includes="images/**.*"/>
    </jar>


    <copy file="meta/${ant.project.name}.jad"
        tofile="build/bin/${ant.project.name}.jad"/>
</target>

In nearly every Ant target, you will have native file system operations, like mkdir or copy. In my case, I create a folder that will contain the resulting JAR. As described in the first article of this series, MIDP-based J2ME projects must be preverified after compilation. This preverification depends of course on the compilation, which must occur before you can see this relationship of targets at the depends attribute of the target-tag. The compile target is not shown here, but can be seen in the full build.xml file included with this article. So when you create a target that depends on another target, the other target will be executed even if you trigger only the original target to run.

After preverification, I package the classes, which were compiled into the build/classes folder of the main project location. The fileset task defines one more folder, in my case the images folder, which should be part of the archive. The specification of MIDP defines some important attributes, which are part of a manifest.mf file with the attribute manifest. I tell Ant where to search for it in order to place it in the JAR also. The resulting JAR file will be located in the build/bin directory and will have the same name as our project.

After all this, I copy a JAD file into the same folder. This JAD file is responsible for defining properties used by the device installation mechanism. I will explain it deeper in the next article.

The final target is the emulation trigger:

<target name="emulator_c55" depends="dist_normal">
  <exec executable="${c55toolkit}\bin\emulator">
    <arg line="${basedir}\build\bin
     \${ant.project.name}.jar"/>
  </exec>
</target>

Again, you will see that this target depends on the execution of the previous target, which is called dist_normal. After execution of this dependency (and the dependency of the other target), I call the emulator software to run the JAR file that was just created. Most emulators are able to execute a JAD file to emulate the installation procedure of a midlet, but I will leave it simple for now. The exec task is just a system call to the defined executable attribute. Each parameter is placed inside an arg line, nested in the exec tags.

When everything works as expected, the emulator will pop up inside your IDE and you will be able to test your application on that virtual device.

In the complete build file, you will notice the dist_w_obfuscation target, which is mainly the same as the distribution target described above, with the exception that I inserted the obfuscation task in order to reduce the application size:

[..]
<java fork="yes" classname="proguard.ProGuard" classpath="${proguard}">
 <arg line="-libraryjars ${midp_lib}"/>
 <arg line="-injars ${basedir}/build/bin/${ant.project.name}-orig.jar"/>
 <arg line="-outjar ${basedir}/build/bin/${ant.project.name}-obf.jar"/>
 <arg line="-keep 'public class * extends 
    javax.microedition.midlet.MIDlet'"/>
</java>

[..]

Again, you see that I just executed a program, this time not a compiled binary, but a Java class file. As described before, I contribute some parameters to the call and I magically have a reduced application size. One thing you must watch out for is that you preverify your JAR after it has been obfuscated; otherwise your MIDlet won't work. Also, you must tell the obfuscator not to work on your starting class, because then the mobile device can't find the needed startApp() method, so we just tell it to leave out all classes derived from javax.microedition.midlet.MIDlet.

This build file should be a starting point for an even more personal build environment, which you can create without a hassle. With this article and the build.xml file, you should be ready to code your iSeries monitoring application in the next article of this series. Just keep in mind that your productivity will partly depend on the level of Ant integration with your IDE. It's not reasonable to be forced to spend more time to execute an Ant target than a normal compile would need.

Marc Logemann is a senior e-business consultant at Spirit/21 AG, a German consulting company that focuses on iSeries services and development. He is involved in several Java- and PHP-based open-source projects and likes reading books about new technologies. Marc can be reached at marc@logemann.info.

Sponsored By T.L. ASHFORD

BARCODE400 by T.L. Ashford is the easiest and fastest way to create and print Compliance Labels directly from the AS/400 and iSeries. Ashford's comprehensive library of Compliance formats is available to Barcode400 users. AIAG labels for Ford and Motorcraft, GM, and many more are available. BARCODE400 is backed by the best Technical Support Team in the industry. FREE Guide to Bar Code Labeling www.tlashford.com or call 800.541.4893