The Java ME Blog

Java ME: An Introduction [Presentation]

2007-12-13T22:52:00.001+05:30

This is a presentation that I made, which will help anyone new to Java ME platform as a gentle introduction guide. Please comment your opinion.

How to get the IP Address of a mobile using Java ME?

2007-12-13T21:43:00.000+05:30

There are many situations where you may want to know your phone's IP Address. You know that your mobile connects over GPRS which in turn is based on Internet Protocol, so you are pretty confident that the phone has an IP Address.
Well then, there is a good news and a bad news for you. The good news is that your phone do have an IP Address. The bad news is that this IP address will be hardly usefull for you. Why? read on.

The above image shows the network layout of most mobile based IP connection. Your mobile handset will be connected to the service provider's NAT gateway. The IP that your mobile handset get is a private IP, means that this IP can't be reached from external world.

There are ways to get both your private IP and the IP Address of the NAT gateway.

Getting your IP Address
1)The following snippet will give you your private IP Address.

ServerSocketConnection scn = (ServerSocketConnection)Connector.open("socket://:1234");
System.out.println(scn.getLocalAddress());

Note: This method may return your IP Address as 127.0.0.1 (the loopback address) if the GPRS link has been idle. So always send some data over the connection before testing this.

2)Using the System properties

System.getProperty("microedition.hostname");

This is supposed to give you the IP Address. But for me this returns 127.0.0.1 always. If you had any success with this, please share in the comments.

3)This is a bit round about method, but is the most guarenteed to work one. If you are trying to connect to your custom server, have the server tell your ip to you. Implement a handshake protocol, where you say "Hello server" and the server replies "Hello client. Your IP is xx.xx.xx.xx".

Getting the IPAddress of the NAT gateway

Service like http://whatismyipaddress.com/ or http://www.lawrencegoetz.com/programs/ipinfo/ or http://www.whatismyip.com/ gives the IP Address it sees when you browse their pages. This will be your NAT IP Address. Just parse the page and get the IP.

Remember all these works only if you are using GPRS/Wifi. If you want to know the IP address it need to be a IP based network.
If all you want is a unique number to identify your mobile, read this post on using IMEI number

Post your success stories and failure in the comments. Let me know how much this post helped you.

How to create serial numbers unique to a mobile. (Using IMEI number)

2007-11-06T17:09:00.000+05:30

Games and most applications in the Windows world come with a
trial period, during which you can test the application. If you find the
application to your taste, you can purchase the full application, which is
usually a simple serial key to unlock the application.

There have been several attempts to adapt such a method to
the mobile programming world. However, it’s not easy to generate a foolproof
method as the computing power required to generate a strong hash (read as
serial number) or to verify it, is limited in a mobile device. The major
difficulty lies in generating a number, which is unique to a mobile.

But Hey, we don’t want to *create* a new number. We already
have a unique number for every device, which is the IMEI number. Why not use
that?

The only difficulty is that Java ME doesn’t expose any
standard API to get the IMEI number of the device. However, most manufactures allow
us to get the IMEI number using the System.getProperty() method. Here is a HowTo:

Nokia

System.getProperty("phone.imei");
System.getProperty("com.nokia.IMEI");

Sony-Ericsson

System.getProperty("com.sonyericsson.imei");

Samsung

System.getProperty("com.samsung.imei");

Siemens

System.getProperty("com.siemens.imei");

thanks: mypapit

Java ME Advanced Tutorial: GUI Programming Part 1

2007-08-31T11:25:00.000+05:30

S
o you are determined in becoming an 31337 Java ME guru, as is evident that you have begun reading the "Java ME Advanced Tutorial" series. If you haven't read the "Java ME Beginner's Tutorial" series, now would be a good time to skim through it. By the time you start the advanced tutorials, you should be well versed with using Wireless Tool Kit, Java ME Basics, writing code and building it and packaging it. Now we are going into advanced areas of Java ME technology. Let's begin with GUI programming.

Little Background Info

The first version of Java released outside Sun was Java 1.0.2. This initial version itself contained AWT(Abstract Windowing Toolkit), which was a means to develop Graphical User Interface (GUI) applications. Later came Swing, which was a better AWT than AWT.

Java ME do not use AWT or Swing. Instead it defines its own GUI classes which are part of the MIDP api. Reason for not using AWT or Swing are:

