PROJECT: EventsPlus+

Overview

EventsPlus+ is a Command Line Interface (CLI) desktop address book application catered for busy university students to manage their contacts, events, project meetings and ad-hoc events efficiently. It aims to simplify some of the more time-consuming administrative tasks such as coordinating location and date of ad-hoc events. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has more than 10 kLoC.

Summary of contributions

  • Code contributed: [RepoSense]

  • Major enhancement: added the Notification/Favourite feature

    • What it does: Allows the user to enable/disable a welcome notification upon application startup. Moreoever, users can favourite an event so that the welcome message will display details of the event.

    • Justification: Busy users should have a convenient means to remind themselves of an upcoming event.

    • Highlights: If a favourite event is deleted, and notification is enabled, the welcome notification will display a default welcome message instead of the events of a deleted event.

  • Other contributions:

    • added the toggle command

      • What it does: CLI command which allows user to switch UI tabs.

      • Justification: Allow proficient users to navigate the UI solely using CLI.

    • Project management:

      • Setup "About Us" documentation

      • Managed releases v1.3 on GitHub

    • Enhancements to existing features:

    • Documentation:

    • Community:

      • Reported bugs and suggestions for other teams in the class (1, 2, 3, 4, 5, 6

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Notifications: notification, alias n

Allow users to enable/disable notifications which appears upon application statrup. Notification is enabled by default.

Format: notification enable/disable

Examples:

  • notification disable

Favourite: favourite, alias fv

Allow users to favourite a upcoming events based on most recently displayed events list. Favourite is null by default.

Format: favourite d/DATE i/EVENT_INDEX

Examples:

  • favourite d/2018-04-01 i/1

Toggling UI tabs : toggle, alias t

Format: toggle

Undo/Redo commands will not undo/redo the toggle command.

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Enable/Disable Notification feature

Current Implementation

Notification preference is stored in the preferences.json file. The notification mechanism is facilitated by Javafx. Upon startup, notification preference is loaded from preferences.json and saved to the ModelManager. Upon exit, the model’s notification preference is saved to preferences.json to ensure statefulness. When enabled, it creates a child stage and scene from the main window and displays with a countdown timer to automatically close the stage. Additionally, it implements the following operations

  • ui#NotificationWindow() — creates the stage and scene for the notification using 2 String inputs: title and message

  • logic#parser#NotificationCommandParser() — creates a NotificationCommand object based on user’s input

  • logic#commands#NotificationCommand() — updates the ModelManager’s notificationPref attribute.

Given below is an example usage scenario and how the enable/disable notification mechanism behaves at each step.

Step 1. The user launches the application for the first time. The model’s notification preference is initally enabled, the notification window appears.

Step 2. The user executes notification disable. The notification command calls NotificationCommandParser which converts disable into the boolean false and creates a new Notification Command which updates the Model’s notification preference to false.

The notification command will update the notification preference regardless of whether the new preference is same as the previous preference.

Design Considerations

Aspect: How notification preferences is updated

  • Alternative 1 (current choice): Re-assign Model’s notification preference regardless of previous preference

    • Pros: Easy to implement.

    • Cons: Wasteful in the case of same notification preference.

  • Alternative 2: Check current notification preference and only assign new value if it is different from the previous value.

    • Pros: Do not waste computing cycles on unecessary re-assingment of notification preference.

    • Cons: Code becomes more complicated because additional check required.

Aspect: Writing to preferences.json

  • Alternative 1 (current choice): Write all Model preferences to preferences.json

    • Pros: Easy to implement.

    • Cons: Unecessary computing cycles wasted on writing when possibly no change

  • Alternative 2: Check for difference between Model preferences and preferences.json, only write to preferences.json if there is difference.

    • Pros: Efficient.

    • Cons: Code becomes more complicated because additional check required === Select an existing event to be detailed in the notification if notification is enabled. ==== Current Implementation

Details of favourite event (i.e. event name, date, day, time, details) stored as a String "Favourite" in preferences.json file. The favourite mechanism is implemented through the ModelManager. Upon startup, if notification is enabled, and there is a String "favourite" in preferences.json is non-null, the notification will display the String "favourite". "Favourite" in preferences.json is also loaded into ModelManager. Upon executing FavouriteCommand, the event is selected based on the input parameters and the filteredEventsListByDate. The attributes of the event is formatted into a String and saved to the ModelManager. Upon exit, the formatted String in ModelManager is saved to preferences.json to ensure statefulness.

  • logic#parser#FavouriteCommandParser() — creates a FavouriteCommand object based on user’s inputs.

  • logic#commands#FavouriteCommand() — updates the ModelManager’s favouriteEvent attribute.

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

Step 1. The user launches the application for the first time. The model’s favouriteEvent attribute is initially null.

Step 2. The user executes favourite d/2018-04-01 i/1. The favourite command calls FavouriteCommandParser which checks validity of user inputs and creates a new FavouriteCommand which selects the event and create a formatted String from the event details.

The favourite command will update favouriteEvent regardless of whether the new favouriteEvent String is the same as the existing String.

Design Considerations

Aspect: How favourite is updated

  • Alternative 1 (current choice): Re-assign Model’s favouriteEvent regardless of previous preference

    • Pros: Easy to implement.

    • Cons: Wasteful in the case of same favorite event.

  • Alternative 2: Check current favouriteEvent and only assign new value if it is different from the previous value.

    • Pros: Do not waste computing cycles on unecessary re-assingment of favouriteEvent.

    • Cons: Code becomes more complicated because additional check required.

Aspect: Writing to preferences.json

  • Alternative 1 (current choice): Write all Model preferences to preferences.json

    • Pros: Easy to implement.

    • Cons: Unecessary computing cycles wasted on writing when possibly no change

  • Alternative 2: Check for difference between Model preferences and preferences.json, only write to preferences.json if there is difference.

    • Pros: Efficient.

    • Cons: Code becomes more complicated because additional check required === Toggles the UI tab to the tab on its right. ==== Current Implementation

Toggle command raises a TabPanelSelectionChangedEvent event through the ModelManager. The tab panel is subscribed to this event and will loop the tabList and change the selected tab to its adjacent tab when the event is raised.

  • logic#parser#ToggleCommandParser() — creates a ToggleCommand object.

  • logic#commands#ToggleCommand() — raises a TabPanelSelectionChangedEvent through the ModelManager.

ToggleCommand is not compatible with undo/redo since there is no writing of data to storage.

Design Considerations

Aspect: How change of UI tab is executed

  • Alternative 1 (current choice): TabPanel subscribe to an event which will be raised by ToggleCommand

    • Pros: Convenient to implement.

    • Cons: Creates a new object and a new handler method.

  • Alternative 2: Pass TabPanel into the ToggleCommand and select the new tab from ToggleCommand

    • Pros: Does not require new event to be raised.

    • Cons: Increases coupling.