Project Duke

The project consists of the following increments:

• Levels: A series of features, meant to be added to Duke in the given order, although some can be skipped. These have been named Level 1 to Level 10 to indicate how the features make the product progressively "level up".
• Extensions:
  • Category A These are internal/feature enhancements meant to help you practice a specific Java or an SE technique.
  • Category B These are enhancements related to task tracking.
  • Category C These are enhancements, not specifically related to task tracking.
  • Category D Each of these adds the ability to track another type of entities.

When implementing this feature, you are also recommended to implement the following extension as collections classes (e.g., ArrayList) have methods to easily delete an item at a specified location:

public class Task {
    protected String description;
    protected boolean isDone;

    public Task(String description) {
        this.description = description;
        this.isDone = false;
    }

    public String getStatusIcon() {
        return (isDone ? "\u2713" : "\u2718"); //return tick or X symbols
    }

    //...
}

Task t = new Taks("read book");
t.markAsDone()

When implementing this feature, you are also recommended to implement the following extension as collections classes (e.g., ArrayList) have methods to easily delete an item at a specified location:

public class Deadline extends Task {

    protected String by;

    public Deadline(String description, String by) {
        super(description);
        this.by = by;
    }

    @Override
    public String toString() {
        return "[D]" + super.toString() + " (by: " + by + ")";
    }
}

Task[] tasks = new Task[100];
task[0] = new Deadline("return book", "Monday");

When implementing this feature, you are also recommended to implement the following extension as collections classes (e.g., ArrayList) have methods to easily delete an item at a specified location:

When implementing this feature, you are also recommended to implement the following extension as collections classes (e.g., ArrayList) have methods to easily delete an item at a specified location:

When implementing this feature, you are also recommended to implement the following extension as collections classes (e.g., ArrayList) have methods to easily delete an item at a specified location:

While it is possible to represent a task list as a multi-dimensional array containing primitive values, the more natural approach is to use a Task class to represent tasks.

public class Task {
    protected String description;
    protected boolean isDone;

    public Task(String description) {
        this.description = description;
        this.isDone = false;
    }

    public String getStatusIcon() {
        return (isDone ? "\u2713" : "\u2718"); //return tick or X symbols
    }

    //...
}

Task t = new Taks("read book");
t.markAsDone()

As there are multiple types of tasks that have some similarity between them, you can implement classes Todo, Deadline and Event classes to inherit from a Task class.

Furthermore, use polymorphism to store all tasks in a data structure containing Task objects e.g., Task[100].

public class Deadline extends Task {

    protected String by;

    public Deadline(String description, String by) {
        super(description);
        this.by = by;
    }

    @Override
    public String toString() {
        return "[D]" + super.toString() + " (by: " + by + ")";
    }
}

Task[] tasks = new Task[100];
task[0] = new Deadline("return book", "Monday");

Use exceptions to handle errors. For example, define a class DukeException to represent exceptions specific to Duke.

Use the input/output redirection technique to semi-automate testing of Duke.

A tutorial is provided in the duke repository.

Use Java Collections classes for storing data. For example, you can use an ArrayList<Task> to store the tasks.

Refactor the code to extract out closely related code as classes.

• Minimal: Extract the following classes:
  • Ui: deals with interactions with the user
  • Storage: deals with loading tasks from the file and saving tasks in the file
  • Parser: deals with making sense of the user command
  • TaskList: contains the task list e.g., it has operations to add/delete tasks in the list

public class Duke {

    private Storage storage;
    private TaskList tasks;
    private Ui ui;

    public Duke(String filePath) {
        ui = new Ui();
        storage = new Storage(filePath);
        try {
            tasks = new TaskList(storage.load());
        } catch (DukeException e) {
            ui.showLoadingError();
            tasks = new TaskList();
        }
    }

    public void run() {
        //...
    }

    public static void main(String[] args) {
        new Duke("data/tasks.txt").run();
    }
}

• Stretch Goal: Consider extracting more classes. e.g., *Command classes (i.e., AddCommand, DeleteCommand, ExitCommand etc.) that inherits from an abstract Command class, so that you can write the main logic of the App as follows:

  public void run() {
      ui.showWelcome();
      boolean isExit = false;
      while (!isExit) {
          try {
              String fullCommand = ui.readCommand();
              ui.showLine(); // show the divider line ("_______")
              Command c = Parser.parse(fullCommand);
              c.execute(tasks, ui, storage);
              isExit = c.isExit();
          } catch (DukeException e) {
              ui.showError(e.getMessage());
          } finally {
              ui.showLine();
          }
      }
  }
  

  You can get some inspiration from how the code of the addressbook-level2 is organized.

Add JUnit tests to test the behavior of the code.

Conventions to follow:

• Add test code in a folder named [project root]\src\test\java\ folder (reason: to follow the convention followed by the project structure so far).
• Name the test class to match the class being tested (Todo.java can be tested by TodoTest.java), and put it in a package to match. For example,
  • Class being tested seedu.duke.Todo: src\main\java\seedu\duke\Todo.java
  • Test class seedu.duke.TodoTest: src\test\java\seedu\duke\TodoTest.java

Requirements:

• Minimum: More than two test methods, preferably targeting more than one class (if you have multiple classes)
• Stretch goal: test methods to target all public methods of all classes

Adding JUnit support to your project: As JUnit is a third-party library, you need to add support to it specifically in your project.

