A Mobile MSN Project

by Mehmet Ecevit


The Mobile MSN Application, I will try to tell you in here, is a project called "tJOP-tJOP" that I have coded for a Dutch Company: "OurCompany". It runs on almost every phone (Midp 1.0, Midp 2.0, Symbian). In this white paper, I would like to share the 13-month-story of a pure Java project that contains various Java technologies (j2me, j2ee etc.) and how the NetBeans IDE helped me.

The Application

How it works

As I mentioned above, the project is an MSN clone for mobile phones. The application connects users to their real MSN contacts and provides the ability to chat with them. This solution should be cheap to use and available for back end users. So, instead of connecting the user directly to the MSN protocol over a socket connection, I have decided to put a custom protocol between the clients and MSN protocol. I have translated all the official MSN protocol commands into smaller ones. So these smaller commands make it possible to say hello with 8 bytes instead of 147 bytes.
To say “hello”:

Official Msn Protocol Command

MSG 4 N 133\r\n
MIME-Version: 1.0\r\n
Content-Type: text/plain; charset=UTF-8\r\n
X-MMS-IM-Format: FN=Arial; EF=I; CO=0; CS=0; PF=22\r\n

My Custom Protocol Command


To achieve and also support this, now we need to study the communication.

Client-Server communication

As you know, j2me has 2 platforms: Midp 1.0 and Midp 2.0. While Midp 1.0 is capable of http connections, Midp 2.0 is capable of both http and socket connections. Lets take a quick look at these network technologies. Http protocol is easy to use but it contains headers that increase the usage of traffic. Even if you send one byte to the server, and the server responds with one byte, that does not mean you have spent 2 bytes for this communication. While sending one byte to the server, a j2me phone sends headers which take up almost 200-300 bytes. This is the same for the server: it sends headers too. But sockets do not behave like that. After a succesful connection, socket connections just send what we send, no extra headers. So I have coded two different builds:

  • Midp 1.0 (with Http Data Connector)
  • Midp 2.0 (with Socket Data Connector)

After deciding on these builds, it became clear what modules I needed.


In this part, we will take a look at the modules of the application. (In the order of coding)

  • MSN Gateway Module (Server
  • Socket Server Module (For Midp 2.0)
  • Client Module (Client)
  • Midp 1.0
  • Midp 2.0

MSN Gateway Module (Server)

This module is the main part of the project. This module, which I have named MSN Gateway, is a simple web application. It runs on Apache Tomcat and is directly connected to the Official Msn Protocol. The important part is, all the socket connections, created by the users from the client, are hosted in this module, where my custom protocol’s mission begins.

In the MSN protocol, every session (dialog with a user, sending file) takes place in different connections. For example, if you want to talk to someone, you should first open a new socket connection. So this mean that there a need for implementing a socket pool.
So this module creates a pool for all the socket connections for a single user. And when the user wants to send a message, the custom protocol identifies the user, gets the right socket connection from the pool, and writes the required bytes to that connection.

Socket Server Module

In fact this is not one of the main modules but needed to be mentioned. This server, connects the midp 2.0 and symbian phones to my custom protocol. As I've mentioned, midp 2.0 and symbian builds use a socket connection so this server is a pipeline between the client and the MSN gateway.

Client Module

The Client Module was the most challenging part of the project and as you may have guessed, I spent the most time on this module. The Client should run the following tasks:

  • Connection: Persistent connection to custom protocol.
  • UI: Advanced UI for better navigation and chat platform.
  • Compatibility: Compatible with all j2me phones.

Connection: The connection should be persistent. This is really easy for socket connection but in HTTP connections I needed to do some additional things.
HTTP Connection: HTTP connections gives you the ability to make one request per connection. (I have not succeeded in using the Keep-Alive feature of HTTP.) So, to make these separate connections persistent, I have implemented a custom cookie manager. After a succesful connection to my custom protocol, it sends a cookie value, and the client keeps that for the other requests. So, in every request of the client, the server recognizes the client.
Socket Connection: Socket connections are persistent. I did not need to implement anything for this type of connection.
UI: For smiley support, group view, scrolling the conversation and much more I have used low level APIs to produce the user interface.

Image:tjoptjop1_MobileMsnProject.gif Image:tjoptjop2_MobileMsnProject.gif Image:tjoptjop3_MobileMsnProject.gif

Compatibility: To make the application compatible for most mobile phones, I have tried not to use specific packages. Besides this, every phone has specific properties like keymapping or a specific package. So I needed different builds for some phones. To achieve this, I created different builds within a single project with the help of “Preprocessor Blocks” that comes with the NetBeans IDE.
After achieving all these factors, the client could run on midp 1.0, midp 2.0, and the symbian OS very efficiently. Here is a visual presentation of the modules:


In this white paper, I hope I was able to give you some ideas about what challenges you may face during a (mobile) project, how NetBeans can help you, and why decisions are important before starting to code.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo