Skip to content

Latest commit

 

History

History
2232 lines (1655 loc) · 96 KB

DeveloperGuide.adoc

File metadata and controls

2232 lines (1655 loc) · 96 KB

ConnectUs - Developer Guide

By: W15-B3      Since: Jun 2016      Licence: MIT

1. Introduction

ConnectUs is an address book application that allows you to manage your contacts through the use of a command-line interface (CLI) or a graphical user interface (GUI).

This guide provides information that can help you contribute to the application in terms of coding and testing, and also allow you to better understand the features through the use of diagrams and explanations.

ConnectUs consists of the following features:

  • Adding new contacts

  • Editing, deleting, sorting, and emailing existing contacts

  • Importing contacts from phone and exporting contacts to phone

  • Filtering and removing tags of contacts

  • Providing a view of the location in Google Maps by the contact’s address

  • Generating QR code for calling, messaging and saving contacts

  • Changing colour theme

  • Uploading and deleting photos of contacts

  • Logging of user’s actions

2. Setting up

2.1. Prerequisites

In order to have a better experience in using the application, it would be good if you have the following java version installed:

  1. JDK 1.8.0_60 or later

    ℹ️
    Having any Java 8 version is not enough.
    This app will not work with earlier versions of Java 8.
  2. IntelliJ IDE

    ℹ️
    IntelliJ by default has Gradle and JavaFx plugins installed.
    Do not disable them. If you have disabled them, go to File > Settings > Plugins to re-enable them.

2.2. Setting up the project in your computer

The following describes the steps you would take to get started developing the application on your computer:

1) Fork this repo, and clone the fork to your computer

fork

2) Open IntelliJ (if you are not in the welcome screen, click File > Close Project to close the existing project dialog first)

3) Set up the correct JDK version for Gradle
(a) Click Configure > Project Defaults > Project Structure

configure

(b) Click New…​ and find the directory of the JDK

newSDK

4) Click Import Project

import

5) Locate the build.gradle file and select it. Click OK

6) Click Open as Project

7) Click OK to accept the default settings . Open a console and run the command gradlew processResources (Mac/Linux: ./gradlew processResources). It should finish with the BUILD SUCCESSFUL message.
This will generate all resources required by the application and tests.

terminal

2.3. Verifying the setup

1) Run the seedu.address.MainApp and try a few commands

2) Run the tests to ensure they all pass.

2.4. Configurations to do before writing code

2.4.1. Configuring the coding style

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

1) Go to File > Settings…​ (Windows/Linux), or IntelliJ IDEA > Preferences…​ (macOS)

preferences

2) Select Editor > Code Style > Java

3) Click on the Imports tab to set the order

  • For Class count to use import with '*' and Names count to use static import with '*': Set to 999 to prevent IntelliJ from contracting the import statements

  • For Import Layout: The order is import static all other imports, import java.*, import javax.*, import org.*, import com.*, import all other imports. Add a <blank line> between each import

codeStyle

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

2.4.2. Updating documentation to match your fork

After forking the repo, links in the documentation will still point to the se-edu/addressbook-level4 repo. If you plan to develop this as a separate product (i.e. instead of contributing to the se-edu/addressbook-level4) , you should replace the URL in the variable repoURL in DeveloperGuide.adoc and UserGuide.adoc with the URL of your fork.

2.4.3. Setting up CI

Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted at GitHub.

ℹ️
Having both Travis and AppVeyor ensures your App works on both Unix-based platforms and Windows-based platforms (Travis is Unix-based and AppVeyor is Windows-based)

To setup Travis, you can refer to UsingTravis.adoc to learn how to set it up.

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

2.4.4. Getting started with coding

Here are some tips to get you started on coding:

1) Get some sense of the overall design by reading the Architecture section.

2) Take a look at the section Suggested Programming Tasks to Get Started.

3. Design

3.1. Architecture

To help you better understand the relationship between each component in our application, the following section describes how each component interact with each other.

The Architecture Diagram given below explains the high-level design of the App. Given below is a quick overview of each component.

Architecture

Figure 3.1.1 : Architecture Diagram

💡
The .pptx files used to create diagrams in this document can be found in the diagrams folder. To update a diagram, modify the diagram in the pptx file, select the objects of the diagram, and choose Save as picture.

As seen in Figure 3.1.1, the App is made up of the following segments:

The Main has only one class called MainApp. It is responsible for,

  • Initializing the components at app launch in the correct sequence, and connects them up with each other.

  • terminating the components whilst shutting down and invokes cleanup method where necessary.

The Commons represents a collection of classes used by multiple other components. Two of those classes play important roles at the architecture level.

  • EventsCenter : This class (written using Google’s Event Bus library) is used by components to communicate with other components using events (i.e. a form of Event Driven design)

  • LogsCenter : Used by many classes to write log messages to the App’s log file.

The rest of the App consists of four components.

  • UI : The UI of the App.

  • Logic : The command executor.

  • Model : Holds the data of the App in-memory.

  • Storage : Reads data from, and writes data to, the hard disk.

Each of the four components

  • Defines its API in an interface with the same name as the Component.

  • Exposes its functionality using a {Component Name}Manager class.

The following figure below shows the class diagram of the logic component.

LogicClassDiagram

Figure 3.1.2 : Class Diagram of the Logic Component

In the figure above, the Logic component defines it’s API in the Logic.java interface and exposes its functionality using the LogicManager.java class.

Events-Driven nature of the design

The Sequence Diagram below shows how the components interact for the scenario where the user issues the command delete 1.

SDforDeletePerson

Figure 3.1.3a : Component interactions for delete 1 command (part 1)

ℹ️
Note how the Model simply raises a AddressBookChangedEvent when the Address Book data are changed, instead of asking the Storage to save the updates to the hard disk.

The diagram below shows how the EventsCenter reacts to that event, which eventually results in the updates being saved to the hard disk and the status bar of the UI being updated to reflect the 'Last Updated' time.

SDforDeletePersonEventHandling

Figure 3.1.3b : Component interactions for delete 1 command (part 2)

ℹ️
Note how the event is propagated through the EventsCenter to the Storage and UI without Model having to be coupled to either of them. This is an example of how this Event Driven approach helps us reduce direct coupling between components.

The sections below give more details of each component.

3.2. UI component

This section describes how the UI component works.

The figure below shows you on the structure of the UI component in our App.

UiClassDiagram

Figure 3.2.1 : Structure of the UI Component

API : Ui.java

The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, PersonListPanel, StatusBarFooter, BrowserPanel etc. All these, including the MainWindow, inherit from the abstract UiPart class.

The UI component uses JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

The UI component,

  • Executes user commands using the Logic component.

  • Binds itself to some data in the Model so that the UI can auto-update when data in the Model change.

  • Responds to events raised from various parts of the App and updates the UI accordingly.

3.3. Logic component

This section describes how the Logic component works.

The following diagrams Figure 3.3.1 and Figure 3.3.2 shows the structure of the logic component.

LogicClassDiagram

Figure 3.3.1 : Structure of the Logic Component

LogicCommandClassDiagram

Figure 3.3.2 : Structure of Commands in the Logic Component. This diagram shows finer details concerning XYZCommand and Command in Figure 2.3.1

API : Logic.java

  1. Logic uses the AddressBookParser class to parse the user command.

  2. This results in a Command object which is executed by the LogicManager.

  3. The command execution can affect the Model (e.g. adding a person) and/or raise events.

  4. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

Given below is the Sequence Diagram for interactions within the Logic component for the execute("delete 1") API call.

DeletePersonSdForLogic

Figure 3.3.1 : Interactions Inside the Logic Component for the delete 1 Command

3.4. Model component

This section describes how the Model component works.

Figure 3.4.1 shows the structure of the Model Component

ModelClassDiagram

Figure 3.4.1 : Structure of the Model Component

API : Model.java

The Model,

  • stores a UserPref object that represents the user’s preferences.

  • stores the Address Book data.

  • exposes an unmodifiable ObservableList<ReadOnlyPerson> that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.

  • does not depend on any of the other three components.

3.5. Storage component

This section describes how the Storage component works.

Lastly, Figure 3.5.1 shows the structure of the Storage component.

StorageClassDiagram

Figure 3.5.1 : Structure of the Storage Component

API : Storage.java

The Storage component,

  • can save UserPref objects in json format and read it back.

  • can save the Address Book data in xml format and read it back.

3.6. Common classes

Classes used by multiple components are in the seedu.addressbook.commons package.

ℹ️
Some examples of common classes includes: StringUtil , FileUtil, IllegalValueException etc.

4. Implementation

This section describes some noteworthy details on how certain features are implemented.

4.1. Email Function

(added in v1.2)

The email function allows a user to email the selected person by opening an email client on the user’s PC with the 'to:' field filled with the receiver’s email.

This function has been mapped to EmailButton

Once a PersonPanelSelectionChangedEvent is raised, EmailButton will save the currently selected email under the "email" attribute.

    @Subscribe
    private void handlePersonPanelSelectionChangedEvent(PersonPanelSelectionChangedEvent event) {
        this.selectedEmail = event.getNewSelection().person.emailProperty().getValue().toString();
        logger.info(LogsCenter.getEventHandlingLogMessage(event));
    }

The following sequence diagram describes how OpenEmailClient passes in the "email" attribute to Desktop

OpenEmailClientSequenceDiagram

Figure 4.1.1 : Sequence Diagram of the Email function

4.1.1. Design Considerations

Aspect: Functionality of Email
Alternative 1 (current choice): Open up an email client in another window by calling OpenEmailClient with to field filled with receiver’s email.
Pros: Easier to implement, user will be familiar with his/her prefered email client.
Cons: Only one field filled up, user still has to manually compose email.
Alternative 2: Build a form within current GUI and compose email there.
Pros: Better performance, does not rely on additional software.
Cons: Makes the current UI even more cluttered and confusing.


4.2. Displaying a contact’s location on Google Maps

(added in v1.2)

In this section, we explain how a contact’s location is displayed on Google Maps whenever a selection is made.

Whenever a PersonPanelSelectionChangedEvent is raised, the loadPersonPage method in BrowserPanel will update the address to the currently selected person.

    @Subscribe
    private void handlePersonPanelSelectionChangedEvent(PersonPanelSelectionChangedEvent event) {
        logger.info(LogsCenter.getEventHandlingLogMessage(event));
        loadPersonPage(event.getNewSelection().person);
    }

The browser will then render the new URL it has received. Below is the code snippet of loadPersonPage

    public void loadPersonPage(ReadOnlyPerson person) {
        browser.getEngine().setUserAgent("Mozilla/5.0 "
                + "(Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0");
        loadPage(GOOGLE_SEARCH_URL_PREFIX + person.getAddress().toString().replaceAll(" ", "+"));
    }
ℹ️
The browser’s user agent had to be set to "Mozilla/5.0 " + "(Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0" because there were unicode issue’s when load Google Maps on Mac computers.

4.3. Mapping a command to a JavaFX Button

(added in v1.2)

This section describes how a command can be mapped to a JavaFX button.

We will use the DeleteButton as an example but it can work for any command currently availble in the application.

To initialise the button, we have to create a StackPane placeholder for it in MainWindow

@FXML
    private StackPane deleteButtonPlaceholder;

Next, we create the DeleteButton class with the following constructor:

    public DeleteButton(Logic logic, int selectedIn) {
        super(FXML);
        this.logic = logic;
        this.selectedIndex = selectedIn;
        registerAsAnEventHandler(this);
    }

The DeleteButton will be instatiated in MainWindow where the placeholder adds the corresponding button element:

        deleteButton = new DeleteButton(logic, 0);
        deleteButtonPlaceholder.getChildren().add(deleteButton.getRoot());

Once a PersonPanelSelectionChangedEvent is raised, DeleteButton will save the currently selected index under the "selectedIndex" attribute.

The DeleteButton has an instance of Logic and CommandResult which performs a similar function to CommandBox.

When the DeleteButton is pressed, it will be handled by the handleDeleteButtonPressed() function:

 @FXML
    private void handleDeleteButtonPressed() throws CommandException, ParseException {
        CommandResult commandResult = logic.execute("delete " + getSelectedIndex());
        logger.info("Result: " + commandResult.feedbackToUser);
    }

4.4. Edit form implementation and validation

form

Figure 4.4.1 : Edit Person Form

This section describes how the edit form has been implemented.

Similar to the deleteButton, the editButton has been mapped to the edit command. Refering to Figure 4.4.1, this
command will be called whenever the Save button is pressed. Fields that have changed in TextFields 1, 2, 3, 4 and 5 (Name, Phone, Email, Address and Tags) would be be saved for the currently selected user. Thus, we have to make sure that the user inputs the correct command parameters into the edit command so that there would be no input errors.

Textfields for each of the 5 fields are implemented this way, in this example, here’s how the name field gets saved:

public class NameTextField extends UiPart<Region> {

    public static final String ERROR_STYLE_CLASS = "error";
    private static final String FXML = "NameTextField.fxml";
    private final Logger logger = LogsCenter.getLogger(CommandBox.class);

    @FXML
    private TextField nameTextField;

    public NameTextField() {
        super(FXML);
        registerAsAnEventHandler(this);
    }
    public String getNameTextField() {
        return nameTextField.getText();
    }

    public void setNameTextField(String text) {
        nameTextField.setText(text);
    }
    public TextField getObject() {
        return nameTextField;
    }
    @Subscribe
    private void handlePersonPanelSelectionChangedEvent(PersonPanelSelectionChangedEvent event) {
        logger.info(LogsCenter.getEventHandlingLogMessage(event));
        setNameTextField(event.getNewSelection().person.getName().toString());
    }
}

As shown above, whenever a user selects a new contact, the details of that contact would be displayed on the textfield
through the use of this event listener:

    @Subscribe
    private void handlePersonPanelSelectionChangedEvent(PersonPanelSelectionChangedEvent event) {
        logger.info(LogsCenter.getEventHandlingLogMessage(event));
        setNameTextField(event.getNewSelection().person.getName().toString());
    }

The user can now modify the selected field, in this case, the name field. Once he is happy with the changes, he goes
on to click the save button.

Shown below is a code snippet of where the save button gets instantiated. It takes in the textfields as parameters:

//extracted from MainWindow.java
// void fillInnerPats()
// ...

        editButton = new EditButton(logic, nameTextField, phoneTextField,
                emailTextField, addressTextField, tagTextField);

Before the contact details are saved, EditButton does a check on whether the inputs are valid:

    public static String checkInput(String name, String phone, String email, String address, String tag) {
        if (name.matches(".*\\d+.*") || name.isEmpty()) {
            return NAME_ERROR;
        }
        if (!phone.matches("[0-9]+")) {
            return PHONE_ERROR;
        }
        if (!email.contains("@") || !email.contains(".")) {
            return EMAIL_ERROR;
        }
        //check tag doesnt end with a special character
        String[] tagSplit = tag.split(",");
        for (int i = 0; i < tagSplit.length; i++) {
            if (!tagSplit[i].matches("[a-zA-Z0-9]*")) {
                return TAG_ERROR;
            }
        }
        return VALIDATION_SUCCESS;
    }

The contact would only be saved if this function returns a VALIDATION_SUCCESS, else it would output an input format error.

4.5. Undo/Redo mechanism

The undo/redo mechanism is facilitated by an UndoRedoStack, which resides inside LogicManager. It supports undoing and redoing of commands that modifies the state of the address book (e.g. add, edit). Such commands will inherit from UndoableCommand.

UndoRedoStack only deals with UndoableCommands. Commands that cannot be undone will inherit from Command instead.

The following diagram shows the inheritance diagram for commands:

LogicCommandClassDiagram

Figure 4.5.1 : Class Diagram for Logic Command

As you can see in Figure 4.5.1, UndoableCommand adds an extra layer between the abstract Command class and concrete commands that can be undone, such as the DeleteCommand. Note that extra tasks need to be done when executing a command in an undoable way, such as saving the state of the address book before execution. UndoableCommand contains the high-level algorithm for those extra tasks while the child classes implements the details of how to execute the specific command. Note that this technique of putting the high-level algorithm in the parent class and lower-level steps of the algorithm in child classes is also known as the template pattern.

Commands that are not undoable are implemented this way:

public class ListCommand extends Command {
    @Override
    public CommandResult execute() {
        // ... list logic ...
    }
}

With the extra layer, the commands that are undoable are implemented this way:

public abstract class UndoableCommand extends Command {
    @Override
    public CommandResult execute() {
        // ... undo logic ...

        executeUndoableCommand();
    }
}

public class DeleteCommand extends UndoableCommand {
    @Override
    public CommandResult executeUndoableCommand() {
        // ... delete logic ...
    }
}

Suppose that the user has just launched the application. The UndoRedoStack will be empty at the beginning.

As shown in Figure 4.5.2 below, the user executes a new UndoableCommand, delete 5, to delete the 5th person in the address book. The current state of the address book is saved before the delete 5 command executes. The delete 5 command will then be pushed onto the undoStack (the current state is saved together with the command).

UndoRedoStartingStackDiagram

Figure 4.5.2: Undoable Command example

As the user continues to use the program, more commands are added into the undoStack. For example in Figure 4.5.3, the user may execute add n/David …​ to add a new person.

UndoRedoNewCommand1StackDiagram

Figure 4.5.3: Undoable Command example

ℹ️
If a command fails its execution, it will not be pushed to the UndoRedoStack at all.

The user now decides that adding the person was a mistake, and decides to undo that action using undo.

We will pop the most recent command out of the undoStack and push it back to the redoStack as shown in Figure 4.5.4. We will restore the address book to the state before the add command executed.

UndoRedoExecuteUndoStackDiagram

Figure 4.5.4: Undoable Command example