AWT and Swing are designed with desktop computers in mind. They are windowing elements for a screen with a higher resolution and capabilities than a mobile phone's screen.
AWT and Swing are supposed to work with a pointing device such as a mouse. Most mobile phones however do not have such a pointing device.
Most of the features that the AWT and Swing supports, such as the Window Mangement and overlapping windows, are impractical and impossible on a mobile device.
AWT and Swing creates event objects during runtime for each GUI event such as mouse-move and button-click. These objects exists only till the event is processed and is later freed during garbage collection. However, the limited processing power and memory of mobile device cannot handle such a heavy process.

Classes for GUI programming are defined within the MIDP APIs.

Due to these reasons MIDP decided to have its own set of GUI APIs. These APIs are classified as high level and low level APIs. Both the high level and low level APIs come in the javax.microedition.lcdui package.

Anything that can be displayed is represented by the Diplayable class. The Screen class is a sub-class of the Displayable class and represent screens that occupy the full screen area. There are three types of screens:

Screens that have a predefined structure and is indented for a specific purpose. You cannot add any other components to these screens. eg: List, TextBox etc.
General purpose screens made using the Form component. You can add other components to this Form creating custom screens of your desire.
Screens created using low-level APIs; as a subclass of Canvas, GameCanvas etc. If you are interested in mobile game programming, this is the stuff you need to learn more thoroughly.

The first step in GUI programming is to get the display object. Yes, as you might have guessed, the display object represent the display of the mobile device. The general routine in GUI programming is:

Get the display object: There is a class named Display in the javax.microedition.lcdui package. We use a static method named getDisplay() to get the display object.
public static Display getDisplay(Midlet midlet);
Things to remember:
- A MIDlet can have only one instance of display object.
- Display.getDisplay() can be called multiple times;however, all calls will return the reference to the same object.
- Do NOT call getDisplay() in the MIDlet's constructor, as the display might not be initialized then.
- A better approach would be to call it in startApp() method.
Create a screen object: The different types of the screen objects and their behavior will come later in this tutorial series.
Show the screen on the display:For this we use the setCurrent() method of the Display class.

public void setCurrent(Displayable nextDisplayable);
public void setCurrent(Alert alert, Displayable nextDisplayable);

Display class - In detail

We have already seen some of the methods in the Display class: getDisplay() and setCurrent(). Some other most useful methods are discussed here:

getCurrent():
public Displayable getCurrent()

This returns the Displayable object that is currently being displayed on the screen. If you call this before setting a screen using setCurrent, it will return NULL.
If the screen is hidden by a system screen(such as a low battery Alert screen), still getCurrent() will return the Displayable that was last set using setCurrent().
isColor():
public boolean isColor()

This returns true, if the phone is a color phone. Else, this returns false.
numColors():
public int numColors()

This returns the number of colors if the phone is a color phone. Otherwise, it returns the number of gray levels supported.
setCurrentItem():
public void setCurrentItem(Item item)

This is a very useful method when you are using forms. Suppose you have a form with two TextEntries - Name and Password, and you wish that the cursor be in the Name field when the form is displayed. All you have to do is : d.setCurrentItem(name);
vibrate():
public boolean vibrate(int duration)

This method can be used to enable and disable the vibrator of a phone. If the phone doesn't support vibration or if your display is not in the foreground then this call returns false. Otherwise it returns true. This method returns immediately and is not a blocking call. It accepts the time in milliseconds for which the vibrator should be active. However, the implementation can limit or override this duration. If this parameter is zero, vibrator is stopped.
flashBacklight():
public boolean flashBacklight(int duration)

This is very much similar to the vibrate() call. It is used to turn on and off the devices' flashlight repeatedly for the duration specified in the parameter. If the parameter is zero the light is turned off immediately. This method is non blocking and returns false if the display is not in the foreground or if the back light cannot be controlled by application. Else it returns true.

In the next section, we begin with the high level api.

Next: TOFOTOTO >>

<< Java ME Advanced Tutorial: Table Of Contents

Java ME Advanced Tutorial: Table Of Contents

2007-08-31T11:21:00.000+05:30

Chapter 1 : GUI Programming Part 1

Java ME Beginners Tutorial : Packaging

2007-08-30T14:24:00.000+05:30

W
elcome to the sixth chapter of the "Java ME Beginners Tutorial" series.

Success of any software application largely depends on the ease of its installation. There should be a standard way of packaging your application; a form which is easy to send over a network, and one which is easy to install. In Windows there is the .msi packages (setup.exe?) and in Linux we have the RPMs and DEBs.

