ToDo

This application allows users to keep track of tasks. These tasks include a description, a priority level (1 through 9, with 1 being the highest priority), and a boolean value indicating whether the task has been completed or not. Every task can be edited or deleted.

Description of interface

The interface is created using the framework provided by the Microsoft Foundation Classes. The main ToDo interface window is a SDI doc/view application with the view class derived from CFormView to allow a dialog template to be embedded in the view. The view contains a single CListCtrl object. In the Windows 98/2000 version, there are also three push buttons below the CListCtrl object. The list has three colums, representing the description, priority, and status of the task. The three buttons represent functionality to add, delete, or modify an entry in the list ctrl. In WinCE, these buttons are absent. However, all three functions can be accessed via menus in both versions.

The application's main menu consists of 1 submenu titled "ToDo" and this submenu contains two items, "Exit", and "Add", which are self explanatory. To delete or edit an entry, the user must right click (tap and hold on WinCE) on the entry that they want to delete or edit. This is done by responding to the WM_CONTEXTMENU messages. MSVC 6.0 can do this automatically for you in the ClassWizard, but the Embedded Visual C++ (as of version 1.0) has a few bugs. Among these bugs is the inability to override the handling of some messages, including the WM_CONTEXTMENU message. However, this is simply solved by making the changes manually instead of going through ClassWizard.

The main list control is automatically sorted by the priority (highest priority first). If the user changes the priority of an entry, it is automatically moved to the correct position.

Adding or editing a task involves bringing up a new dialog. This dialog allows to user to enter the description, choose the priority, and check/uncheck the done box.

Server interaction

To request the user profile, the application needs to send a snapshot request to the profile server. All that is sent is the snapshot message and a blank todo_app message inside it as follows. 

	<snapshot>
	    <todo_app>
	    </todo_app>
        </snapshot>
The server should send back a series of snapshot messages each contains one of the user's entries. If the user has no tasks at the time, no snapshot is sent. The message should look like the following: 
	<snapshot>
	    <todo_app>
	        <id>[The ID]</id>
	        <done>[true/false]</done>
	        <priority>[The priority]</priority>
	        <text>[The description]</text>
	    </todo_app>
        </snapshot>
NOTE: None of the server messages that applications receives are null terminated. Therefore, more than one snapshot (or any other message) could be in a message string received by the app. In addition, for the case of synch broadcast messages, it is NOT guaranteed that each application will only receive messages meant for it. If the user has applications open across several devices, it can be expected that applications will receives messages meant for other apps and each app is responsible for filtering this out.

After the snapshots have been received,the application should now have showing all of the tasks that the user has stored. This is stored in the program's memory, unlike the MemoPad message.

We will describe below how the application handles certain events.

From the background app:

Login

If the background app sends a user id message, the application will attempt to contact the profile server and log in that user id. If the server acknowledges and accepts the request, the user interface of the application will be exposed (the main list and buttons are initally hidden, and the menu items disabled).

Logoff

Application will send logoff message to profile server, close the socket, then close the program (note that this is done by sending a WM_CLOSE to the main window).

From the user:

NOTE: None of these commands will actually do anything with the data. They will send a message to the server and wait for the server broadcast to add/delete/modify an entry.

Add
The Add Entry dialog will be brought up with the description blank, the priority set at 5, and the done box unchecked. If the user clicks on ok to add this entry, the application will send a update message to the server. Format of update message is as follows: (basically identical to the synch messages) 

	<update>
	    <mode>add</mode>
	    <todo_app>
	        <id>[The ID]</id>
	        <done>[true/false]</done>
	        <priority>[The priority]</priority>
	        <text>[The description]</text>
	    </todo_app>
        </update>

Delete
A messagebox will be shown asking the user if they are sure they want to delete the entry. If they click ok, the delete message will be sent to the server. In the delete message, only the id is sent as only the id is pertinent.

Modify
The Edit Entry dialog, which is identical to the Add Entry dialog except for the title will be brought up and the values of the description, priority, and done box are automatically set according to the current entry values. When the edit dialog is closed, the changes will be sent to the server.

From the server:

Add
The Entry is added. Format of the synch message from server is as follows: 
	<synch>
	    <mode>add</mode>
	    <todo_app>
	        <id>[The ID]</id>
	        <done>[true/false]</done>
	        <priority>[The priority]</priority>
	        <text>[The description]</text>
	    </todo_app>
        </synch>

Delete
The Entry is deleted, format of synch message from server is as follows: Note at the ONLY the ID is expected 
	<synch>
	    <mode>delete</mode>
	    <todo_app>
	        <id>[The ID]</id>
	    </todo_app>
        </synch>

Modify
The entry is automatically updated. Format of message is same as format of add entry update message, except that the mode is "modify" instead of "add".

Retrospect

I believe that there is not much about the ToDo application that I would have do differently. I guess in this case, foresight was 20/20 also. I think that the application turned out well in its features and simplicity of use. This same interface style is also used by the Contact List application, which unfortunatelly was "scrapped" ;-).

As far as doing things differently, the only thing that I can think up is that to allow third party vendor to build applications, a better API should have been provided in communicating with the Background app as well as the profile server. But this doesn't really have anything to do with the ToDo application.