MemoPad

This application will allow users to edit, create, and modify an existing text files. This is not meant to edit and store extremely large text files, but is intended for short and simple text files.

Description of interface

The interface was create by using the initial notepad appliation provided from the Microsoft AppWizard. We used the application as our framework and simply added functionality to communicate with the profile server. We discuss more about using this starter application below.

Create a new document
Open an existing document
Save the current document
Delete the current document

Server interaction

To request the user profile, the application needs to send a snapshot request to the profile server (The tags will not be filled with any values but is used to inform the profile server what information is requested from the application). 

	<snapshot>
	    <memo_app>
                <id><id>
                <filename></filename>
                <text></text>
	    </memo_app>
        </snapshot>

The application should now contain the text files contained in the user's profile. In using the initial framework provided by Microsoft, these text files are stored on the OS file-system. The files will be stored in the same directory as the MemoPad executable. Using the file-system will introduce many more problems with which we will discuss later.

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

From the user:

Message sent to the server will be in the following format: 

	<update>
	    <mode>['add', 'modify', or 'delete']</mode>
	    <memo_app>
                <id><id>
                <filename></filename>
                <text></text>
	    </memo_app>
        </update>
New File
If a text file is not open, it just brings up a new text document. If a text file is open, it will it either just bring up a new text document or prompt the user to save modifications to the current text file. No communication with the server is done.

Save File
A save does not do anything to the current file. If it is a new document that has never been saved, an 'add' message update is sent to the server. If the user is saving an existing text file, a 'modify' message update is sent to the server. The file is actually altered once the server broadcasts the messages.

Delete File
A delete will not do anything to the current file. It will send a message to the server, and the delete will be handled in the broadcast from the server. This message will require only sending the file id to the server.

From the server:

Messages received from the server will be in the follwoing format: 

	<synch>
	    <mode>['add', 'modify', or 'delete']</mode>
	    <memo_app>
                <id><id>
                <filename></filename>
                <text></text>
	    </memo_app>
        </synch>
Add
A file will be created on the device's file system with the contents of the file. If application which initiated the broadcast receives this event, it will simply push the contents of the file back onto the screen. A momentary blink will occur where the file disappears then reappears. The allows us to handle a 'add' similarly to a 'modify'.

Delete
The file should exist on the devices file system. It will be deleted. If that file is currently open, the screen will be cleared and an empty document will be displayed.

Modify
If the file is not open, the existing file will be deleted and a new file will be created with the new contents. If the file is open, the new contents are pushed onto the screen to display to the user. Then then save command is automatically called to update the local file on the filesystem.

Retrospect

The MemoPad was initially developed using Microsoft's AppWizard from MSVC to create the framework. The AppWizard created the entire user interface, from the buttons to the dialog boxes. Using this interface as the starting point, the remaining implementation required communication to the server.

However, using this intial application as the starting point required us to store our files on the OS filesystem. This turned out to be a very poor implementation decision as it introduced many problems. These problems would have been resolved had we not used the file system and developed the application from scratch, storing the files in main memory.

Problem 1:
When saving a file, the user has an option of storing the file in any folder, on any disk drive. However, when a broadcast from the server occurs for a 'delete', the application will expect all files to be located at a specific directory. Since this may not be the case, the file can still exist on the device after a broadcast delete. This poses a security problem.

Problem 2:
Files are deleted once the user has properly logged on the device. However, should the application or OS prematurely quit, the files will still exist on the device, as it was not deleted. Had the files been stored in main memory, they would have been properly deleted. This is another security issue.

Unfortunately, these issues were discovered near the end of development. When we realized the impact of using the file-system, the application was virtually completed. Instead of re-developing the application, we decided to focus on the other applications.