CIS-180 Laboratory Project

Contact Editor Implementation (Part 1)


Designing the User Interface Classes

The user interface classes provide an interface through which the user can interact with the domain objects which you have already identified (Address Books, Contacts, etc.). The user interface classes that you should identify are not the low level components such as JTextArea's or JButton's, but the windows and panels that contain these low level components.

For example, you probably should have an AddressBookWindow class (or something similar) responisble for displaying an AddressBook. As another example, you will probably want a ContactEditor (or similar) class that provides an interface for displaying and editing contact information. A ContactEditor might be a separate window, or it could be a panel within the AddressBookWindow.

You might wonder why separate classes (e.g. AddressBook and AddressBookWindow) are necessary. The design principle we are using is that the model and the view should be kept separate. Part of the reason for keeping these separate is so that the user interface can change without rewriting the whole application. Consider, for example, what would happen if you decided later on to implement a version of your address book application for a cell phone with a small screen and no full size keyboard.

There are also other good reasons for keeping the model and view separate. In the address book application, you will eventually need to be able to save the contact information on disk, but not the user interface objects. This will be much easier if the contact information is in objects separate from the user interface objects.


Contact Editor Implementation

This week you will also begin implementing the Address Book application that you have designed. You will be implementing two classes that will allow you to create address book entries and view them in a window.

Hopefully, your design includes a class to represent an entry in the address book. You might have called this class something like Contact or AddressBookEntry. This class should have many attributes of type String for a contact's name, address, etc. It should have getter and setter methods for accessing these attributes.

At this point, you should also have included in your design a class that provides a user interface for viewing and editing an entry in the address book. You might have called this class something like ContactEditor or ContactWindow. If your design is different, you should consult with your lab instructor on how to proceed.



In the following exercises, the classes discussed above will be referred to as Contact and ContactEditor, although it is fine if you have used different names.

As you complete each exercise, make sure that your feature list and design documents are kept consistent with what you have done.

  1. Create a new java project in Eclipse for your Address Book application.
  2. Add a class to your project for the Contact class. The class should include a main method for testing purposes. Eventually, you may remove the main method from this class.
  3. Add the attributes to your Contact class according to your design. You can save some work if you declare each attribute to have an initial value of empty string (a string with no characters in it). For example:
    private String nickname = "";
  4. Implement a default constructor (constructor with no parameters) for the Contact class. If you declared your attributes with empty string initializers the default constructor can have an empty body (no code between the curly brackets). Otherwise, the default constructor should assign an empty string to each attribute. If your design does not include a default constructor for this class, add it now.
  5. For purposes of testing, you will probably want to implement a constructor that takes parameters for all of the attributes and uses them to initialize the Contact accordingly.
  6. You should add accessor/mutator methods to get and set the values of each attribute of a Contact. In eclipse, you can generate these methods automatically by selecting the code where the attributes are defined, and then choosing "Generate Getters and Setters ..." from the Source menu.
  7. Now add a class to your project for the ContactEditor class. This class should extend the JFrame class from the javax.swing package. (If your user interface design does not call for a separate window for displaying or editing contact information, you can easily change this later to extend some other container class such as JPanel.)
  8. The ContactEditor class should have an attribute of type Contact, which is the address book entry to display. It may also have attributes for user interface components, but be careful not to clutter your class with unnecessary attributes. Only information that needs to be remembered for the life of the ContactEditor object should be stored in an attribute as part of its state information.
  9. There should be a contructor method for ContactEditor that takes a Contact as parameter. This constructor should assign the Contact to the field, and layout the user interface to display the contact information.
  10. Depending on your user interface, you might need a setContact method to change the Contact that the editor displays.
  11. Now add code to the main method in your Contact class to test what you have done. Create some Contact objects and use ContactEditor objects to display them on the screen.