Misc

Maintaining different profiles

The profile is the relation of server and protocol. The profile contains a protocol type and server specification. Server specification includes server ip, port and it's ability and other protocol specific attributes.

Platform restrictions

This program is designed for J2ME. The MIDP2 API is one of the requirement. J2ME is demanded to be " the most ubiquitous application platform for mobile devices across the globe" by the inventors. Ofcourse it is the most popular one for mobile devices. Though the implementation of the APIs are fragmented over different devices. Applications designed for the APIs needs to be JDK1.1 complient. And they are expected to be lightweight.

Using External Library

Efficient application for this platform consumes less memory when they are deployed in "jar"s. This requires unused codes to be truncated. This has a conflict to the use of external libraries. External libraries make it faster to develop using the idea of code reuse. On the other hand they introduce unused codes. Using obfuscation removes much of the pain of using external libraries.

This project uses "lcrypto-j2me" from bouncycastle organization for tls implementation and kxml as the implementation of xmlpullparser. These two are needed for implementing xmpp protocol. Finally the project is obfuscated with "proguard".

Interface Design

The user interface here is designed using the "Form"s of MIDP2 API. Each form requires a separate storage to keep display data. To make it possible to use smaller heap it is needed to use less or a static number of form. The Account Dialog, Account List Dialog, Conversation and Buddy List are separate forms and they are singletons. Thus they are reusable. So the total form count is four which is acceptable of course.

Other possible way of interfacing user is to use external libraries upon the MIDP2's "Canvas". The are food for future thinking.

Threads

The events from the user interface is dispatched from the main thread. To make it feel effecient there are threads maintained for each connection. The idea is to do background job while being interactive to user. The communication basic is shown below.

       main/application thread                               Connection Thread

                |                                                    |
      o  typing |                                                    |
     / \ ------>|                                                    | waiting
for
      |         |              push sendMessage command              |
commands
     / \        |--------------------------------------------------->|
                |                                                    |
           processing other                                    pops the
command
            user commands                                            |
                |                                                    |
connecting
                |                                                    |
                |                                                 connected
                |                                             show the status
                |                                                    |
                |                                                    |
</code>