Archive for the 'J2ME' Category

The North American market is so sheltered from the rest of the world when it comes to mobile devices. I came to this realization when I was in Greece for the 2004 Olympics, walked into a Samsung booth at the Olympic village and saw the latest phones to come on the market — 3.2 mega pixel camera, phone-to-phone video conferencing, brilliant screens & UIs — no big deal to them.

Last week during the php|works conference, I sat through a talk about Flash + PHP by Christian Wenz. During the session, he briefly mentioned Flash Lite — Flash on mobile devices? I can’t believe I had never heard of this before, its gaining lots of momentum all over the world (Japan, Korea, Europe) there are over 140 supported devices world wide. A full list can be seen here. From the list, its easy to see the largest supporter of Flash enabled devices is Nokia.

As mentioned in a previous post, the MTJ DSDP project had its first M1 release last week. This project is being sponsored mainly by Nokia, with support from other companies like IBM, Sony, Sprint, etc… There seems to be a continuous struggle about what developers should use for UIs, Flash Lite or J2ME, but it appears the answer keeps coming back to: it depends on the application and what you’re doing. The fact remains, with Nokia and so many other companies supporting Flash Lite, there is no way Nokia has been contributing so much effort to the MTJ project, without plans to make an open source Flash Lite development extension to MTJ.

The first official Flash Lite enabled phone was recently released in the US, you probably heard of saw commercials it: Verizon Wireless Chocolate. Click here to see a video of the LG VX8500 phone in action. This phone was released about a year ago in Korea.

The Mobile Tools for the Java Platform (MTJ) Eclipse project had its first release this past Friday. It’s still early and there are many known issues, but it’s worth a try, especially if you have a Nokia phone. MTJ currently supports (has an extension) for Nokia PC Suite toolkits, so you’ll have to go to the Nokia website and download the toolkit for your phone. You’re also going to need a Java wrapper from the Nokia website, all the information is here.

EclipseCon Slides

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.

Continuing on from the day before, I started looking into specifically making an application that would run on my cell phone. At this point and time, the J2ME runtime and the associated tools seem like the best bet to get started. It’s not actually called J2ME, but rather the Sun Java Wireless Toolkit 2.5 beta, in any case some really useful development tools are packaged inside to make the mindless setup a lot easier.

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.

For reasons I don’t feel like getting into, I’ve begun a journey to learn as much as possible about developing applications for micro devices. Before I even get started, let me say I have no prior experience with micro device programming, so a lot of what I say (in coming posts), could very well be wrong.

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…