The Java ME Blog

Java ME: An Introduction [Presentation]

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

This is a presentation that I made to explain the Java ME technology to some management guys. As you can see, it doesn't contain Java ME explained in detail, but is just a basic introduction to anyone new to the field. 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

Java ME Beginners Tutorial : Introduction

2007-08-23T11:19:00.000+05:30

T
his is the beginning of the 'Java ME Beginners Tutorial' Series. Emphasis has been given to explain stuff in a easy to understand, concise manner. This is intended for novice Java programmers who wishes to enter the 'Java ME' arena. Please send your feedback to anoopengineer[AT]gmail[DOT]com. We will begin with the prerequisites.

Prerequisites

Good knowledge on Core Java a.k.a Java SE.
Sun Java Wireless Toolkit 2.5.1. See installation for details.
A Little grey matter.

What we are going to learn

Java ME (earlier known as J2ME) is for creating java programs for mobile phones (I'm lying here as I explains later, but this will help you now). You use an ordinary Windows/Linux desktop computer to write your program, emulate its working using the toolkit, and then transfer it to a mobile phone for installing.
For this, you need to install "Sun Java Wireless Toolkit" in your desktop. The current version of the toolkit as of writing this is 2.5.1. How to get the toolkit and install it is specified in the installation section. After going through this tutorial, you will be able to create all kind of mobile applications, limited only by your creativity

Table of Contents

Next: Installation

Java ME Beginners Tutorial: Table Of Contents

2007-08-22T23:55:00.000+05:30

Chapter 1 : Introduction

Chapter 2 : Installation Instructions

Chapter 3 : WTK Explained

Chapter 4 : Java ME Basics

Chapter 5 : Writing the first MIDlet

Chapter 6 : Packaging

Java ME Books

2007-08-22T17:00:00.000+05:30

This is a listing of all books that are related to Java ME technology. They are in no particular order.

Free Books

J2ME & Gaming by Jason Lam

Enterprise J2ME: Developing Mobile Java Applications by Michael Juntao Yuan

Wireless Java: Developing with J2ME, Second Edition by Jonathan Knudsen.

Wireless Java for Symbian Devices by Jonathan Allin

Programming Java 2 Micro Edition on Symbian OS. A developer's guide to MIDP 2.0 by Martin de Jode

Beginning J2ME: From Novice to Professional, Third Edition

About the Author
Jonathan Knudsen is a Java developer and noted author of several books, including Wireless Java: Developing with J2ME, Second Edition, Mobile Java, The Unofficial Guide to LEGO MINDSTORMS Robots, Learning Java, and Java 2D Graphics. Jonathan began his object-oriented programming career in Objective-C on the NeXT OS, soon thereafter suffering through a couple of purgatorial years in Microsoft's Visual C++, before graduating to Java in 1996. He has written extensively about Java and LEGO robots, including five books, a monthly online column called "Bite-Size Java," and articles for JavaWorld, EXE, NZZ Folio, and the O'Reilly Network. Jonathan holds a degree in mechanical engineering from Princeton University. You can find him at www.jonathanknudsen.com. Sing Li is a systems consultant, avid open source developer, and active freelance writer. With over two decades of industry experience, Sing is a regular contributor to printed magazines and e-zines, and has a sizable roster of book credits. Sing is an evangelist of the mobile Java, VOIP, and P2P evolution.

Java ME Tutorials

2007-08-22T16:58:00.000+05:30

This page contains listing of all the Java ME tutorials and articles contained in "The Java ME Blog".

Java ME Beginner's Tutorial

This is a sequence of Java ME tutorial written for pure novice to Java ME field. Special importance has been given to simplicity and ease of understanding in writing this. It begins from giving an introduction to Java ME, goes through the various tools required in the trade and concludes with a guide to building source code using Wireless Tool Kit. You can start with the table of contents or instead, dive directly into action here.

Java ME Advanced Tutorial

This is a sequence of tutorials written for people who have had an introduction to Java ME technology. It has been written as a continuation of the Java ME Beginner's Tutorial. It covers topics like GUI programming, RMS, Multimedia, WMA, Bluetooth etc. You can start with the Table of Contents.

Java ME- Frequently Asked Questions

2007-08-22T16:49:00.000+05:30

This is supposed to contain a FAQ. Please give me a little time to compile this.

Contact Me

2007-08-22T16:04:00.000+05:30

Your feedback on this site is most welcomed and needed. Please send in your queries and suggestion to anoopengineer[AT]gmail[DOT]com. I usually reply to all mails that I receive. But if I am taking time, it means I am currently engaged in something more important. Please be patient, I will eventually find time for you. Alternatively, you can leave your comments on any blog post, and I will do my best to answer them. Thanks, Anoop KS.

Java ME Beginners Tutorial: Part Two

2007-08-20T15:05:00.000+05:30

The Build Procedure

There are six steps in the creation of a MIDlet. These are:

Design

This is essential for even the smallest of the projects. A good design can eliminate most of the roadblocks you are going to face with “jumping into the code” style of programming. You need to keep in mind some of the elemental features of a mobile application. The User Interface in a mobile phone is substantially different from a user interface available in Microsoft Windows or Linux Gnome/KDE. In windows forms, a large amount of data can be provided to the application through a wide range of widgets available like text fields, radio buttons, combo boxes etc. due to the large screen size. In a mobile phone, the screen real estate is limited and hence you may want to limit the widgets in each screen to a minimum and take the user through a sequence of screens to get the needed data (much like a wizard in Windows). In usual commercial production environment it is always better to design the application UI in Flash first and then code it accordingly.

Code

Every MIDlet must extend the abstract class MIDlet in javax.microedition.midlet package. Then you have to override three methods of this abstract class:

· startApp()

· pauseApp()

· destroyApp()

We will come to these methods later when we discuss the MIDlet life cycle.

Remember that there will NOT be a “public static void main()” method anywhere in our program.

Compile

Similar to Java SE technique, the code has to be compiled to byte code form. This is done using the javac compiler.

Preverify

Before running any class file the JVM performs a verification of the byte code to ensure that it is structurally and conceptually correct as per the JVM specification. If the class file fails this check, it is rejected and the JVM shuts down. This is done by all JVMs including our CLDC JVM. But there is a problem. Verification is a costly process, both in turns of memory and processor cycles. And hence a normal mobile phone won’t be able to verify class files. As a solution to this, the verification process itself was divided into two: a preverification which is done in the desktop development station and a simple verification by the mobile phone JVM which checks whether preverification was done earlier or not. The preverification process adds special information to the class files that identified them as preverified. This makes the process on the device more efficient.

Package

The java application that we developed is then send to the customers in the form of two files – the JAD file and the JAR file.

The JAD (Java Application Descriptor) file is a text file, which describes the application. It contains the name of the application, the version of the application, the version of CLDC and MIDP required to run the application, the location of the jar file, the jar file size etc.

The JAR (Java Archive) file is a compressed zip file, which contains all the preverified class files together with any other resources that the application requires like audio, images etc. This JAR file can be opened with any zip file handler like winzip and studied. The JAR file contains an important file called Manifest.mf. This file also contains information about the application similar to the jad file.

Test

We can test the application using the emulator available in WTK or using a real mobile device.

Using the Wireless Toolkit

Since we have studied the build process, we will see how to perform these steps using the Wireless Toolkit. It would be a good idea now, to learn bit more about the WTK.

If you installed the WTK to C:\WTK25 then these are the folders you will find there:

appdb	This directory is the root for the emulators file system.
apps	The project directory. All project are created here.
bin	Contains the binaries for the WTK itself and for other need like the compiler, emulator etc
docs	The documentation for the WTK along with API reference for CLDC and MIDP.
lib	Contains the jar files for MIDP, CLDC and a large number of optional packages.
sessions	Folder where the networking and profiling sessions are saved.
wtklib	Contains the library files (jar files) used by the WTK itself.

Now run the Wireless ToolKit as mentioned in the Installation section and select “New Project” from the menu bar.

You will get a window as shown below:

Enter the project name as “AnoopKS” and Class Name as “HelloMidlet”; then press “Create Project”. The settings window should be displayed.

Use the default settings and click ok. You can see the various messages posted on the main window:

If you go to C:\WTK25\apps\ you can see that a folder named AnoopKS have been created. All the .java files that you write should be put into the C:\WTK25\apps\AnoopKS\src folder.

Now take Notepad and copy-paste the following code into it.

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) {

}

}

Save it as HelloMidlet.java in the folder C:\WTK25\apps\AnoopKS\src. This code doesn’t do anything fancy. All it does is print “Hello World” on the WTK’s message area and exit.

Now select “Build” from the tool bar:

If you have typed the program correctly build should be success. Now you can run the application in an emulator by selecting “Run” from the tool bar.

The emulator will be displayed. Select “Launch” and you can see the string “Hello World” being displayed on the WTK messages area.

Go to C:\WTK25\apps\AnoopKS\bin directory and you can see that a JAD file have been created. But still there is no JAR file. To create JAR file select the menu: Project -> Package -> Create Package.

Java ME Beginners Tutorial: Part One

2007-08-20T14:27:00.000+05:30

This tutorial aims in teaching you Java ME technology in the simplest possible way. Please send your feedback to anoopengineer[at]gmail[dot]com.

Prerequisites

Good knowledge on Core Java a.k.a Java SE.
Sun Java Wireless Toolkit 2.5.1. See installation for details.
A Little grey matter.

What we are going to learn

Java ME (earlier known as J2ME) is for creating java programs for mobile phones (I'm lying here a bit, but it will help you). You use an ordinary Windows/Linux desktop computer to write your program, emulate its working using the toolkit, and then transfer it to a mobile phone for installing.

For this, you need to install "Sun Java Wireless Toolkit" in your desktop. The current version of the toolkit as of writing this is 2.5.1. How to get the toolkit and install it is specified in the installation section. After going through this tutorial, you should be able to create all sorts of applications on your mobile.

Installation

Prior to installing Java Wireless Toolkit (here forth called WTK), you should have Java Runtime Environment installed in your computer. The download page for WTK gives more information on these.

After installing WTK, you should get a start menu entry as shown below.

Figure 1: Start Menu entry after installing WTK

Select the option ‘Wireless Toolkit 2.5’ (in older version it is called ktoolbar) and you should see the following windows coming up:

OK, now we have everything we need to get some Java ME gyan. Let’s start.

Java ME Basics

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 two layers: Configuration and Profile. Memorize these two jargon words; you will not regret doing it when you become ‘the el33t Java ME guru’.

Configuration

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 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:

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

KVM

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.
Different form of class verification.

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

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.

How to make OpenOffice run faster in Ubuntu

2007-08-13T11:50:00.000+05:30

Some simple steps make OpenOffice snappier.

Go to Applications > Office > OpenOffice.org Word Processor

The OpenOffice.org Word Processor is launched. Go to the Tools menu and select Options.

The Options window is opened.
Highlight Memory on the left panel, change the setting as shown below.

Reduce the number of Undo steps to a figure lower than 100. Adelstein suggests 20 or 30 steps.
Under Graphics cache, set Use for OpenOffice.org to 128 MB (up from the original 6MB).
Set Memory per object to 20MB (up from the default .5MB).
Set the number of objects under Cache for inserted objects at 20.
Check OpenOffice.org Quickstarter.

Now highlight Java on the left panel, uncheck Use a Java runtime environment

Click the OK button and close OpenOffice.org. Start it up again to experience the change in speed!

Taken from http://www.zolved.com/synapse/view_content/28209/How_to_make_OpenOffice_run_faster_in_Ubuntu

Hacking OOo 2.0

2007-08-09T09:41:00.001+05:30