In the Java ME arena, the packages are called "MIDlet Suites".

Midlet Suites can contain more than one MIDlets. A MIDlet Suite is not a single file, but a group of two files: JAD file and a JAR file.

JAD File

JAD stands for "Java Application Descriptor" and is a simple text file. If you have installed WTK and followed the exercise in our last chapter, you will find a JAD file in your [INSTALLDIR]\apps\JavaMEBlog\bin directory. Open JavaMEBlog.jad using Notepad and you can see the following contents:

MIDlet-1: JavaMEBlog, JavaMEBlog.png, HelloMIDlet
MIDlet-Jar-Size: 887
MIDlet-Jar-URL: JavaMEBlog.jar
MIDlet-Name: JavaMEBlog
MIDlet-Vendor: Unknown
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.1

This is a JAD file that WTK made for us. The contents of JAD file is arranged in the form of property:value. The valid properties that can come in a JAD file are:

MIDlet-Name: This is the name of the MIDlet suite (Do not confuse it with name of individual MIDlets contained in the suite).
MIDlet-Version: Version of the MIDlet Suite.
MIDlet-Vendor: The name of the person or the company which developed the MIDlet Suite.
MIDlet-Icon: Every MIDlet Suite has an icon that appears in the phone menu when the suite is installed. This enables the user to easily identify an application. The value of this property should be the name of the icon. Icons have to be stored in the res folder within the project directory.
MIDlet-Description: A short description of the MIDlet suite.
MIDlet-Info-URL: A url that gives more information about the MIDlet Suite.
MIDlet-: As mentioned, a MIDlet suite can contain more than one MIDlet. For each MIDlet present, there should be a corresponding MIDlet-1, MIDlet-2 etc entry made in the JAD file. The value of this will contain the MIDlet name, Icon for this MIDlet and the MIDlet class name.
MIDlet-Jar-URL: URL of the JAR file
MIDlet-Jar-Size: Size of the JAR file in bytes.
MIDlet-Data-Size: The minimum number of bytes required for persistent data storage.
MicroEdition-Profile: What J2ME Profile is required by the MIDlet.
MicroEdition-Configuration: What J2ME Configuration is required by the MIDlet.

Not all of these properties are compulsory, but the following are :

MIDlet-Name
MIDlet-Version
MIDlet-Vendor
MIDlet- for each MIDlet in the JAR file
MicroEdition-Profile
MicroEdition-Configuration

JAR File

JAR stands for "Java Archive". A JAR file is a compressed zip file which will contain compiled class files, icons, images and other resources that the application requires during runtime. Since it is a zip file, you can open and inspect it using any zip utility like WinZip. To create a JAR file select Project -> Package -> Create Package from the menu bar. This will create a new JAD and JAR file in the [PROJECTDIR]\bin folder.

Every JAR file will contain a folder named "META-INF" and file named "Manifest.mf" inside this folder. Manifest.mf is again a text file and if you open it using a text editor, you can see that it very much resembles the JAD file. All the JAD file properties that we used earlier can be added to the Manifest file also. The value of compulsory properties like MIDlet-Name, MicroEdition-Profile, MicroEdition-Configuration etc has to match in both the manifest file and JAD file. Other properties can differ between Manifest and JAD file, but in such a case the values in the JAD file is taken.

Previous:Writing the first MIDlet

Table of Contents

Next:TODO TODO

Java ME Beginners Tutorial : Writing the first MIDlet

2007-08-29T17:04:00.000+05:30

L
ets get our hands dirty. In this chapter, we are going to write our first MIDlet. This is the fifth chapter in the 'Java ME Beginners Tutorial' series.

By the time you reach here, you are expected to have gone through the introduction, installed WTK on your work machine and learned about it. We also had a brief look into the Java ME world. In this chapter we will begin coding.

If you remember earlier chapters, it was said that Wireless Tool Kit is not an IDE. There is no facility to edit and indent code. So we have to use a text editor for this purpose. For the purpose of this tutorial, we will use Notepad available in windows (Linux users have a myriad of options: vi, emacs, gedit, kate, kwrite etc etc...).

Step 1

Fire up WTK (Start -> All Programs ->Sun Java(TM) Wireless Toolkit 2.5 for CLDC ->Wireless Toolkit 2.5 or [INSTALLDIR]\bin\ktoolbar.exe). Then select "New Project" from the toolbar.

You will get a dialog box asking for Project Name and Midlet class name, as shown below.

