Perry Wang - Project Portfolio

The undo and redo feature allows users to undo and redo their previous commands. The commands that can be undone are only those that modify the contents of the address book or event list, such as adding a person or event within the app. This is managed within ModelManager.

The undo/redo mechanism is implemented separately for the address book and event list by the VersionedAddressBook and VersionedEventList. They are extensions of the superclass AddressBook and EventList respectively with a history of states stored internally as an addressBookStateList for the address book, eventListStateList for the event list, and a currentStatePointer in each of them. To ensure that the address book and event list are undone/redone correctly, a StateHistoryList (sub-class of LinkedList) is kept in the ModelManager to keep track of the list that was modified.

The following operations were implemented:

These operations are exposed in the Model interface as Model#commitAddressBook(), Model#undoAddressBook() and Model#redoAddressBook() for the address book, and Model#commitEventList(), Model#undoEventList() and Model#redoEventList() for the event list. Two wrapper methods, Model#undo() and Model#redo() are also implemented. These will be the methods called by the commands undo and redo.

The StateHistoryList implements the following operations for the Model to decide whether to undo/redo the address book or event list:

A command can either modify the address book, event list, or both. Within the model, the StateHistoryList keeps track of all model methods which modify the address book or event list, and stores a history record value within itself for each method called.

When undoing a command, the ModelManager requests for the latest record by StateHistoryList#getCurrentState() and calls the corresponding VersionedAddressBook#undo() and/or VersionedEventList#undo(). The ModelManager also informs the StateHistoryList that an undo command was issued to shift the pointer back.

When redoing a command,the ModelManager requests for the next record from StateHistoryList and calls the corresponding VersionedAddressBook#redo() and/or VersionedEventList#redo(). The ModelManager also informs the StateHistoryList that an undo command was issued to shift the pointer forward.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The VersionedAddressBook and VersionedEventList will be initialized with the initial address book and event list states, and the currentStatePointers will point to their single state respectively. The StateHistoryList is instantiated as an empty list.

Step 2. The user executes add (with valid input arguments) to add a person to the address book. The add command calls Model#addPerson(), which will add a state record index integer STATE_ADDRESSBOOK to the StateHistoryList. This command is the last entered command, therefore the pointer in StateHistoryList shifts forward. The add command also calls Model#commitAddressBook(), causing the modified state of the address book after the add command executes to be saved in the addressBookStateList, and the address book currentStatePointer is shifted to the newly inserted address book state. The currentStatePointer for VersionedEventList remains unchanged as only the VersionedAddressBook was modified..

Step 3. The user realises that they have accidentally added the wrong person, and decides to undo the action by executing the undo command. The undo command calls Model#undo(), which gets the latest record state from StateHistoryList and recognises that the VersionedAddressBook was modified in the previous command. The Model#undoAddressBook() is then called, which shift the currentStatePointer once to the left, pointing it to the previous address book state, and restores the address book to that state. Also, the pointer in StateHistoryList is shifted to the left by StateHistoryList#decrementPointer.

The following sequence diagram shows how the undo operation works:

Step 4. The redo command does the opposite — it calls Model#redo(), which shifts the currentStatePointer in either the VersionedAddressBook and/or VersionedEventList once to the right, pointing to the previously undone state, and restores it to that state.

Step 5. The user then decides to add a new event to the event list, by the addEvent command. The addEvent command calls Model#addEvent(), which will add a state record index integer STATE_EVENTLIST to the StateHistoryList. This command is the last entered command, therefore the pointer in StateHistoryList shifts forward. The addEvent command also calls Model#commitEventList(), causing the modified state of the event list after the addEvent command executes to be saved in the eventListStateList, and the event list currentStatePointer is shifted to the newly inserted address book state. The currentStatePointer for VersionedAddressBook remains unchanged as only the VersionedEventList was modified.

Step 6. The user then decides to execute clear. Since this command must clear both the address book and event list, the clear command calls both Model#commitAddressBook() and Model#commitEventList(). It adds a state record index integer STATE_BOTH to the StateHistoryList. The currentStatePointer in both VersionedAddressBook and VersionedEventList shifts to point to the newly added states respectively.