I came across some great slides today, from a presentation done by Kevin Horowitz at EclipseCon 2006. Kevin is an IBM employee based out of Boca Raton in Florida. The slides are called ‘Taking it on the road – Developer tools for J2ME’
The slides answer six main questions, these are:

What is the J2ME™ environment?
What is the MTJ Project?
What are the plans?
What is out there already?
How is MTJ developing to meet the need?
Where can I get it and how can I help?

Profiles and Configurations

I know I talked about this a bit in a previous post, but I want to look into this a bit more. Profiles are at the core of J2ME – they define which types of device are supported and are built on top of configurations. The main type of configuration for J2ME (along the same lines, cell phones) is CLDC or Connected Limited Device Configuration. CLDC is comprised the small subset of Java classes needed to run the Java virtual machine. Built on top of CLDC is MIDP or Mobile Information Device Profile. There are two widely accepted types of MIDP, version 1.0 and 2.0. In general they provide an API for LCD GUI development, with 2.0 providing a two dimensional gaming API.

An interesting type of profile, designed for embedded (‘headless’) devices, is IMP or Information Module Profile. These devices have no LCD display and limited network connectivity (i.e. Vending machine). IMP is very similar to MIDP, just without the lcdui.* Java package. As all profiles, these are developed through open JSRs, for more information read them.

A feature rich version of CLDC is CDC or Connected Device Configuration. CDC includes most of Java SE, essentially all which is not UI related. The Foundation Profile, Personal Basis Profile and Personal Profile are profiles utilizing a more complete Java SE framework with a subset of AWT support.

Easiest Way to Upload Apps

Uploading games or applications to your device (phone) via USB cable is most likely disabled. This is really annoying since the other option is to download the apps and spend money on data transfer rates. There are ways to make your phone accept apps via USB cable, but these adventures would end up voiding warranty, etc. I found today a convenient and easy method of uploading apps – Bluetooth. This method assumes your laptop or computer has Bluetooth capabilities, but if it does, then do the following:

• Turn Bluetooth on, for your device and laptop. Find your Bluetooth passwords, most likely if you don’t know them, their 1234.
• Set your phone as ‘Discoverable’ by your mobile device. Most likely your phone will on be visible for 60 seconds.
• From your Bluetooth console on your computer, search for available devices. Once found, right click and ‘Pair’ the device. This creates a persistent connection between the two Bluetooth devices. You will be asked for the associated Bluetooth passwords.
• Double click the paired device in your Bluetooth console. Now, drag and drop the JAR file for your application to the ‘OBEX Object Push’ icon. Once transferred your phone will ask you to install the application.

J2ME UI Development

As shown in a previous post, J2ME MID programs must extend the MIDlet class, which controls the lifecycle of the application. This lifecycle is simple in nature, with 4 states. The figure below was taken from J2ME Application Development and shows the lifecycle:

MIDP user interfaces are divided into 2 parts, the high-level and low-level API. The low-level API extends the Canvas class and is mainly used to develop games or any UI were you must draw pixels yourself. A good example of the low-level API in action is the WormGame, packaged in the example application of the Sun Wireless Toolkit. The high-level API is used to create standard lists, textboxes and forms. It’s important to remember when developing with MID, you have no control precisely were widgets will appear on the screen — this power is given to individual devices (i.e. the device manufacturer). The form class has numerous children items, which can be attached, these include textfield, stringitem, etc. The figure below was taken from J2ME Application Development and shows structure of MIDP UI Classes.

All devices have a Display object, which manages the screen on the given device — most application will only have 1 instance of a display. Each new panel to be displayed to the user will be an instance of the Displayable class. Once this instance is populated with the desired UI widgets, the panel is made visible to the user, by calling the setCurrent method of the Display object.

Below is an example of a method to display a welcome message to a user:

private void displayWelcome() {
	try {
		form = new Form(applicationTitle);
		image = Image.createImage(getClass().getResourceAsStream(
				backgroundPath));
		titleImage = new ImageItem("", image, ImageItem.LAYOUT_CENTER, "");
		form.append(new Spacer(10, 10));
		form.append(titleImage);
		form.append(new Spacer(20, 20));
		form.append(welcomeText);
		form.addCommand(exitCmd);
		form.addCommand(openWebURL);
		form.addCommand(openLocalFeed);
		form.setCommandListener(this);
		display.setCurrent(form);
	} catch (Exception e) {
		System.out.println("NewsReader Error: " + e.getMessage());
	}
}

General Comments

I’ve been begun playing around with MIDP 2.0 (CLDC 1.0), making some simple and more complicated programs. I’m using the book J2ME In A Nutshell as a reference when I don’t feel like Googling. The Sun website has JavaDocs for all their standardized JSRs. The Sun Wireless Toolkit comes with example applications you can use to better understand the J2ME world. There are three types of XML parsers available, push (SAX), model (DOM) and Pull (Incremental). XML parsing on resource restricted devices is something that literature says to do with care. On the same note, most of these articles, etc. were written in 2002/03 and since then, most mobile devices have probably quadrupled in power and memory. Right now, I’m using MinML, a SAX1 supported XML parser designed for devices with 512kB of RAM.

To make a simple test application, start the KToolbar. I had a problem getting this to start, but that was only because KToolbar.bat was pointing to a JVM that didn’t exist anymore (I’m using the 1.5.0 8 JDK). Click ‘New Project’ and enter a project name and class name – for the sake of argument put TestProj and TestApp. Click OK, and the settings for the project are automatically loaded in a window. Check to make sure you are set up for the device you’re using, specifically the MIDP and CLDC setting are correct.

At this point KToolbar has setup the directory structure for your new application, in my case the application is inside of the apps directory of SJWT i.e. C:\WTK25\apps\TestProj. The IDE I’ll use is Eclipse, I also installed the plug-in my team here at IBM developed called RSE (Remote Systems Explorer). It can be downloaded from the Eclipse website within the DSDP Project. RSE allows you to work with remote or local devices. In this case, we can browse the file system and work with the new directory structure KToolbar made for us. (You don’t need to use Eclipse; any editor would be just fine.)

In the /src directory of TestProj create a new file called TestApp.java, the code follows:

import javax.microedition.lcdui.*;
import javax.microedition.midlet.MIDlet;

public class TestApp extends MIDlet implements CommandListener {
	public void startApp() {
		Display display = Display.getDisplay(this);
		Form mainForm = new Form("TestApp");
		mainForm.append("Your first App");
		Command exitCommand = new Command("Exit", Command.EXIT, 0);
		mainForm.addCommand(exitCommand);
		mainForm.setCommandListener(this);
		display.setCurrent(mainForm);
	}

	public void pauseApp() { }

	public void destroyApp(boolean unconditional) { }

	public void commandAction(Command c, Displayable s) {
		if (c.getCommandType() == Command.EXIT) {
			notifyDestroyed();
		}
	}
}

Click here to download the code.

This is the equivalent to a Hello World program for a cell phone. Ok, so let’s review what we have so far. In the /TestProj directory there is a project.properties file, which holds the standards you are programming with, part of mine is below:

….
JSR75: false
MMAPI: true
SATSA-APDU: false
SATSA-CRYPTO: false
SATSA-JCRMI: false
SATSA-PKI: false
WMA0: false
WMA1.1: true
WMA2.0: false
….

In the /bin directory there are 2 files. The first is the manifest file holding a few project specific properties, i.e.:

MIDlet-1: TestProj, TestProj.png, TestApp
MIDlet-Name: TestProj
MIDlet-Vendor: Unknown
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-2.0

The second file in the /bin directory is the JAD (Java Application Descriptor) file. As defined on the Motorola Hackers Guide:

This file contains a predefined set of attributes (denoted by names that begin with “MIDlet-”) that allow application management software to identify, retrieve, and install the MIDlets. All attributes appearing in the JAD file are made available to the MIDlets. The user may define application-specific attributes and add them to the JAD file.

With the source file saved, you’re ready to build your application. From within KToolbar click the Build button and then the Run button. The source will be compiled and the toolkit will launch the Sun emulator.

On an intersting note, RSE is part of the Target Managment subproject of the Eclipse DSDP (Device Software Development Platform) project. Another subproject in DSDP is called MTJ or Mobile Tools for the Java Platform. As it turns out, Nokia is heavily involved in DSDP, specifically MTJ. Here is a quote from the press release:

Nokia and the Eclipse Foundation today announced that Nokia has joined the Eclipse Foundation as a Strategic Developer and Board member. Nokia will support the work of the Eclipse open source community by contributing software and developers to a proposed new Eclipse project.

MTJ was supposed to have had it first release by now, but its been postponed till sometime in September. I’m excited to see what their working on, I hope MTJ will support or use RSE in someway. I look forward to a day were a great open source IDE for resource constrained devices will exist. Here is a particularly interesting quote from the MTJ project page:

The purpose is to develop both frameworks that can be extended by tool vendors and tools that can be used by 3rd party mobile java application developer.

The cell phone I’m going to use as a test-bed is my own, a RAZR V3. Though I’m using a specific phone, a lot of what I say about micro devices will apply (I think) in the general case. The first thing needed, is to figure out the Java System settings on your device. In my case:

CLDC v1.0
MIDP v2.0
Data Space: 1545 K
Heap Size: 800 K

MIDP or Mobile Information Device Profile is a spec written for the development of Java applications on mobile devices, etc. In the grand design, MIDP sits on top of CLDC or Connected Limited Device Configuration, which is another spec outlining a framework for developing Java ME applications on resource constricted devices. Both CDLC and MIDP have been developed by the open source community, and as you can probably tell from my phone, different devices support different versions. The diagram below is from the J2ME Developers Guide for the Motorola V3 Handset. With that in mind, be sure to get your hands on the Developers Guide for your device.

In my case, the heap size is 800 K, this defines the amount of memory the JVM (Java Virtual Machine) can use to create objects, story temporary variables, etc. Developing on cell phone, PDA etc. is a different monster, you need to be conscious of memory size (both disk space and heap size), processing power, screen capabilities and wireless network characteristics.

After I skimmed through the Developers Guide, read up on J2ME, and browsed a couple Wikipedia pages, I set out to find the software I needed to get started. The first thing I did was install the SDK supplied by Motorola for my phone. I’m not even sure why they call it an SDK, the entire kit came with 2 applications. The first was MIDway, which is basically a tool to upload applications to your cell phone. The second was Motorola Launchpad, which acted as an emulator, to test applications on your computer. Undoubtedly, these programs will prove useful (eventually), but for now it’s not that helpful in developing applications. The obvious next install was J2ME, which can be found from the Sun website.

I ended up downloading a couple example applications (with source) from the Motorola website, and after getting a feel for them, wanted to upload these to my phone. After about 10 minutes of frustration, I realized USB application uploads to a cell phone are restricted to ‘Developer phones’. You can check if your phone allows USB uploads by looking in the Java Settings, and seeing if a ‘Java Link’ option available. After a little bit of research, I came across the Motorola Hackers Bible. A moderator from Mobile-Review.com I guess got fed up with people asking the same questions, and wrote a masterpiece. The guide covers a lot of thing, one of which includes transferring applications to your cell phone via USB cable. Needless to say, I spent the rest of the day reading through this guide…

The Open SOA Collaboration represents an informal alliance of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits.

Service Oriented Architecture or SOA, it’s an acronym I hear a lot of at IBM these days. I’m not going to attempt and explain SOA in a blog post, but before you start reading, think of it as large pieces of a puzzle easily interconnecting. Tons of companies have embraced it with IBM, Sun and BEA leading the charge.

I’ll be on course next week here at the Toronto Lab, taking ‘Developing Applications with a Service Oriented Architecture’. I’m excited about it; I know the high level details of SOA, but a lot of the finer points, including developing the applications, I lack.

The course covers:

• SOA Overview
• IBM SOA Foundation Products Overview
• Design SOA Solutions applying principles and patterns
• Develop SOA solutions using IBM SOA Foundation
• Case study Overview
• WebSphere Business Modeler
• WebSphere Process Server and WebSphere ESB Overview
• Service Component Architecture (SCA)
• WebSphere Integration Developer
• Process Choreography and Web Services Business Process
• Develop and assemble business rules and human tasks
• Supporting Services Overview
• Developing Mediation Services
• Adapters
• Deploying to WebSphere Process Server
• Managing SOA
• SOA Security
• IBM SOA Foundation Governance and Processes

One thing for sure in this world: PHP programmers do not want the J2EE world forced upon them. The solution for me was obvious: integrate Java support directly into PHP. I had a couple options to tackle this. I thought about writing my own library, which would use RPC or JNI calls to connect with the existing JAR file, or perhaps use an existing PECL package, but after a little research the best option was to use the open source project PHP/Java Bridge. The project had received rave reviews and in tests destroyed its competition in performance; by using it own custom protocol to facilitate data transfer.

Installation was also a breeze. Assuming you have Apache and PHP already installed, copy the appropriate .dll file from the JavaBrdige.war into extension_dir (as defined in php.ini). For convince rename it to php_java.dll.

for PHP >= 4.3.4 use php-4-java-x86-windows.dll
for PHP >= 5.0.0 use php-5.0-java-x86-windows.dll
for PHP >= 5.1.0 use java-x86-windows.dll

Next, copy JavaBridge.jar from the War file also, into the extension_dir directory. Then open the php.ini file and add the new extension, i.e.

extension=php_java.dll

That’s it, whatever jar file your going to be using, place it in the lib folder of your php installation. Restart the server and you should be good to go.

Link to the articles

Features of the code include:

• A single control loop (as opposed to multiple threads and listeners)
• A great ’stay straight’ algorithm which keeps the robot centered in the network, through 2 light sensors
• Transmission to and from the host component for tasks and logging information
• A task driven control structure

You can download the code here. To learn more about our final product go here.

From the November 11th meeting notes, it looks like it might be out sometime in December:

RSE Status:

Making some progress but sill some obstacles; looking better, but not quite there yet, hopefully make it till the next meeting (3 weeks)

That would be perfect, I could play with it over the holidays and see if it would work with the RCX brick.

The robot will be given a text file of the map, before it enters the maze. Once in the maze the goal is simple: Rescue all the victims as fast as possible. The standard Lego Mindstorms software does not apply here. To handle the complex logic and additional constrains we decided to use LeJOS (open source Java OS for the Lego RCX brick).

Tomorrow is the second “proof of concept” and I just spent a good 6 hours today getting our robot to work. All the robot has to do for tomorrow, is go into the maze (in a straight line) detect the egg and rescue it. Seems simple enough… no. First of all, the egg is hallow and thus extremely light. Unless the egg is going to be tied down (by tape or Palestine) the touch sensor will push the egg without even detecting it. I hear using a light sensor would work better; I’ll try that in the future (or a combination!). The next issue is handling all the threads of execution that get spawned from all the listeners that are set.

Ah well, it works now, and is good for tomorrow. This project is going to take lots of work. Eventually the robot will have to make turns, clear blockages, work with a map (and without), save multiple eggs, etc. Good times.