Texting in Bangla : The Technical Analysis

My relation with the J2ME platform is somewhat old now. I have started learning J2ME on September 2004. On Fall’05 I took the course CSE-327 (Software Engineering). For the course I was looking for an idea of a project, which will be relatively small, but imposing. As I was then learning J2ME, I thought why don’t I try BanglaSMS! It will just suit my requirement. At the end of the semester the project was successfully completed. It was 13th April 2005 when the result of the project was successfully demonstrated in front of my instructor TwI (Towhidul Islam). I have a long story related to this BanglaSMS, but as this will be an off-topic, I am not going to write it now. If you want to check the software please mail me or post a comment here.
Coming back into the topic. As there are several solutions of a particular problem, a technical analysis is required before starting the project; this analysis will make sure that we are heading towards the goal in the right way. Let’s try to analyze & figure out the best solution:

Picture Message Based Solutions:
One problem of picture message based solution is one picture message is approximately equivalent to 4 text messages. So the server load for picture messages is huge. So, if anyone wants to use this solution has to pay a lot for it, unless the service provider is kind enough to reduce the tariff. In Citycell’s case they only charge taka 2 (w/o vat) per BanglaSMS. Another problem is, as the user does not have a Bangla interface for writing & editing text messages, it creates ambiguity & difficulty. So, the scope of this solution is very limited.

Application Based Solution:
Most of the new generation mobile phones supports 3rd party application installation. Two popular platforms for developing application for handheld devices are 1. Symbian & 2. J2ME. Though Symbian C++ is more flexible & powerful, J2ME is surely the best when compatibility is considered. For BanglaSMS J2ME is the right choice as there are many Java supported mobile phones are available in the market and all the upcoming mobile phones will be also Java enabled for sure. There are two different profiles (API Sets) available for the J2ME developers: MIDP 1.0 & MIDP 2.0. MIDP 1.0 is designed for low-end handsets where the resources are very limited. Whereas the MIDP 2.0 contains some advance classes that are designed for high-end handsets where the resources are not that much a problem. For developing BanglaSMS we must need two APIs namely
1. PushRegistry API :
This API is used when an auto invocation of a program is needed without user initiation. The BanglaSMS software must need this API, because the user must be notified on SMS arrival & the program must be launched automatically. PushRegistry API is a core part of the MIDP 2.0 API.
2. WMA (Wireless Messaging API) :
This API provides classes that will enable an application to send & receive messages. There are some alternatives of this API like Nokia’s messaging API, but they are very much platform dependent. Though WMA is not a core part of the MIDP 2.0, all of the MIDP 2.0 handsets have this additional API. BanglaSMS software also needs this API to ensure the SMS communication between different handsets of different vendors. So, the highest level of compatibility can be gained when the BanglaSMS application is developed for the J2ME platform, more specifically using the MIDP 2.0 profile.

There are some constraints that also should be taken into consideration while developing BanglaSMS: The application size must be less than 128 KB to maximize compatibility. MIDP 2.0 handsets support max-jar-size of 128 KB or higher. Using relational algebra’s aggregate function min this can be expressed as, G_{min(max-jar-size)}(handsets) = 128 KB ( just joking!).

Using UCS-2 for SMS is unnecessary as most of the mobile service providers do not support UCS-2 & also most of the mobile phones nor support Unicode neither have Bangla font. Moreover an UCS-2 text SMS cannot have more than 80 (not sure, approximately) characters per SMS. The application so must use GSM-7 bit encoding. GSM-7 bit is the regular encoding for text SMS, this encoding is a little bit different than ASCII. ASCII cannot be used for SMS communication because some of the ASCII characters are not supported in GSM-7bit and many of the ASCII characters are represented using 2 GSM-7 bit characters. So, there is a scope for non-fatal bug’s existence in the application if GSM-7 bit encoding is not used. Mobile handsets commonly have only 12 num-keys. So creating a good UI is a ‘matter of research’ rather than ‘creative stuff’.

So, the design & implementation constraints are:
Þ There is no way of installing/changing fonts in a mobile device by an application that is running on that device.
Þ The keyboard of a usual mobile phone has only 12 keys for alphanumeric character inputs while Bangla has over 250 letters including conjuncts.
Þ Generally, the GSM3.38 (7bit) character set is used for handling SMS by a network. So, at most 128 characters can be supported. Two GSM-7 bit characters can be used to represent one conjunct (following common escape method), thus the domain of supported conjuncts can be increased.