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.

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.

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

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

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

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

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.

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.