Provide "JavaMEBlog" as the project name and "HelloMIDlet" as the class name and click "Create Project". You will get a settings page. This is the configuration page where you can edit the settings of your project. The default settings will work for us, so click "OK". If all went correct, a folder named JavaMEBlog would have been created in the [INSTALLDIR]\apps\ directory (INSTALLDIR is the place where you installed WTK). This is the main project folder. It contain many sub directories :

bin:Will contain the binary files: JAD and JAR after compiling the code. (We will see JAD and JAR files later when we discuss "Packaging")
lib:Place the library files(again in JAR format) that the application requires in this directory.
res: Place resources like icons, images, audio, video files etc that the application requires during run-time in this directory.
src:The most important directory for the application developer, as this directory contains all the source code.

Step 2

Copy-paste the following code into Notepad:

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

public class HelloMIDlet extends MIDlet {
public void startApp() {
System.out.println("Hello World");
}

public void pauseApp() {
}

public void destroyApp(boolean unconditional) {
}
}

Now save it as "HelloMIDlet.java". If using Notepad, be careful to make the "save as type" to "All files". Otherwise notepad will name the file as HelloMIDlet.java.txt which is not what we intended. You have to save this file in the [INSTALLDIR]\apps\JavaMEBlog\src directory.

Step 3

Now we can compile the code. Select "Build" from the tool bar. Building is a sequence of two operations: Compiling the code and then preverifying it. If your code was correct you will get the "Build complete" message as shown in the figure.

Step 4

Next step is to test the application. We use the Wireless Tool Kit's emulator for this purpose. Select "Run" from the tool bar.

Our application doesn't do anything useful. All it does is to print "Hello World" in the WTK console and exit (duh!); so there is no point in installing such an application in an actual mobile device since there is no console in mobile devices.

