Instant Messenger

This application will allows users of our system to send short messages between users. If the user is holding a scrap device with IM currently running, messages will instantaneously appear. If the user is currently not online, the message will be queued up, waiting to read the next the user logs on.

Description of interface

The application's main dialog box will contain a list of all users within the network. We do not distinguish between users that are online or offline. This was intended to simplify our application. If we maintained a separate list of online and offline users, the server would need to broadcast to all users when users log on and log off the system.

Sending a message

This can be done in two methods. The first method requires the user to select a person and press the send button. The second method allows the user to double click on the the persons name. The only restriction with this method is that there must NOT be an messages queued for that person.

Receiving a message

This is very similar to sending a message and can be done in two methods. The first method requires the user to select a person and press the receive button. The second method allows the user to double click on the persons name. Again the restriction is that there MUST be message queued up for that person.

Informing user that messages are queued

If a message is waiting to be read originating from another user, that persons name will be displayed in the following format:
Video Wall - The name of the person will be highlighted red.
Compaq iPaq - An asterisk will exist immediately after the name of the person.

It is displayed differently on the two platforms due to the limited implementation of the CListBox for Windows CE. It currently does not support any owner-drawn boxes. Therefore, we could not visually highlight a person's name for the Compaq iPaq.

Server Interaction

In order to receive the user profile, a snapshot request must be sent to the server (The tags will not be filled with any values but is used to inform the profile server what information is requested by the application). 

	<snapshot>
	    <message_app>
	        <id></id>
	        <fromid></fromid>
	        <from></from>
	        <text></text>
	    </message_app> 
	</snapshot>

The application should now contain the user profile for this application. The profile consists of all messages destined for the user. A local copy of the messages are stored in a queue, waiting to be read. Each person on the IM list has its own queue, containing messages orignating from that person.

We describe below how the application handles certain events from the server or the user.

From the user:

Sending a new message
No change to the application. An 'add' message update is sent to the server to be broadcasted to the destined user. It will be sent in the following format: 

	<update>
            <mode>add</mode>
	    <message_app>
	        <fromid></fromid>
	        <text></text>
	    </message_app> 
	</update>

Reading an existing message
The current message is deleted locally from the queue. A 'delete' message update will also be sent to the server to inform other instances of the IM that the message has been read. More on this is explained below. The message format sent will be in the following format: 

	<update>
            <mode>delete</mode>
	    <message_app>
	        <id></id>
	    </message_app> 
	</update>
The message is identified by the record id.

From the server:

Add
The new message has just been sent originating from another user, destined for you. It will be identified by the 'from' tag. The message will be queued up on the 'from' persons queue, waiting to be read by the user. The message received will be in the following format: 

	<synch>
            <mode>add</mode>
	    <message_app>
	        <id></id>
	        <fromid></fromid>
	        <from></from>
	        <text></text>
	    </message_app> 
	</synch>
Delete
An existing message has been read and must be removed from the queue. This event is only applicable if the same user has two instant messenger applications open at the same moment.
One instance of the app: The message has already been deleted when it was read. This event is ignored.
Multiple instances of the app: The message is deleted from the message queue of the 'from' user.

The message received will be in the following format: 

	<synch>
            <mode>delete</mode>
	    <message_app>
	        <id></id>
	    </message_app> 
	</synch>
Modify
This event will never be sent from the server for the instant messenger application. In this case, it is not applicable.

Retrospective

The functionality of application is exactly as we had wanted. From that point of view, nothing really needs to be changed. However, the user interface is quite boring compared to the other instant messenger applications available on the market. Making this application more user friendly by 'spicing' up the UI could be done if we had more time.