Organize the classes into suitable java packages. e.g., duke.task, duke.command

Add JavaDoc comments to the code.

• Minimal: Add header comments to at least half of the non-private classes/methods.
• Stretch goal: Add header comments to all non-private classes/methods, and non-trivial private methods.

Tweak the code to comply with a chosen coding standard.

Use checkStyle to detect coding style violations.

If you are using Gradle for your project, refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to use CheckStyle via Gradle. Alternatively, you can try the CheckStyle plugin for Intellij.

Critically examines the code and refactor to improve the code quality where necessary.

Use assert feature (not JUnit assertions) to document important assumptions that should hold at various points in the code.

Package the app as an executable JAR file so that it can be distributed easily.

Do not commit the JAR file created. Instead, you can make the JAR file available in the following manner.

• Go to your fork on GitHub and create a new release.
• In the page where you fill the details of th release,
  • give an appropriate version number e.g., v0.1
  • attach the JAR file where it says Attach binaries by dropping them ....

If you are using Gradle for your project, refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to create a jar file using Gradle.

Use Gradle to automate some of the build tasks of the project. Refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to set up Gradle for your project.

• Minimal: Set up gradle so that you can build and run Duke using gradle.
• Recommended: Set up gradle to run unit tests.
• Stretch Goal: Use gradle to automate more things in your project.

Use Travis (and GitHub) to perform Continuous Integration (CI).

Use Java enums, if applicable.

Use Java varargs feature, if applicable.

Use the Lambdas feature of Java in your code, if applicable.

Use the Streams feature of Java in your code, if applicable.

Use third-party libraries in your project. For example, you can use the Natty library to parse strings into meaningful dates.

Use JavaFX to create a GUI. Refer to the JavaFX tutorials at the Duke repo (i.e., the repo you forked from) to learn how to get started.

Add a User Guide to the project. Here is one simple way to do it.

• Update the given docs\README.md. See this guide to GitHub flavored Markdown (GFMD).
• Go to the settings page of your Duke fork and enable GitHub pages to publish from the docs folder (you can select a theme too).
• Go to http://{your username}.github.io/duke/ to view the user guide of your product.

Add a Developer Guide to the project, explaining the design and implementation to future developers.

Release the product to be used by potential users. e.g., you can make it available on GitHub

Provide a way for an event to be tentatively scheduled in multiple slots, and later to be confirmed to one the slots.

Provide a way to easily snooze/postpone/reschedule tasks.

Provide support for managing recurring tasks e.g., a weekly project meeting.

Support the managing of tasks that need to be done after a specific time/task e.g., return book after the exam is over.

Provide support for managing tasks that need to be done within a certain period e.g., collect certificate between Jan 15 and 25th.

Provide support for managing tasks that takes a fixed amount of time but does not have a fixed start/end time e.g., reading the sales report (needs 2 hours).

Provide a way to get reminders about tasks e.g., remind the user about upcoming deadlines.

Provide a way for the user to find free times e.g., when is the nearest day in which I have a 4 hour free slot?.

Provide a way to view tasks in the form of a schedule e.g., view the schedule for a specific date.

Deal with schedule anomalies e.g., detect if a task being added clashes with another task in the list.

Add the ability to recognize and deal with duplicate items. e.g., the same task added multiple times.

Provide more flexibility with the data source e.g., the ability for the user to specify which file to use as the data source.

The ability to sort items e.g., sort deadlines chronologically.

Support more natural date formats e.g., Mon in a user command can be interpreted as the date of the next Monday in the calendar.

All more flexibility in search e.g., find items even if the keyword matches the item only partially.

Support a way to easily edit details of items e.g., change the end time of an event without changing anything else.

Minimal: the ability to update an existing item without having to delete it first

Other ideas:

• the ability to clone items (to easily create new items based on existing items)

Provide a way to tag items e.g., tag a task as #fun.

Provide a way to attach priorities to items e.g., mark an item as a high priority (or priority level 1).

Provide a way to archive items so that the user can remove items from the app but still keep a record of them somewhere e.g., archive all tasks in the list into a file so that the user can start over with a clean slate.

Provide a way to perform tasks on multiple items e.g., delete some specific items in one go.

Provide a way to leverage statistics about the items managed by the App e.g., show the number of tasks that have been completed in the past week.

Provide a way to undo a command.

Minimal: the ability to undo the most recent command.

Provide in-App guidance to users.

Minimal: add a command to access a help page.

Other ideas:

• Load the App with some sample data at the first run.

Make the command syntax more flexible.

Minimal: provide shorter aliases for keywords e.g., t can be shorter alias for todo.

Other ideas:

• Allow users to define their own aliases
• Remove the need for the parts of a command to be in a specific order

Support managing info about contacts e.g., details of friends

Support managing info about small snippets of textual information the user wants to record e.g., one's own waist size, a name of a movie that the user wants to remember

Support managing info about expenses e.g., the amounts spent on food, books, transport, etc.

Support keeping records of loans given/taken e.g., money lent/owed to colleagues/friends

Support recording info about places e.g., info about restaurants visited, for future reference

Provide the ability to learn/memorize thingse.g., learn vocabulary, answers to questions

Support managing info about clients e.g., for an insurance agent to keep track of clients

Support managing info about merchandise e.g., a property agent to keep track of properties, a collector of stamps keep track of items in the collection