As one of the design goal is to develop a abstraction over varius protocols, the architechure encapsulates three types of packages,- first one for handling the protocol level workouts providing protocol independent way of actions, second one for user interface, and the last one is the protocol implementation itself. They are packaged under miniim.common, miniim.ui and miniim.plugins respectively.
The following diagram gives a high level overview of the architecture.
+-----------+ +---------------+
o | |<------| |
/ \ | | | |
| -------->| miniim.ui |------>| miniim.common |
| | | | |<-----+
| <--------| | +->| | |
| +-----------+ | +---------------+ |
/ \ | |
user | |
| |
+-----------------|----------------------+ |
| | | |
| +-------------- | |
| miniim.plugin | | |
| | | |
| ---------------------- | | |
o | | |<-- | |
/ \ | | miniim.plugins.xmpp| | |
| --------------->| | | |
| | | | | |
| <---------------| | | |
| | ---------------------- | |
/ \ | | |
| ------------------------ | |
remote | | |<------+
xmpp | | | | o
server | | | | / \
| | miniim.plugins.yahoo |<------ |
| | | | |
| | |------> |
| | | | |
| ------------------------ | / \
| | remote
| | yahoo
| | server
+----------------------------------------+
The miniim.common consists of some core storage constructs to keep the basic data. The data consists of both the protocol independent data and the protocol dependent ones. The storage constructs are Account and Buddy.
To make it easier to plug new protocols there are some API concepts. These concepts are IMProtocol, IMMessage, IMPresence, IMCommand, IMStateChangeListener, MessageListener and PresenceListener.
The account contains the user recognition information over a specific service. This kind of information is protocol dependent and they are kept in a HashTable. They are mapped as key to value. One of the example of protocol dependent data serialization is found in Pidgin account header (in C code, they are implemented with GHashTable of glib library).
Some of the common account attribute required in most of the cases are username, password and protocol type.
Besides the storage capability the account also contains some actions as connect and disconnect to server , setting client state, message and presence listeners.
The account storage is designed to be reusable. It contains factory method getInstance to get a usable instance and destroy to make it reusable. There are restrictions of the maximum number of accounts that can be used at a time. This is because they are allocated statically. Dynamic storage like Vector in J2ME contains thread safe feature making it very costly to use.
A buddy is another user of messaging service. It is associated with a specific account. Buddy also has common attribues as username, status and associated account. Like account it also has some protocol and ui specific data saved in a HashTable.
There are messages saved in a circular queue in the buddy. They are the conversation history.
Buddy actions consists of sending message.
Unlike the account, multiple buddy is managed with a single vector. This is because the number of buddies varies more rapidly than the number of accounts.
IMProtocol contains the connect, disconnect, destroy and sendMessage actions that are enforced to be implemented in the protocol code.
To notify the external events there are three listeners IMStateChangeListener ,MessageListener and PresenceListener that are supported in IMProtocol implementation.
Again, the client activity is enforced to be done in separate thread. The thread communication is done using asynchronous queue. Commands from external thread are issued in the queue. To support this there are two methods push and pop implemented in IMProtocol.
IMMessage consists of sender,receiver and a message body storage. There are no actions defined here.
IMPresence consists of the associated buddy. Like IMMessage there are no actions defined.
IMCommand is the construct of the command to pass to the client thread. It consists of some basic command types as Connect, Disconnect and Send message.
It also recommended to keep a storage for data related to a specific command.
IMStateChangeListener notifies the client state changes. MessageListener notifies both message send and receive events. PresenceListener notifies presence state change of the buddies.
Note that the notification of these events are done from the protocol thread. So there is need of external synchronization of the notification tasks.
Unlike commonly practiced idea of allowing multiple listeners of each event (like message receive) from each event source ( an open connection ) , here only one listener is permitted. This is done to make it lightweight.
User interface consists of user friendly way of issueing the actions described in the core concepts and viewing the output. Like the core concepts this part also has some platform imposed restrictions. The interface has three visible parts mapped into four code segments.
This is reusable user interface for account information input. As shown below there are the fields as Name, Password and Profile for input and related commands as Connect/Disconnect,OK,Cancel and Delete. This is considered as the view part of the Account storage model.
+------------------------+
| Account - Anonymous |
|------------------------|
| |
| Name : Anonymous |
| Pass : ********* |
| Profile: jabber |
| |
| |
| |
+------------------------+
Connect/Disconnect,OK Cancel,delete
This shows the accounts. There are commands as View details of an existing account, Create new account and Back.
+--------------------+
| Account List |
|--------------------|
| Waheed |
| Hasan |
| .... |
| .... |
| |
| |
| |
| |
| |
| |
+--------------------+
Back Create New,Details
This is a dialog where to write messages and view others from the remote users. It contains Write and Back commands. The Previous and Next commands are for switching the remote user whome to write to.
+------------------------+
| Conversation- anony.. |
|------------------------|
| |
| Salehin: Hi |
| Me : Hi |
| .... |
| .... |
| .... |
| .... |
+------------------------+
Previous,Write Next,Back
Buddy list is the dialog showing the buddies associated to the connected accounts. Additionally the status of active connections. The buddy list is the main window that have the commands to switch to diffetent dialogs.
+----------------------------+
| Buddy List |
|----------------------------|
| Salehin online |
| Shuva away |
| |
| |
| |
|----------------------------|
| Connected |
+----------------------------+
Quit,Account Write,Accounts
Protocol implementation as simple as defining the enforced methods of IMProtocol, IMCommand. Additionally it can extend IMPresence, IMMessage to accomodate protocol specific demands.
One example implementation is the miniim.plugins.xmpp package. This enables communication to xmpp protocol supported messanger servers.