On running the application, the default emulator will be displayed (which will be Default color phone, if you haven't changed any settings). The application name "JavaMEBlog" will be displayed on the screen. Select "Launch". Since out application doesn't have a GUI, you will not notice any difference in the screen. But the string "Hello World" would be printed on the WTK's console.

Understanding the source code

public class HelloMIDlet extends MIDlet {

Every MIDlet should implement the abstract class javax.microedition.midlet.MIDlet. This class contains three abstract methods that we have to implement: startApp(),pauseApp() and destroyApp(). Every MIDlet is invoked and controlled by the Application Management System (AMS) residing in the mobile phones. The above three methods are special as they are never called by the developer(application) but by the AMS. Whenever the user wishes to run the application, the AMS invokes the startApp() method. When the AMS wishes to pause the application (such as during an incoming call) the pauseApp() method is called. Finally, when the AMS wants to terminate the application, the destroyApp() is called.

public void startApp() {
System.out.println("Hello World");
}

The stuff within the startApp() method will be executed when the application is launched by the user. Here, we have given as simple println statement. The System.out.println() will print to the WTK's console area. So it can be used for testing with an emulator only.

public void pauseApp() {
}

public void destroyApp(boolean unconditional) {
}

We are not doing anything when pauseApp() or destroyApp() is being called. In actual programming, we will be doing some clean up work (freeing some resources) in these methods.

Since we have gone through our first code, now is a good time to discuss the life cycle of a MIDlet application.

There are three states for every MIDlet: Active, Paused and Destroyed. When the MIDlet object is made by calling its constructor, the application is said to be in the Paused state. Then the AMS can move the application to Active state by calling the startApp() method. From the Active state, the AMS can take the application back to Paused state by calling the pauseApp() method. The thing to remember here is that startApp() and pauseApp() can be called multiple times in an application's life time.
When the AMS wants to terminate the application, it calls the destroyApp() method. destroyApp() accepts a boolean parameter. If this parameter is true, the MIDlet has to compulsorily quit, no matter what it is currently doing. However if this is false, the application can survive termination by throwing a MIDletStateChangeException. If any runtime exception occurs within the destroyApp() method, it is ignored and the application is terminated immediately.

Next we will discuss how to package the compiled classes to a package so that other people can easily install our application.

Previous: Java ME Basics

Table of Contents

Next: Packaging

Java ME Beginners Tutorial : Java ME Basics

2007-08-24T12:28:00.000+05:30

W
elcome to the fourth part of the "Java ME Beginners Tutorial" series. If you haven't read the previous parts you can begin here (Java ME Beginners Tutorial : Introduction).

By the time you reach here, you have installed WTK and studied it.So now we have everything we need to get some Java ME gyan. Let’s start.

By saying Java ME, we refer to a number of classes, interfaces and a JVM that is needed to run a Java application on mobiles. To make things simple and to bring little peace to this chaotic world, these classes, interfaces and JVM are put into three layers: Configuration, Profile and Optional Packages. Memorize these jargon words; you will not regret doing it when you become ‘the el33t Java ME guru’.

Configuration

This is the most underlying layer of Java ME and not surprisingly, it contains the “special” JVM also. Now why do we need a special JVM? Why can’t we reuse the existing JVM that we use in our desktops? The reason is simple: your mobile phone has less computational muscle as compared to a desktop computer. So it simply can’t run the bulky and mighty JVM from the desktop world.

I said I was lying when I defined Java ME in the introduction. I said that Java ME is for creating Java programs for mobile phones. Sure!, you can use Java ME technology to develop application for mobile phones, but its scope is not just limited to mobile phones. Java ME is currently used on a multitude device like pagers, set-top boxes, car navigation systems and a number of other embedded systems. The only requirement to use Java ME is that the device should have some sort of connectivity: a powerful Ethernet connection or a weak wireless connection.
There are two types of configuration as of writing this:

CDC and
CLDC

CDC stands for ‘Connected Device Configuration’ and CLDC for ‘Connected Limited Device Configuration’.

CDC aims at devices that are a little bit more powerful than a mobile phone; devices like a Set-top box or a Car Navigation system. I have mentioned that configuration contained the JVM. The virtual machine in CDC is called CVM (Compact Virtual Machine).

Mobile phones use CLDC as the configuration. The VM used in CLDC is termed KVM (K because it runs on Kilobytes of memory).

CVM

This VM is a complete clone of the desktop Java JVM. It contains all the power, all the abilities of the former. Only difference is that it can run in a much-restricted environment: restricted memory, restricted computational power, restricted storage facility.

KVM

This is a stripped down version of the desktop VM. It is designed for smaller device like a mobile phone and for a smaller memory footprint. It doesn’t support all features of conventional JVM like the object serialization, finalization etc.

In addition to the JVM the configuration also contains all the classes, interfaces and exceptions that Java ME subsets from Java SE. A list of all classes contained in CLDC can be obtained here.
The configuration used in mobile phones is CLDC, and hence this will be our area of interest.

CLDC

Some of the limitations of the CLDC are given below. A programmer need to be aware of such limitations to avoid serious trouble later on.

No floating point support.
No object finalization.
No JNI support.
No reflection.
No thread groups and daemon threads.
No application defined class loaders.
Implementation defined error handling.
Class verification is done in a different manner.

Profile

A profile extends the configuration. It adds domain specific classes to the core. It is geared towards a specific use of the device. For example, not every device need to have a screen. For devices that have one, the APIs to manage the screen is included in a profile.

There are different types of profiles like MIDP, Foundation Profile, Personal Profile, Personal Basis Profile etc. The profile used in mobile phones is MIDP, and hence this will be our area of interest.

MIDP

Application created using the MIDP API is called a MIDlet.

Mobile Information Device Profile extends the CLDC configuration. JSR 37 introduced MIDP 1.0, while JSR 118 introduced MIDP 2.0.
MIDP 1.0 contained APIs for UI creation, local persistence mechanism, networking and MIDlet life-cycle management. (An application written using MIDP APIs is called a MIDlet). In addition to these, MIDP 2.0 added APIs for a robust security policy, APIS for sound and gaming and extended the networking APIs to include TCP socket streams, UDP datagrams, serial, push-initiated and secure connections.
You may not know a lot of things said above. Don’t worry just read along. You will catch up in no time.

Optional Packages

At first, when the 'Sun' god created Java ME platform (then called J2ME) there was only configurations and profiles. As the platform evolved, god realized that something was missing. There was no way to support new technology. He knew it was not a good practice to throw everything and the kitchen sink into the profiles. So he created optional packages.

Optional packages are similar to profiles as they are also a set of APIs. They do not have an independent existence of their own. They are always associated with a configuration and a profile. An optional package extend the capabilities of a configuration + profile system.

An example of an optional package is the MMAPI or the Multimedia API. This API provides support for playing Audio and Video files as well as other features like taking photos using the phones built in camera. However not all mobile phones support multimedia and not all mobiles will be having a built in camera. So only those phones which support these features will contain the MMAPI support in them.

An important thing that Java ME developers should know is that application developers have no control over what optional packages are available on a phone. No, we cannot install optional packages in a mobile phone, nor can we bundle our application with an optional package. It is the phone manufactures like Nokia and Motorola that should provide optional packages. If they haven't, then you will have to eat that.

Previous:WTK Explained

Table of Contents

Next: Writing the first MIDlet

Java ME Beginners Tutorial : WTK Explained

2007-08-24T10:56:00.000+05:30

T
his is third part of the "Java ME Beginners Tutorial" series. If you haven't read the previous parts you can begin here (Java ME Beginners Tutorial : Introduction).

This section explains in-depth about the Sun's Wireless Tool kit(WTK). We have already discussed the Installation of WTK.

When you install WTK seven menu entries are made for you. They are:

Default Device Selection
Documentation
OTA Provisioning
Preferences
Run MIDP Application
Utilities
Wireless Toolkit 2.5

Default Device Selection

After you write your code and compile it, you will be emulating the behavior of your application using an emulator that's built into the WTK. This avoids the need for a physical mobile device to install and test your app each time you make a modification. Since there are a wide variety of mobile devices on the market each with a different look and feel, WTK provides us with four different emulators each having a different screen size and look and feel.

The "Default Device Selection" menu entry points to \bin\DefaultDevicew.exe. It is a simple utility which enables us to make a particular emulator as our default emulator.

Documentation

An excellent documentation for the Wireless Tool Kit. It also includes the API reference for CLDC, MIDP and a number of other popular packages. (Don't worry if you don't understand what's CLDC and MIDP. It will be explained later). Go throught the FAQ section in the documentation. It is a must read!

OTA Provisioning

The Java ME platform has the ability to download and install a Java application over a wireless network (usually on demand). This is called OTA(Over The Air installation) For this, after developing the application we need to place the application on a special server. Once we have done this, we can use the WTK emulator to download and install the application. If OTA works fine in emulator it ought to work fine in an actual mobile device.

The "OTA Provisioning" menu entry points to \bin\emulatorw.exe -Xjam. That is, it invokes the emulator with a particular command line switch "-Xjam". It displays the default emulator as shown below.

Select "Apps" and then Menu -> Launch.
You will see a text entry where you can give the web address of your application to be installed.

Preferences

The menu entry "Preferences" points to \bin\prefsw.exe. The preferences window allows you to change many configuration settings of the Tool kit. These include the Network Proxy, the heap size available,adjusting emulator performance, enabling memory and network monitoring, enabling profiling, tracing, changing the emulator's storage space etc.

Utilities

The "Utilities" menu entry points to \bin\utilsw.exe. It is similar to the Windows Control Panel as it is a collection of multiple utility programs. It contains utilities like the Database Cleaner which removes all database records in the default emulator, the memory & network monitor, the profiler, midlet signing utility etc.

Wireless Toolkit 2.5

This is the most important one. It points to \bin\ktoolbar.exe. It is important because we use it to perform all major tasks in Java ME application developing - compiling, packaging and testing (and more).

An important thing to know is that WTK is not an IDE. It doesn't have any means for code editing. You will have to use an external text editor like notepad for creating .java files.

We can classify the main window into three parts:

Menu Bar
Tool Bar
Console Area

This have been marked in the figure:

How to use WTK will be discussed as we begin coding.

Previous:Installation

Table of Contents

Next:Java ME Basics

Java ME Beginners Tutorial : Installation Instructions

2007-08-24T09:12:00.000+05:30

T
his is the second part of the "Java ME Beginners Tutorial" series. If you haven't read the first part you can get it here (Java ME Beginners Tutorial : Introduction).

This section explains about installing Sun's Wireless Tool kit (here forth called WTK) in your computer. Prior to installing WTK , you should have Java SE Development Kit installed.

If you have been programming in Java for a while, you may already have it. Otherwise download JDK and install it first.

The next step is the installation of the WTK itself. Download 'WTK for CLDC' from the sun's site. As you will notice it is available for both Windows and Linux. This tutorial will be using WTK on Windows, but it will be much similar to use in a Linux machine.
Once you install WTK you will get a menu entry in your start menu as shown.

The one which we are interested is Start Menu -> All Programs -> Sun Java(TM) Wireless Toolkit 2.5 for CLDC -> Wireless Toolkit 2.5. (In older versions of WTK, the menu entry was named 'ktoolbar'). If you select it the following screen will be displayed.

The next section will explain the WTK interface in detail.

Previous:Introduction

Table of Contents

Next:WTK Explained