|applications d'entreprise :: business apps
mobile payment concept
mobile chat platform
|Understanding the various types of mobile chat technologies
Originally requiring an IRC client, text messaging has become more popular with the web and easy chat websites with java and/or flash applets. It also gained popularity through wide-spread instant-messaging applications such as ICQ, AIM, MSN or Yahoo's IM.
Moving this new habit onto a mobile platform is quite an endeavour. Most operators offer today solutions based on XHTML/WML. WAP chat has been talked about a lot, but nearly one uses it. Why? Why do most end-users act as if it did not exist ?
The short answer is: confort, features and pricing. But this can be explained in detail by analyzing the several generations of technology that have been available on mobile devices.
Being the first one and still the most widely available, this kind of chat technology is also very dated and lacks many features one would ask to consider it actually usable. It is suitable for a casual one-to-one communication but becomes very confusing when several people try to communicate together or when the conversation last longer than a few sentences. This service is also rather expensive for the consumer, especially in groups. Each message costs the price of one SMS multiplied by the number of listeners. The time between each send/receive operation can be several seconds, making it the slowest chat system in addition to the most expensive. Yet, it is still the most widely used.
WML / XHTML Chat
When the basic internet navigation technology, known as WAP, was made available for mobile devices, chatting became one the first applications to come to developer's mind. However chatting via WAP, that is displaying XHTML or WML pages, has several disadvantages :
- No real time. The user has to constantly reload the page to see if anyone has posted new messages. On recent phones, this reloading is done automatically but it blocks any user input and reading during this time, making the experience awful.
- Every new action requires reloading lots of data (pages, smileys), increasing both price and feeling of lagginess.
- Clunky, inconsistent interface. Every phone has it's own layout and it won't be easy to write XHTML or WML code that will be consistent among all devices, with different screen sizes, while keeping the user-experience simple and flawless. Generally the only phones that have decent XHTML support are the ones that also feature java.
J2ME (Java 2 Micro Edition) 1.0 Chat, through HTTP Gateway
Now, it becomes interesting! The third generation came with Java MIDP 1.0 compatible devices. Those are able to open an HTTP connection to a webserver and parse the incoming data. Unlike WML/XHTML this technology allows for a handmade user-interface design, through java programming, that will feel consistent among most devices. The application could have locally-stored smileys and sounds, greatly reducing traffic and lagginess.
A MIDP 1.0 chat application is also able to reload messages on the server automatically without user intervention and as opposed to XHTML/WML chat without interrupting the users actions (reading, writing). But MIDP 1.0 communication is not perfect. Since it is done through HTTP, it is one-way only. This means the application still has to regularly ask (in the background) the server for new messages. This creates delays in received message and also greatly increases traffic amount.
For example if the application wants to get the messages from the server every 10 seconds, a request for updated messages would have to be sent every 10 second, even if no messages were written in that time. Decreasing the lag time from say, 10 to 2 seconds, would multiply the traffic by five. One has to keep a reasonable delay in order to both keep costs limited and also not hammer the server continuously with useless requests.
MIDP 1.0 did not support sound. But many manufacturers such as Nokia, Siemens, SonyEricsson have made APIs to play sounds in various formats. Link-u mobile already has written support for most common proprietary sound APIs.
J2ME (Java 2 Micro Edition) 2.0 Chat, through Direct Socket Connection
That's when it becomes even more interesting! The second version of Java 2 Micro Edition, MIDP 2.0, finally allows programming a mobile phone to do nearly anything your computer could do.
Thanks to added support for network sockets, communication is now possible on a two-way scheme without continuous polling. This means that as soon as the java server receives a message from one participant it'll forward it without delay to one or multiple others. In others words, this is just like chatting from your computer using your favourite IM client or website. It is Real-Time!
In addition to this MIDP 2.0 compatibility brought other great features:
- Normalized media system (all phones can play MIDI sounds and more!)
- Ability to capture still images from java applications. In other words one user could take a picture on his phone and send it immediately to one or several other chatters, without having to know their phone numbers or use MMS.
- Direct Pixel Access, allows for special graphical effects, that MIDP 1.0 phones couldn't do, enhancing visual experience.