ℹ️
If the undoStack is empty, then there are no other commands left to be undone, and an Exception will be thrown when popping the undoStack.

The following sequence diagram shows how the undo operation works:

UndoRedoSequenceDiagram

Figure 4.5.5 : Sequence Diagram of the Undo and Redo function._

The redo does the exact opposite (pops from redoStack, push to undoStack, and restores the address book to the state after the command is executed).

ℹ️
If the redoStack is empty, then there are no other commands left to be redone, and an Exception will be thrown when popping the redoStack.

The user now decides to execute a new command, clear. As before, clear will be pushed into the undoStack. This time the redoStack is no longer empty. It will be purged as it no longer make sense to redo the add n/David command (this is the behavior that most modern desktop applications follow).

UndoRedoNewCommand2StackDiagram

Figure 4.5.6: Undoable Command example

Commands that are not undoable are not added into the undoStack. For example, list, which inherits from Command rather than UndoableCommand, will not be added after execution:

UndoRedoNewCommand3StackDiagram

Figure 4.5.7: Undoable Command example

The following activity diagramsummarize what happens inside the UndoRedoStack when a user executes a new command:

UndoRedoActivityDiagram

Figure 4.5.8: Undoable Command Activity Diagram

4.5.1. Design Considerations

Aspect: Implementation of UndoableCommand
Alternative 1 (current choice): Add a new abstract method executeUndoableCommand()
Pros: We will not lose any undone/redone functionality as it is now part of the default behaviour. Classes that deal with Command do not have to know that executeUndoableCommand() exist.
Cons: Hard for new developers to understand the template pattern.
Alternative 2: Just override execute()
Pros: Does not involve the template pattern, easier for new developers to understand.
Cons: Classes that inherit from UndoableCommand must remember to call super.execute(), or lose the ability to undo/redo.


Aspect: How undo & redo executes
Alternative 1 (current choice): Saves the entire address book.
Pros: Easy to implement.
Cons: May have performance issues in terms of memory usage.
Alternative 2: Individual command knows how to undo/redo by itself.
Pros: Will use less memory (e.g. for delete, just save the person being deleted).
Cons: We must ensure that the implementation of each individual command are correct.


Aspect: Type of commands that can be undone/redone
Alternative 1 (current choice): Only include commands that modifies the address book (add, clear, edit).
Pros: We only revert changes that are hard to change back (the view can easily be re-modified as no data are lost).
Cons: User might think that undo also applies when the list is modified (undoing filtering for example), only to realize that it does not do that, after executing undo.
Alternative 2: Include all commands.
Pros: Might be more intuitive for the user.
Cons: User have no way of skipping such commands if he or she just want to reset the state of the address book and not the view.
Additional Info: See our discussion here.


Aspect: Data structure to support the undo/redo commands
Alternative 1 (current choice): Use separate stack for undo and redo
Pros: Easy to understand for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project.
Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both HistoryManager and UndoRedoStack.
Alternative 2: Use HistoryManager for undo/redo
Pros: We do not need to maintain a separate stack, and just reuse what is already in the codebase.
Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as HistoryManager now needs to do two different things.

4.6. Logging

We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.

  • The logging level can be controlled using the logLevel setting in the configuration file (See Configuration)

  • The Logger for a class can be obtained using LogsCenter.getLogger(Class) which will log messages according to the specified logging level

  • Currently log messages are output through: Console and to a .log file.

Logging Levels

  • SEVERE : Critical problem detected which may possibly cause the termination of the application

  • WARNING : Can continue, but with caution

  • INFO : Information showing the noteworthy actions by the App

  • FINE : Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size

4.7. Configuration

Certain properties of the application can be controlled (e.g App name, logging level) through the configuration file (default: config.json).

4.8. Import Command

(added in v1.2)

The import command is a new feature implemented that allows the user to import contact details directly from some external source.

The logic is implemented by reading the external source file and then retrieving the relevant contact details by reading the file line by line.

Once the required information (name, email, address, phone number) is retrieved from the data, a Person object will be created and the Model will then add the person into the address book.

  • The user will first enter the command import FILENAME.vcf where the FILENAME is the name of the file.

  • Next, the AddressBookParser class will retrieve the command as well as the argument and then call the ImportCommandParser class with the FILENAME as the argument.

        case ImportCommand.COMMAND_WORD:
        case ImportCommand.COMMAND_ALIAS:
            return new ImportCommandParser().parse(arguments);
  • Then, in the ImportCommandParser class the file will be retrieved by the java FILE class which will access and convert the file into a byte stream using bufferedReader and fileReader class.

  • Once the file is loaded into the bufferedReader, the ImportCommandParser class will read the file line by line to identify the required contact information that is inside the file.


public ImportCommand parse(String args) {
    String filename = args.trim();
    ArrayList<ReadOnlyPerson> p = new ArrayList<ReadOnlyPerson>();
    BufferedReader br = null;
    FileReader fr = null;

  • The class uses simple String comparison to identify key words such as "FN" for name and "EMAIL" for email address etc.


if (currLine.contains("FN")) {
    name = currLine.split(":")[1];
}
if (currLine.contains("TEL")) {
    phone = currLine.split(":")[1];
}
if (currLine.contains("ADR")) {
    address = currLine.split(";")[2];
}
if (currLine.contains("EMAIL")) {
    email = currLine.split(":")[1];
}

  • Once the line reads the keyword "END", it means that the end of the first contact has been accessed and all its required values were all retrieved by the class.

  • Then using the informaton the class retrieved, it will then create a Person object. This object is then stored inside a ReadOnlyPerson array.


try {
   Name n = new Name(name);
   Phone pe = new Phone(phone);
   Email e = new Email(email);
   Address a = new Address(address);
   ReadOnlyPerson person = new Person(n, pe, e, a, tagList);
        p.add(person);
     } catch (IllegalValueException ie) {
       ie.getMessage();
    }

  • When all the contact in the file has been accessed and created as a Person object and stored inside the array, the ImportCommandParser will then return a new ImportCommand() that will parse the array to the ImportCommand class for execution.

  • The ImportCommand class will retrieve the ReadOnlyPerson array that was parsed into its' constructor and then loop through the array and add each Person object into the addressbook.


private ArrayList<ReadOnlyPerson> p;
public ImportCommand(ArrayList<ReadOnlyPerson> list) {
    this.p = list;
}
@Override
public CommandResult executeUndoableCommand() throws CommandException {
    if (p.isEmpty()) {
        return new CommandResult(MESSAGE_FAILURE);
    } else {
        try {
            for (ReadOnlyPerson pp : p) {
                model.addPerson(pp);
            }
        } catch (DuplicatePersonException de) {
            throw new CommandException(AddCommand.MESSAGE_DUPLICATE_PERSON);
        }
        LoggingCommand loggingCommand = new LoggingCommand();
        loggingCommand.keepLog("", "Import Action");
        return new CommandResult(MESSAGE_SUCCESS);
    }
}

  • Lastly, the ImportCommand class will return a success message to inform the user that all the contacts has been imported.

4.8.1. Design Considerations

Aspect: The types of file that can be imported using the Import command.
Alternative 1 (current choice): Currently, the import command can only read files that has the extension .vcf.
Pros: Multi platform compatibility and the format in .vcf file enables the program to retrieve the information easily.
Cons: Since the logic is written specifically for .vcf files, we will have to rewrite the logic if we want to support other file types in the future.
Alternative 2: use .csv file as the import source
Pros: Format is simple, each value is separated by a comma.
Cons: Values in the file will have a hard time to be mapped into each variable as each value is only separated by a comma, mistakes can be made when trying to map each values into each category.


Aspect: Which directory to access the source file.
Alternative 1 (current choice): Currently, the file has to be stored in /main directory.
Pros: Easy to develop the logic as there is only one filepath .
Cons: User will have to specifically place the file in the /main directory which does not really make sense.
Alternative 2: Create a File upload function.
Pros: User friendly. User can upload a file that is residing in any part of the user’s PC. Does not require user to specifically place the file at the /data directory.
Cons: Requires an Upload button to be created, involves UI component. Requires more time to develop the upload function.

4.9. Filter by tag mechanism

(added in v1.2)

The filter by tag mechanism logic is implemented by the TagContainsKeywordsPredicate class which lies under Model.

  • The keywords inputted by the user is put into a List<String> and then parses into TagContainsKeywordsPredicate.

  • TagContainsKeywordsPredicate will override the test(ReadOnlyPerson) method where the method checks against the list of tags of each person and returns true for the person that has the tags similar to the keywords.

  • After which, the predicate returned by TagContainsKeywordsPredicate will be saved in TagCommand. The tag command is not undoable so it will just override execute().

  • At the method execute(), the predicate is then used to update the filtered list when it is parsed into the method updateFilteredPersonList(Predicate) which belongs to the Model class.

  • The filtered list size is then parsed into the getMessageForPersonListShownSummary(int) which will return the CommandResult to show to the user.

  • The result will be the message showing the amount of persons in the filtered list and the display of the filtered list.

4.9.1. Design Considerations

Aspect: Implementation logic of TagCommand
Alternative 1 (current choice): Keywords(case-insensitive) that are substrings or equal to the tag names will match
Pros: Easy and convenient for users to search for specific tags.
Cons: If the user only type a common letter or substring found in all tag names, more persons will be returned which makes it difficult to search for the specific tag.
Alternative 2: Only keywords(case-sensitive) that are exactly equal to the tag names will match
Pros: Results in an accurate filtered list
Cons: Requires user to type the exact tag name which makes it inconvenient. As convenience is more important, Alternative 1 is chosen.

4.10. Remove tag mechanism

(added in v1.2)

The remove tag mechanism is implemented by Logic and Model.

  • When parsing the command,each of the keywords inputted by the user is used to create a new Tag object that is put into a ArrayList<Tag>.

  • The ArrayList<Tag> is then parsed in to RemoveTagCommand which is returned by the RemoveTagCommandParser class.

  • The RemoveTagCommand is undoable so it will execute and override executeUndoableCommand() instead of overriding execute().

  • Under the executeUndoableCommand() method in the RemoveTagCommand under Logic, each Tag inside the ArrayList<Tag> is then sent to the removeTag(Tag) method which is handled by the ModelManager which implements Model. The method removes any tags of a person that matches the tag in the ArrayList.

  • The method works by looping the person list in the 'AddressBook' and creating a new Person object called newPerson for each Person in the list. The Set<Tag> is then obtained from the newPerson and then removes the Tag that is parsed into the method.

  • The setTags is then set for the newPerson and the updatePerson(oldPerson, newPerson) method is subsequently called to update the Person in the AddressBook.

  • RemoveTagCommand also handles the checking of whether the Tag(keyword) matches any of the existing tags in ConnectUs.

ℹ️
If the keywords is not identical to any of the existing tag names, 'CommandResult' will notify the user that no tags has been removed. Otherwise, a success message will be shown.

The following sequence diagram shows how the remove tag operation works:

removeTag sequenceDiagram

Figure 4.8.1: Remove Tag Sequence Diagram

4.10.1. Design Considerations

Aspect: Implementation logic of RemoveTagCommand
Alternative 1 (current choice): Only keywords(case-sensitive) that are exactly equal to the tag names will match
Pros: Ensures that only the tag specified by the user gets deleted.
Cons: Requires user to type the exact tag name which makes it inconvenient.
Alternative 2 : Keywords(case-insensitive) that are substrings or equal to the tag names will match
Pros: More convenient for users to type.
Cons: If the user only type a common letter or substring found in all tag names, some tags which may not be what the user wanted may get deleted. Even though the command can be undone, it is undesirable to have this logic when deleting.


Aspect: Data structure to support the RemoveTagCommand
Alternative 1 (current choice): Use an ArrayList<Tag> to store the keywords
Pros: Compares between the same object Tag which can ensure that only the tag specified by the user gets deleted.
Cons: Requires more overhead at creating the object Tag for each keyword
Alternative 2 : Use an ArrayList<String> to store the keywords
Pros: Less overhead as can compare between keyword strings and tag name strings
Cons: Further implementation and checks required to check that the keyword is identical to the tag name

4.11. Change colour theme mechanism

(added in v1.2)

You can customise the look of the application by changing the color theme. This feature can be done on the GUI or the CLI.

The colour theme options are implemented by the UI on the MainWindow MenuBar as MenuItems.

  • When the option is clicked, it will trigger the specified action for the MenuItem. E.g. Clicking on "White Theme" MenuItem will trigger the onAction method "handleWhiteTheme".

  • The method adds the stylesheet to the VBox that is specific for the colour theme chosen and removes the stylesheets that belongs to other colours.

For the CLI, the ChangeThemeCommand makes use of the EventsCenter to post the event ThemeChangeEvent whenever the command is executed.

  • When the command is executed, the theme inputted by you would be saved as a String variable to the ThemeChangeEvent.

  • The method "handleThemeCommand" on the MainWindow is subscribed to the ThemeChangeEvent and will check with the saved theme to handle the specific themes.

  • The same onAction methods will be triggered for the different specific themes and follows the GUI implementation as above.

The diagrams shows the UI of the additional colour themes:

whiteThemeUI

Figure 4.9.1 : White Theme

Ui

Figure 4.9.2 : Green Theme

4.12. Upload photo mechanism

(added in v1.4)

The uploading photo mechanism is implemented by EventsCenter and Logic.

  • There are two ways a user can upload a photo to the contact, either by choosing an image from a file explorer or inputting in the image file path in the command.

  • After the user enters the command, the UploadPhotoCommandParser will separate the argument into the index and file path before parsing both variables into UploadPhotoCommand.

  • In UploadPhotoCommand, the execute() method will check for invalid index before checking if filePath string is empty. The file explorer will open for the user to choose an image if the filePath string is empty.

  • Next, the method will check if the file is a valid image file before saving the file into the project directory, as well as raising an event called PhotoChangeEvent as seen below.

    if (isValidImageFile(imageFile)) {
                saveFile(imageFile, personToUploadImage.getEmail());
                EventsCenter.getInstance().post(new PhotoChangeEvent());
            } else {
                throw new CommandException(String.format(MESSAGE_UPLOAD_IMAGE_FALURE));
            }
  • The event is raised to allow instant display of the modification of the photo. To implement this, PersonCard is registered as an event handler and includes a @Subscribe handlePhotoChange to handle the event of uploading the photo.

  • The handlePhotoChange method will set the ImageView to the new image file path of the uploaded photo in the project directory.

ℹ️
If the file given is not a valid image file, a 'CommandException' will be thrown to specify that the file is invalid.

4.12.1. Design Considerations

Aspect: Storing of photo for each contact in UploadPhotoCommand
Alternative 1 (current choice): The uploaded photo file name is saved as the person’s email.
Pros: Implementation needs just EventsCenter and PersonCard to handle any change of photo event and instantly displays the change.
Cons: Requires other modification to the storage of photo logic such as deleting or clearing contacts, as well as adding and editing a contact.
Alternative 2 : Modify Person in Model to include a Photo attribute.
Pros: Reliable as the photo path is always stored for each Person.
Cons: Requires a lot of modification to codes that will require Person , as well as changing tests to reflect the additional attribute.

4.13. Export Command

(added in v1.3)

The export command is a new feature implemented that allows the user to export contact details to other external applications.

This feature enables the user to do a backup of their contact details from our application to other applications that support the vCard format for contact details.

Similar to the import command, the logic for the export command will read all the ReadOnlyPerson object that is stored in the addressbook array.

And for each ReadOnlyPerson object found in the array, the required information (name, email, address, phone number) will be retrieved and placed onto a crafted vCard format string variable for writing to a vCard file.

  • The user will first enter the command export from the command line interface

  • Next, the AddressBookParser class will be invoked and the ExportCommand class will be called.


case ExportCommand.COMMAND_WORD:
case ExportCommand.COMMAND_ALIAS:
    return new ExportCommand();

  • In the ExportCommand class, the class will first check if the address book is empty.

  • If the address book is empty, it will return an error message to the user indicating that there is nothing to export.`


if (model.getAddressBook().getPersonList().isEmpty()) {
    return new CommandResult(MESSAGE_EMPTY_AB);

  • Once the class checks that there are objects in the address book array that can be retrieved, the class will call the method writeToFile() to do the necessary retrieving of the data

  • The writeTofile() method will first create a filename called output.vcf.

  • The method then use the bufferedWriter and the fileWriter class to write all the information retrieved onto a string variable in each iteration..

  • Lastly, we call the close() method in both bufferedWriter and fileWriter in order to save the output onto the file output.vcf.


/**
 * This method handles the writing of contacts to a file
 */
private void writeToFile() throws IOException {
    final String filename = "output.vcf";
    FileWriter fw = new FileWriter(filename);
    BufferedWriter bw = new BufferedWriter(fw);
    for (ReadOnlyPerson p : model.getAddressBook().getPersonList()) {
        String header = "BEGIN:VCARD\n";
        String version = "VERSION:3.0\n";
        String fullName = "FN:" + p.getName().toString() + "\n";
        String name = "N:;" + p.getName().toString() + ";;;\n";
        String email = "EMAIL;TYPE=INTERNET;TYPE=HOME:" + p.getEmail().toString() + "\n";
        String tel = "TEL;TYPE=CELL:" + p.getPhone().toString() + "\n";
        String address = "ADR:;;" + p.getAddress().toString() + ";;;;\n";
        String footer = "END:VCARD\n";
        bw.write(header);
        bw.write(version);
        bw.write(fullName);
        bw.write(name);
        bw.write(email);
        bw.write(tel);
        bw.write(address);
        bw.write(footer);
    }
    if (bw != null) {
        bw.close();
    }
    if (fw != null) {
        fw.close();
    }
}

4.13.1. Design Considerations

Aspect: The types of file that can be exported using the export command.
Alternative 1 (current choice): Currently, the export command can only output files onto a file with the extension .vcf.
Pros: Multi platform compatibility and the format in .vcf file enables the user to use our output as a backup onto other application that supports it.
Cons: Since the logic is written specifically for .vcf files, we will have to rewrite the logic if we want to support other file types in the future.
Alternative 2: use .csv file as the import source
Pros: Format is simple, each value is separated by a comma.
Cons: All values will have a hard time to be retrieved and mapped into each variable as each value is only separated by a comma, mistakes can be made when trying to map each values into each category.


Aspect: Which directory to access the source file.
Alternative 1 (current choice): Currently, the file will be stored in /main directory.
Pros: Easy to develop the logic as there is only one filepath .
Cons: User will have to specifically place the file in the /main directory which does not really make sense.
Alternative 2: Create a Export button for the user on the GUI.
Pros: User friendly. User can simply click on an Export button and all the contacts will be exported. Cons: Requires an Export button to be created, involves UI component.

4.14. Delete photo mechanism

(added in v1.5)

The delete photo mechanism is similar to the upload photo mechanism where it is also implemented by EventsCenter and Logic.

  • After inputting the command with the index of the person in the argument, DeletePhotoCommandParser will parse in the index into DeletePhotoCommand.

  • At the execute() method of DeletePhotoCommand, the method first checks if the index given is larger than the current filteredPersonList. If it is, a CommandException will be thrown to indicate invalid index.

  • Next, the method will get the ReadOnlyPerson object based on the index given.

  • A method called isPhotoExist will check if there is an existing photo for the current person before deleting the photo as shown in the code below:

     if (isPhotoExist(personToDeleteImage)) {
                deletePhoto(personToDeleteImage);
                EventsCenter.getInstance().post(new PhotoChangeEvent());
            } else {
                throw new CommandException(String.format(MESSAGE_DELETE_IMAGE_FAILURE));
            }
  • The event is raised to allow instant display of the modification of the photo. To implement this, PersonCard is registered as an event handler and includes a @Subscribe handlePhotoChange to handle the event of deleting the photo.

  • The handlePhotoChange method will set the ImageView to the default image file path in the project directory.

ℹ️
If the person does not have an existing uploaded photo, a 'CommandException' will be thrown to specify that the person does not have a photo to delete.

4.15. Deletes all photos mechanism

(added in v1.5)

The deletes all photos mechanism is similar to the delete photo mechanism where it is also implemented by EventsCenter and Logic.

  • After entering the command, the execute() method in DeletesAllPhotosCommand will delete all the photos in the project directory.

4.15.1. Design Considerations

Aspect: Implementation of code
Alternative 1 (current choice): Implementing this feature in a separate DeletesAllPhotosCommand class
Pros: Separation of Concerns Principle (SoC) is not violated as the DeletesAllPhotosCommand class simply handles the deletion of all photos.
Cons: One more command has to be added which can inconvenience the user.
Alternative 2 : Implementing this feature in the DeletePhotoCommand class by having the same command and different parameters
Pros: There will be one less command which makes it more convenient to the user.
Cons: This will violate Separation of Concerns Principle (SoC) as even though both classes concerns the deletion of photos, DeletePhotoCommand
is specifically concerned in deleting a person’s photo while DeletesAllPhotosCommand is concerned with deleting all photos.

4.16. LoggingCommand Function

(added in v1.2)

In this section, we explain how logging is done in the application whenever an important action is taken by user.

Whenever an action such as "Add", "Clear", "Delete", "Edit", "Email", "Import", "List", "Redo", "RemoveTag", "Undo", "UploadPhoto", "DeletePhoto" & "DeletesAllPhotos" is executed, the LoggingCommand method will be called and information of the action is recorded in ConnectUsLog.txt with a timestamp.

With slight modification to Figure 3.1.2, we have the following diagram showing the Class Diagram on how LoggingCommand is implemented in the system.

LogCommandClassDia

Figure 4.15.1 : Class Diagram of LoggingCommand function

The sequence diagram uses delete command as an example on how LoggingCommand is implemented.

loggingcommandseq

Figure 4.15.2 : An example of Sequence Diagram for LoggingCommand function used for delete

This is how you can use the LoggingCommand method in your code.

   LoggingCommand loggingCommand = new LoggingCommand();
   loggingCommand.keepLog("Information", "Type of Action such as Add,Clear,etc.");
ℹ️
With reference to the code for LoggingCommand, the "information" indicate the data that the user are editing with while "type of action" indicate the action taken by the user.

4.17. ClearLog Function

(added in v1.3)

ℹ️
This action is irreversible.

In this section, we will explain how users can clear their log for ConnectUsLog.txt file.

In cases, where you want to keep your logfile organised by clearing logfile such as after checks or confirmation of log details. The logfile information is no longer useful to the user and this method allow that action.

This function has been mapped to ClearLogButton and 'clearlog' 'cl' for commandline.

The following sequence diagram describes how 'ClearLogCommand' delete ConnectUsLog.txt file when method is called.

clearlogseq

Figure 4.16.1 : Sequence Diagram of the ClearLogCommand

The ClearLog Method is implemented in the 'ClearLogButton' with the following codes.

       @FXML
       private void handleClearLogButtonPressed() throws CommandException, ParseException, IOException {
           Alert alert = new Alert(AlertType.CONFIRMATION, "Are you sure you want clear the log?",
                   ButtonType.YES, ButtonType.NO, ButtonType.CANCEL);
           alert.showAndWait();
           if (alert.getResult() == ButtonType.YES) {
               ClearLogCommand clearLogCommand = new ClearLogCommand();
               clearLogCommand.execute();
               logger.info("Log has been cleared.");
           }
       }

The ClearLog Method implementation for commandline with the following codes.

    public CommandResult execute() throws CommandException, IOException {
        File file = new File("ConnectUsLog.txt");
        file.delete();
        return new CommandResult(MESSAGE_SUCCESS);
    }

4.18. QrCall Function

(added in v1.4)

In this section, we explain how users can generation Quick Response(QR) Code for calling with any contact number available in the addressbook.

To make user experience more convenience, QR Code can make calling easy through the use of Smartphone with QR Scanner application installed.

This function has been mapped to QrButton and qrcall qc for commandline.

The following sequence diagram describes how 'QrCall' Generates QR Code using commandline.

QrCallCommand

Figure 4.17.1 : Sequence Diagram of the QrCallCommand

The QrCallCommandParser Method is implemented with the following code.

          public QrCallCommand parse(String args) throws ParseException {
              try {
                  Index index = ParserUtil.parseIndex(args);
                  return new QrCallCommand(index);
              } catch (IllegalValueException ive) {
                  throw new ParseException(
                          String.format(MESSAGE_INVALID_COMMAND_FORMAT, QrCallCommand.MESSAGE_USAGE));
              }
          }

The QrCallCommand Method implementation for commandline with the following codes.

     @Override
        public CommandResult execute() throws CommandException {

            List<ReadOnlyPerson> lastShownList = model.getFilteredPersonList();

            if (targetIndex.getZeroBased() >= lastShownList.size()) {
                throw new CommandException(Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX);
            }
            int indexOfPersonInList = targetIndex.getOneBased() - 1;
            EventsCenter.getInstance().post(new QrEvent(lastShownList.get(indexOfPersonInList)));
            return new CommandResult(String.format(MESSAGE_SELECT_PERSON_SUCCESS, targetIndex.getOneBased()));

        }

The QrEvent Method implementation for commandline with the following codes.

        @Override
        public String toString() {
            return this.getClass().getSimpleName();
        }
        public ReadOnlyPerson getPerson() {
            return person;
        }

The QrButton Method implementation for commandline with the following codes.

    @FXML
    private void handleQrButtonPressed() throws CommandException, ParseException, IOException {
        if ( person != null) {
            bp.loadQrCode(person);
            logger.info("QR Code displayed");
        } else {
            logger.info(MESSAGE_FAIL);
        }
    }

The BrowserPanel Method implementation for commandline with the following codes.

       public void loadQrCode(ReadOnlyPerson person) {
           QrGenCallCommand qrGenCallCommand = new QrGenCallCommand();
           browser.getEngine().setUserAgent("Mozilla/5.0 "
                   + "(Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0");
           loadPage(qrGenCallCommand.qrCall(person.getPhone().toString()));
       }

The QrGenCallCommand to retrieve QrCode with the following codes.

       public String qrCall(String phoneNum) {
              String qrCodeA = "http://";
              String qrCodeB = "api.qrserver.com/";
              String qrCodeC = "v1/";
              String qrCodeD = "create-qr-code/";
              String qrCodeE = "?color=000000";
              String qrCodeF = "&bgcolor=FFFFFF";
              String qrCodeG = "&data";
              String qrCodeH = "=tel";
              String qrCodeI = "%3A";
              String qrCodeJ = "&qzone";
              String qrCodeK = "=1";
              String qrCodeL = "&margin";
              String qrCodeM = "=0";
              String qrCodeN = "&size";
              String qrCodeO = "=500x500";
              String qrCodeP = "&ecc";
              String qrCodeQ = "=L";
              String qrLineA = qrCodeA + qrCodeB + qrCodeC + qrCodeD + qrCodeE + qrCodeF
                      + qrCodeG + qrCodeH + qrCodeI;
              String qrLineB = qrCodeJ + qrCodeK + qrCodeL + qrCodeM + qrCodeN + qrCodeO
                      + qrCodeP + qrCodeQ;
              String fullQr = qrLineA + phoneNum + qrLineB;
              return fullQr;
          }

4.19. QrSms Function

(added in v1.4)

In this section, we explain how users can generation Quick Response(QR) Code for Sms(Short Message Services) with any contact number available in the addressbook.

To make user experience more convenience, QR Code can make sms easy through the use of Smartphone with QR Scanner application installed.

This function has been mapped to QrSmsButton and qrsms qs for commandline.

The following sequence diagram describes how 'QrSms' Generates QR Code using commandline.

QrSmsCommand

Figure 4.18.1 : Sequence Diagram of the QrSmsCommand

The QrSmsCommandParser Method is implemented with the following code.

 public QrSmsCommand parse(String args) throws ParseException {
        try {
            Index index = ParserUtil.parseIndex(args);
            return new QrSmsCommand(index);
        } catch (IllegalValueException ive) {
            throw new ParseException(
                    String.format(MESSAGE_INVALID_COMMAND_FORMAT, QrSmsCommand.MESSAGE_USAGE));
        }
    }

The QrSmsCommand Method implementation for commandline with the following codes.

   @Override
       public CommandResult execute() throws CommandException {

           List<ReadOnlyPerson> lastShownList = model.getFilteredPersonList();
           if (targetIndex.getZeroBased() >= lastShownList.size()) {
               throw new CommandException(Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX);
           }
           int indexOfPersonInList;
           indexOfPersonInList = targetIndex.getOneBased() - 1;
           EventsCenter.getInstance().post(new QrSmsEvent(lastShownList.get(indexOfPersonInList)));
           return new CommandResult(String.format(MESSAGE_SELECT_PERSON_SUCCESS, targetIndex.getOneBased()));

       }

The QrSmsEvent Method implementation for commandline with the following codes.

        @Override
        public String toString() {
            return this.getClass().getSimpleName();
        }
        public ReadOnlyPerson getPerson() {
            return person;
        }

The QrSmsButton Method implementation for commandline with the following codes.

     @FXML
        private void handleQrSmsButtonPressed() throws CommandException, ParseException, IOException {
            if ( person != null) {
                bp.loadSmsQrCode(person);
                logger.info("QR Code displayed");
            } else {
                logger.info(MESSAGE_FAIL);
            }
        }

The BrowserPanel Method implementation for commandline with the following codes.

 public void loadSmsQrCode(ReadOnlyPerson person) {
        QrGenSmsCommand qrGenSmsCommand = new QrGenSmsCommand();
        browser.getEngine().setUserAgent("Mozilla/5.0 "
                + "(Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0");
        loadPage(qrGenSmsCommand.qrSms(person.getPhone().toString(), person.getName().fullName));
    }

The QrGenSmsCommand to retrieve QrCode with the following codes.

  public String qrSms(String phoneNum, String contactName) {
        String qrCodeA = "http://";
        String qrCodeB = "api.qrserver.com/";
        String qrCodeC = "v1/";
        String qrCodeD = "create-qr-code/";
        String qrCodeE = "?color=000000";
        String qrCodeF = "&bgcolor=FFFFFF";
        String qrCodeG = "&data";
        String qrCodeH = "=SMSTO";
        String qrCodeI = "%3A";
        String qrCodeJ = "&qzone";
        String qrCodeK = "=1";
        String qrCodeL = "&margin";
        String qrCodeM = "=0";
        String qrCodeN = "&size";
        String qrCodeO = "=500x500";
        String qrCodeP = "&ecc";
        String qrCodeQ = "=L";
        String qrLineA = qrCodeA + qrCodeB + qrCodeC + qrCodeD + qrCodeE + qrCodeF
                + qrCodeG + qrCodeH + qrCodeI;
        String qrLineB = qrCodeI + "Dear+" + contactName + "%2C";
        String qrLineC = qrCodeJ + qrCodeK + qrCodeL + qrCodeM + qrCodeN + qrCodeO
                + qrCodeP + qrCodeQ;
        String fullQr = qrLineA + phoneNum + qrLineB + qrLineC;
        return fullQr;
    }

4.20. QrSaveContact Function

(added in v1.4)

ℹ️
Currently only available for Android Users.

In this section, we explain how users can generation Quick Response(QR) Code for saving contact into their android smartphone.

To make user experience more convenience, QR Code can make saving contact easy through the use of Smartphone with QR Scanner application installed.

This function has been mapped to QrSaveButton and qrsave qrs for commandline.

The following sequence diagram describes how 'QrSave' Generates QR Code using commandline.

QrSaveContactCommand

Figure 4.19.1 : Sequence Diagram of the QrSaveContactCommand

The QrSaveContactCommandParser Method is implemented with the following code.

    public QrSaveContactCommand parse(String args) throws ParseException {
        try {
            Index index = ParserUtil.parseIndex(args);
            return new QrSaveContactCommand(index);
        } catch (IllegalValueException ive) {
            throw new ParseException(
                    String.format(MESSAGE_INVALID_COMMAND_FORMAT, QrSaveContactCommand.MESSAGE_USAGE));
        }
    }

The QrSaveContactCommand Method implementation for commandline with the following codes.

   @Override
      public CommandResult execute() throws CommandException {

          List<ReadOnlyPerson> lastShownList = model.getFilteredPersonList();
          if (targetIndex.getZeroBased() >= lastShownList.size()) {
              throw new CommandException(Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX);
          }
          int indexOfPersonInList = 0;
          indexOfPersonInList = targetIndex.getOneBased() - 1;
          EventsCenter.getInstance().post(new QrSaveEvent(lastShownList.get(indexOfPersonInList)));
          return new CommandResult(String.format(MESSAGE_SELECT_PERSON_SUCCESS, targetIndex.getOneBased()));

      }

The QrSaveEvent Method implementation for commandline with the following codes.

    @Override
    public String toString() {
        return this.getClass().getSimpleName();
    }
    public ReadOnlyPerson getPerson() {
        return person;
    }

The QrSaveButton Method implementation for commandline with the following codes.

    @FXML
    private void handleQrSaveButtonPressed() throws CommandException, ParseException, IOException {
        if ( person != null) {
            bp.loadSaveQrCode(person);
            logger.info("QR Code displayed");
        } else {
            logger.info(MESSAGE_FAIL);
        }
    }

The BrowserPanel Method implementation for commandline with the following codes.

 public void loadSaveQrCode(ReadOnlyPerson person) {
        QrGenSaveContactCommand qrGenSaveContactCommand = new QrGenSaveContactCommand();
        browser.getEngine().setUserAgent("Mozilla/5.0 "
                + "(Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0");
        loadPage(qrGenSaveContactCommand.qrSaveContact(person.getPhone().toString(), person.getName().fullName,
                person.getEmail().toString()));
    }

The QrGenSmsCommand to retrieve QrCode with the following codes.

    public String qrSaveContact(String phoneNum, String contactName, String contactEmail) {
        String qrA = "http://";
        String qrB = "api.qrserver.com/";
        String qrC = "v1/";
        String qrD = "create-qr-code/";
        String qrE = "?color=000000";
        String qrF = "&bgcolor=FFFFFF";
        String qrG = "&data=BEGIN";
        String qrH = "%3AVCARD";
        String qrI = "%0AVERSION";
        String qrJ = "%3A2.1%0";
        String qrK = "AFN%3A";
        String lineA = qrA + qrB + qrC + qrD + qrE + qrF + qrG + qrH + qrI
                + qrJ + qrK;
        String newName = contactName.replace(' ', '+');
        String lineB = "%0AN%3A%3B";
        String qrL = "%0ATEL";
        String qrM = "%3BWORK";
        String qrN = "%3BVOICE%3A";
        String lineC = qrL + qrM + qrN;
        String qrO = "%0AEMAIL";
        String qrP = "%3BWORK";
        String qrQ = "%3BINTERNET%3A";
        String lineD = qrO + qrP + qrQ;
        String qrCodeA = "%0AEND";
        String qrCodeB = "%3AVCARD";
        String qrCodeC = "%0A&qzone=1";
        String qrCodeD = "&margin=0";
        String qrCodeE = "&size=500x500";
        String qrCodeF = "&ecc=L";
        String lineE = qrCodeA + qrCodeB + qrCodeC + qrCodeD + qrCodeE + qrCodeF;
        String fullQr = lineA + newName + lineB + newName + lineC + phoneNum + lineD + contactEmail + lineE;
        System.out.println(fullQr);
        return fullQr;
    }

4.21. Sort Command

(Added in v1.2)

The sort command is a feature we implemented to allow users to sort their contact details based on the name of the contacts. When we add in new contacts using the add feature, the contact will usually be added into the bottom of the address book.

As the contacts in the addressbook gets larger and larger, it will be difficult to maintain the contacts as the contact details in the contact list panel will become messy and we will have to use the find feature constantly to look for the contact we want.

The sort command starts off by taking in the sort command from the AddressBookParser class and call a new SortCommand class.


case SortCommand.COMMAND_WORD:
case SortCommand.COMMAND_ALIAS:
   return new SortCommand();

The SortCommand class will then call the sort() method created in the AddressBook class to modify the array list that was used to maintain the contact details in the UniquePersonList class.

The sorting algorithm lies in the UniquePersonList class where a self-defined comparator was implemented to sort the elements in the array list based on the name of the Person in the list.


public void sort() {
    internalList.sort((person1, person2) -> (
            person1.getName().fullName
                    .compareToIgnoreCase(person2.getName().fullName)));
}

4.21.1. Design Considerations

Aspect: What attributes to be sorted by the user.
Alternative 1 (current choice): Currently, the sort command only allows sorting the name of the contact list.
Pros: The most logical way is to sort by the name as all other attributes is associated to the name of the person in the list
Cons: User may want to sort by other attributes to allow better managing and retrieving of contacts
Alternative 2: implement sort by various attributes
Pros: Allows user to sort by attributes to their preference.
Cons: Does not make any sense when sorting by attributes such as Phone number or address.

5. Documentation

We use asciidoc for riting documentation.

ℹ️
We chose asciidoc over Markdown because asciidoc, although a bit more complex than Markdown, provides more flexibility in formatting.

5.1. Editing Documentation

See UsingGradle.adoc to learn how to render .adoc files locally to preview the end result of your edits. Alternatively, you can download the AsciiDoc plugin for IntelliJ, which allows you to preview the changes you have made to your .adoc files in real-time.

5.2. Publishing Documentation

See UsingTravis.adoc to learn how to deploy GitHub Pages using Travis.

5.3. Converting Documentation to PDF format

We use Google Chrome for converting documentation to PDF format, as Chrome’s PDF engine preserves hyperlinks used in webpages.

Here are the steps to convert the project documentation files to PDF format.

  1. Follow the instructions in UsingGradle.adoc to convert the AsciiDoc files in the docs/ directory to HTML format.

  2. Go to your generated HTML files in the build/docs folder, right click on them and select Open withGoogle Chrome.

  3. Within Chrome, click on the Print option in Chrome’s menu.

  4. Set the destination to Save as PDF, then click Save to save a copy of the file in PDF format. For best results, use the settings indicated in the screenshot below.

chrome save as pdf

Figure 5.3.1 : Saving documentation as PDF files in Chrome

6. Testing

6.1. Running Tests

There are three ways to run tests.

💡
The most reliable way to run tests is the 3rd one. The first two methods might fail some GUI tests due to platform/resolution-specific idiosyncrasies.

Method 1: Using IntelliJ JUnit test runner

  • To run all tests, right-click on the src/test/java folder and choose Run 'All Tests'

  • To run a subset of tests, you can right-click on a test package, test class, or a test and choose Run 'ABC'

Method 2: Using Gradle

  • Open a console and run the command gradlew clean allTests (Mac/Linux: ./gradlew clean allTests)

ℹ️
See UsingGradle.adoc for more info on how to run tests using Gradle.

Method 3: Using Gradle (headless)

Thanks to the TestFX library we use, our GUI tests can be run in the headless mode. In the headless mode, GUI tests do not show up on the screen. That means the developer can do other things on the Computer while the tests are running.

To run tests in headless mode, open a console and run the command gradlew clean headless allTests (Mac/Linux: ./gradlew clean headless allTests)

6.2. Types of tests

We have two types of tests:

  1. GUI Tests - These are tests involving the GUI. They include,

    1. System Tests that test the entire App by simulating user actions on the GUI. These are in the systemtests package.

    2. Unit tests that test the individual components. These are in seedu.address.ui package.

  2. Non-GUI Tests - These are tests not involving the GUI. They include,

    1. Unit tests targeting the lowest level methods/classes.
      e.g. seedu.address.commons.StringUtilTest

    2. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
      e.g. seedu.address.storage.StorageManagerTest

    3. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
      e.g. seedu.address.logic.LogicManagerTest

6.3. Troubleshooting Testing

Problem: HelpWindowTest fails with a NullPointerException.

  • Reason: One of its dependencies, UserGuide.html in src/main/resources/docs is missing.

  • Solution: Execute Gradle task processResources.

7. Dev Ops

7.1. Build Automation

See UsingGradle.adoc to learn how to use Gradle for build automation.

7.2. Continuous Integration

We use Travis CI and AppVeyor to perform Continuous Integration on our projects. See UsingTravis.adoc and UsingAppVeyor.adoc for more details.

7.3. Making a Release

Here are the steps to create a new release.

  1. Update the version number in MainApp.java.

  2. Generate a JAR file using Gradle.

  3. Tag the repo with the version number. e.g. v0.1

  4. Create a new release using GitHub and upload the JAR file you created.

7.4. Managing Dependencies

A project often depends on third-party libraries. For example, Address Book depends on the Jackson library for XML parsing. Managing these dependencies can be automated using Gradle. For example, Gradle can download the dependencies automatically, which is better than these alternatives.
a. Include those libraries in the repo (this bloats the repo size)
b. Require developers to download those libraries manually (this creates extra work for developers)

Appendix A: Suggested Programming Tasks to Get Started

Suggested path for new programmers:

  1. First, add small local-impact (i.e. the impact of the change does not go beyond the component) enhancements to one component at a time. Some suggestions are given in this section Improving a Component.

  2. Next, add a feature that touches multiple components to learn how to implement an end-to-end feature across all components. The section Creating a new command: remark explains how to go about adding such a feature.

A.1. Improving each component

Each individual exercise in this section is component-based (i.e. you would not need to modify the other components to get it to work).

Logic component

💡
Do take a look at the Design: Logic Component section before attempting to modify the Logic component.
  1. Add a shorthand equivalent alias for each of the individual commands. For example, besides typing clear, the user can also type c to remove all persons in the list.

Model component

💡
Do take a look at the Design: Model Component section before attempting to modify the Model component.
  1. Add a removeTag(Tag) method. The specified tag will be removed from everyone in the address book.

    • Hints

      • The Model API needs to be updated.

      • Find out which of the existing API methods in AddressBook and Person classes can be used to implement the tag removal logic. AddressBook allows you to update a person, and Person allows you to update the tags.

    • Solution

      • Add the implementation of deleteTag(Tag) method in ModelManager. Loop through each person, and remove the tag from each person.

      • See this PR for the full solution.

Ui component

💡
Do take a look at the Design: UI Component section before attempting to modify the UI component.
  1. Use different colors for different tags inside person cards. For example, friends tags can be all in grey, and colleagues tags can be all in red.

    Before

    getting started ui tag before

    After

    getting started ui tag after
    • Hints

    • Solution

      • See this PR for the full solution.

  2. Modify NewResultAvailableEvent such that ResultDisplay can show a different style on error (currently it shows the same regardless of errors).

    Before

    getting started ui result before

    After

    getting started ui result after
  3. Modify the StatusBarFooter to show the total number of people in the address book.

    Before

    getting started ui status before

    After

    getting started ui status after

Storage component

💡
Do take a look at the Design: Storage Component section before attempting to modify the Storage component.
  1. Add a new method backupAddressBook(ReadOnlyAddressBook), so that the address book can be saved in a fixed temporary location.

A.2. Creating a new command: remark

By creating this command, you will get a chance to learn how to implement a feature end-to-end, touching all major components of the app.

A.2.1. Description

Edits the remark for a person specified in the INDEX.
Format: remark INDEX r/[REMARK]

Examples:

  • remark 1 r/Likes to drink coffee.
    Edits the remark for the first person to Likes to drink coffee.

  • remark 1 r/
    Removes the remark for the first person.

A.2.2. Step-by-step Instructions

[Step 1] Logic: Teach the app to accept 'remark' which does nothing

Let’s start by teaching the application how to parse a remark command. We will add the logic of remark later.

Main:

  1. Add a RemarkCommand that extends UndoableCommand. Upon execution, it should just throw an Exception.

  2. Modify AddressBookParser to accept a RemarkCommand.

Tests:

  1. Add RemarkCommandTest that tests that executeUndoableCommand() throws an Exception.

  2. Add new test method to AddressBookParserTest, which tests that typing "remark" returns an instance of RemarkCommand.

[Step 2] Logic: Teach the app to accept 'remark' arguments

Let’s teach the application to parse arguments that our remark command will accept. E.g. 1 r/Likes to drink coffee.

Main:

  1. Modify RemarkCommand to take in an Index and String and print those two parameters as the error message.

  2. Add RemarkCommandParser that knows how to parse two arguments, one index and one with prefix 'r/'.

  3. Modify AddressBookParser to use the newly implemented RemarkCommandParser.

Tests:

  1. Modify RemarkCommandTest to test the RemarkCommand#equals() method.

  2. Add RemarkCommandParserTest that tests different boundary values for RemarkCommandParser.

  3. Modify AddressBookParserTest to test that the correct command is generated according to the user input.

[Step 3] Ui: Add a placeholder for remark in PersonCard

Let’s add a placeholder on all our PersonCard s to display a remark for each person later.

Main:

  1. Add a Label with any random text inside PersonListCard.fxml.

  2. Add FXML annotation in PersonCard to tie the variable to the actual label.

Tests:

  1. Modify PersonCardHandle so that future tests can read the contents of the remark label.

[Step 4] Model: Add Remark class

We have to properly encapsulate the remark in our ReadOnlyPerson class. Instead of just using a String, let’s follow the conventional class structure that the codebase already uses by adding a Remark class.

Main:

  1. Add Remark to model component (you can copy from Address, remove the regex and change the names accordingly).

  2. Modify RemarkCommand to now take in a Remark instead of a String.

Tests:

  1. Add test for Remark, to test the Remark#equals() method.

[Step 5] Model: Modify ReadOnlyPerson to support a Remark field

Now we have the Remark class, we need to actually use it inside ReadOnlyPerson.

Main:

  1. Add three methods setRemark(Remark), getRemark() and remarkProperty(). Be sure to implement these newly created methods in Person, which implements the ReadOnlyPerson interface.

  2. You may assume that the user will not be able to use the add and edit commands to modify the remarks field (i.e. the person will be created without a remark).

  3. Modify SampleDataUtil to add remarks for the sample data (delete your addressBook.xml so that the application will load the sample data when you launch it.)

[Step 6] Storage: Add Remark field to XmlAdaptedPerson class

We now have Remark s for Person s, but they will be gone when we exit the application. Let’s modify XmlAdaptedPerson to include a Remark field so that it will be saved.

Main:

  1. Add a new Xml field for Remark.

  2. Be sure to modify the logic of the constructor and toModelType(), which handles the conversion to/from ReadOnlyPerson.

Tests:

  1. Fix validAddressBook.xml such that the XML tests will not fail due to a missing <remark> element.

[Step 7] Ui: Connect Remark field to PersonCard

Our remark label in PersonCard is still a placeholder. Let’s bring it to life by binding it with the actual remark field.

Main:

  1. Modify PersonCard#bindListeners() to add the binding for remark.

Tests:

  1. Modify GuiTestAssert#assertCardDisplaysPerson(…​) so that it will compare the remark label.

  2. In PersonCardTest, call personWithTags.setRemark(ALICE.getRemark()) to test that changes in the Person 's remark correctly updates the corresponding PersonCard.

[Step 8] Logic: Implement RemarkCommand#execute() logic

We now have everything set up…​ but we still can’t modify the remarks. Let’s finish it up by adding in actual logic for our remark command.

Main:

  1. Replace the logic in RemarkCommand#execute() (that currently just throws an Exception), with the actual logic to modify the remarks of a person.

Tests:

  1. Update RemarkCommandTest to test that the execute() logic works.

A.2.3. Full Solution

See this PR for the step-by-step solution.

Appendix B: User Stories

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

B.1. Must Have

Priority As a …​ I want to …​ So that I can…​

* * *

new user

see usage instructions

refer to instructions when I forget how to use the App

* * *

user

add a new person

* * *

user

delete a person

remove entries that I no longer need

* * *

user

find a person by name

locate details of persons without having to go through the entire list

* * *

user

the application to look simple and easy to use

easily understand how the application works.

* * *

user

input commands on a GUI

won’t need to memorize the commands

* * *

user

delete people by their name

clear space for new contacts

* * *

user

be able to sort my contact based on most recent contact

immediately get the contact.

* * *

user

retrieve my past command history

review what I entered previously

* * *

user

undo my last command

enter in the correct command instead

* * *

user

clear the whole list of persons

pass this app to a new user

* * *

user

edit the details of a person

update any changes to the person.

B.2. Nice to have

Priority As a …​ I want to …​ So that I can…​

* *

user

filter the list through details such as tags

search for those contacts that I only need.

* *

user

easily send email or messages to the contact through the application

immediately send messages.

* *

user

have a map view of all my contacts based on their address

plan where to visit them.

* *

user

import my phone contacts to the addressbook easily

save time in adding them again.

* *

user

update my group friends of an upcoming event or activities

be informed of the activities.

* *

user

have my information secured

be assured that my contact information are safe on cloud storage

* *

user

hide private contact details by default

minimize chance of someone else seeing them by accident

* *

user

personalize the application

feel more familiar with the application

* *

user

check what command or changes was done at any point in time

can rectify mistakes committed to keep addressbook up to date

* *

user

avoid careless mistake when keying number for calling

be more productive and careless free

* *

user

avoid careless mistake when keying number for sending of sms

be more productive and careless free

* *

user

save user contact to my smart phone

be more productive and careless free. As well as saving time from manual input for huge number of contact information.

B.3. Unlikely to have

Priority As a …​ I want to …​ So that I can…​

*

user

upload images to different contacts

so that I can easily identify them

*

user

delete images of different contacts

so that I can remove outdated photos

*

user

plan out the best path for each contact based on what i select

take advantage of the most efficient routes.

Appendix C: Use Cases

(For all use cases below, the System is the ConnectUs and the Actor is the user, unless specified otherwise)

C.1. Use case: Delete person

MSS

  1. User requests to list persons

  2. ConnectUs shows a list of persons

  3. User requests to delete a specific person in the list

  4. ConnectUs deletes the person

    Use case ends.

Extensions

  • 2a. The list is empty.

    Use case ends.

  • 3a. The given index is invalid.

    • 3a1. ConnectUs shows an error message.

      Use case resumes at step 2.

C.2. Use case: Add person

MSS

  1. User requests to add person

  2. ConnectUs adds the person

    Use case ends.

Extensions

  • 1a. The given command is invalid.

    • 1a1. ConnectUs shows an error message.

      Use case resumes at step 1.

  • 1b. The given person is a duplicate of an existing person.

    • 1b1. ConnectUs shows an error message.

      Use case resumes at step 1.

C.3. Use case: Edit person

MSS

  1. User requests to list persons

  2. ConnectUs shows a list of persons

  3. User requests to edit a specific person in the list

  4. ConnectUs edits the person

    Use case ends.

Extensions

  • 2a. The list is empty.

    Use case ends.

  • 3a. The given index is invalid.

    • 3a1. ConnectUs shows an error message.

      Use case resumes at step 2.

  • 3b. The given changes are a duplicate of an existing person.

    • 3b1. ConnectUs shows an error message.

      Use case resumes at step 2.

  • 3c. The given command is invalid.

    • 3c1. ConnectUs shows an error message.

      Use case resumes at step 2.

C.4. Use case: Redo command

MSS

  1. User requests to redo command

  2. ConnectUs redoes the command

    Use case ends.

Extensions

  • 1a. There is no command to redo.

    • 1a1. ConnectUs shows an error message.

      Use case ends.

C.5. Use case: Undo command

MSS

  1. User requests to undo command

  2. ConnectUs undoes the command

    Use case ends.

Extensions

  • 1a. There is no command to undo.

    • 1a1. ConnectUs shows an error message.

      Use case ends.

C.6. Use case: Select person

MSS

  1. User requests to list persons

  2. ConnectUs shows a list of persons

  3. User requests to select a specific person in the list

  4. ConnectUs selects the person

    Use case ends.

Extensions

  • 2a. The list is empty.

    Use case ends.

  • 3a. The given index is invalid.

    • 3a1. ConnectUs shows an error message.

      Use case resumes at step 2.

C.7. Use case: Find person

MSS

  1. User requests to find person by name

  2. ConnectUs finds and displays the list of person(s) with their names similar to the keywords

    Use case ends.

Extensions

  • 1a. The given command is invalid.

    • 1a1. ConnectUs shows an error message.

      Use case resumes at step 2.

Appendix D: Non Functional Requirements

  • Should work on any mainstream OS as long as it has Java 1.8.0_60 or higher installed.

  • Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.

  • A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.

  • Internet connection is required to maximise the functionality of the AddressBook Application. Such as accessing features in BrowserPanel.

  • Should have at least 100MB of space in HardDiskDrive in order for application to install.

  • Should have at least 2GB of ram in computer in order for the application to run smoothly.

  • Requirement of at least 3rd Generation i3 processor to operate the application.

Appendix E: Glossary

Activity Diagram

A flowchart to represent the flow from one activity to another activity

Architecture Diagram

A diagram that defines the structure, behavior, and views of a system.

Mainstream OS

Windows, Linux, Unix, OS-X

Private contact detail

A contact detail that is not meant to be shared with others

Sequence Diagram

A diagram that shows how objects operate with one another and in what order.

Use Case

a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal.