Goals: Upon completion of this lab, you should be able to

• design and implement a simple graphical user interface from standard components,
• evaluate competing user interface alternatives in terms of intuitiveness and efficiency,
• manage files and directories within a program, and
• navigate documentation for class libraries in order to find the relevant support for application requirements.

Overview: Over the course of this semester, you will design and implement a customizable game that helps special needs children learn their letters and sounds. To support this game, you will need to create a subsystem that records and manages voice clips as audio files. Using your voice clip manager, people will be able to record the required audio clips for the game, play the clips, adding and replacing clips as needed. Over the first four weeks of the semester, you will develop this audio clip manager in several stages, as follows. (The due dates for these stages are listed above.)

1. Design: A sketch of audio clip manager user interface, and descriptions of how users will interact with it. (Use the "GUI layout" and "scenario" forms for this design.) Your objectives in this design are that the functionality is obvious to the user and that the features can be used with minimal effort. The interface should also be visually pleasing and well organized.
2. View Implementation: An application with all the required visual components, but that does not interact with the user. You will give a demo of this, but none of the buttons or other features will need to work. All that is required at this stage is that all the visual components are present and arranged in accordance with your design.
3. Controllers Implementation: The controllers are the classes that react to user input (such as button presses) that allow the user to interact with the application. Upon completion of this stage of development, users should be able to record and save audio clips and play them back.
4. File Management Implementation: In this final phase of development, you will implement additional features that streamline the management of sound files in a list. (These are the features designated as "File Management" in the list below.)

Recording Features:

• The user can record an audio clip and save it to a file.
• The user can start and stop a recording session manually.
• The user can specify the duration of a recording session in seconds (in the range 1 to 10 seconds) and have the recording session stop automatically after that many seconds. A JSlider is recommended for this.
• If a fixed duration is specified by the user, a JProgressBar should be used to let the user see the percentage of the total time that has elapsed during recording.

Playback Features:

• The user can load an audio clip from a file and play it back.
• After playing back a file, the user can choose to record over it (using recording features).
• The user can stop audio playback in the middle. (That is, the user does not have to wait for the entire audio clip to play out.)
• Optional: The user can pause/resume playback.

File Management Features:

• A program (not the user) can pass a collection (List or array) of Strings to a method your audio clip manager, and the audio clip manager will prompt the user to speak each of the given text strings, one by one. There should be a space of at least 1.5 seconds after showing the prompt before recording begins. The method, in addition to the collection of Strings, should take a parameter that specifies the duration of the clips. (The usual recording features, with the JProgressBar, should be used. The only difference for the user is that they don't have to manually enter each file name and press the record button. It happens automatically.)
• The user can see a list (use a JList to present this) of the audio files that exist in a particular directory (i.e., folder). When showing the list, do not include the file extension (.wav) as part of the displayed file name. Just show the name of the file.
• The user can select one or more files from the JList, and then "review" them, meaning that each one is played out, with an opportunity for the user to choose to rerecord any of them along the way. For example, if three clips are selected, each will be played, followed by an option for the user to replace it. Note that JList supports multiple selection.
• Optional: When the user rerecords a clip, don't immediately replace the old one, but give the user the option to choose between the old and the new clip after recording.
• Optional: Let the user navigate, using a JFileChooser, to the directory whose files are displayed in the JList.

Supporting Classes: Read the documentation for the following classes, as they will be helpful in your design and implementation. Two of the classes are explicitly provided, and the others are part of the standard Java library. See the Java API documentation linked from the CSE132 web site.

• After you create your Java project in Eclipse, import these provided files:
  1. Recorder.java - a class that records from the microphone to a .wav file
  2. Player.java - a class that plays back a .wav file to the speakers
• Visual components: JFrame, JPanel, JButton, JToggleButton, ButtonGroup, JSlider, JProgressBar, JList, JLabel, JTextField, and you may want to use JSplitPane if you want your JList to be in a separately resizable area.
• For file dialog boxes: JFileChooser
• Listener interfaces for implementing controllers: ActionListener (for handling both buttons and timers) and ListSelectionListener for JList selection handling
• For timed actions, use javax.swing.Timer,
• Layout managers: FlowLayout, GridLayout, BorderLayout
• The File class will support everything you need from the file system. Note that a File can be a direcory (you can tell with the isDirectory() method), and if so you can use the list() and listFiles() methods to get its contents.
• Optional: If you want to use icons on your buttons, use the ImageIcon class, which has a constructor that takes a file name. A collection of icons is available at http://java.sun.com/developer/techDocs/hi/repository/
• Optional: If you want to add pulldown menus to your JFrame, use JMenuBar, JMenu, and AbstractAction.

Documentation: Using javadoc comments, create thorough documentation of your code. Let the documentation guide the implementation, not the other way around. In other words, write the documentation as part of your design process, before you fill in the bodies of your methods. This will help you to collect your thoughts, improve communication between you and your lab partner, and make it more likely that everything works as expected. Each class should have an overview paragraph that describes its purpose. Documentation for each method should include a one line summary of the purpose of the method, followed by "requires," "modifies," and "effects" clauses, where appropriate. Use the Javadoc parameter, return, and throws tags as well.

To set up the javadoc templates in Eclipse, select the menu item "Project->Properties," expand "Java Code Style," and select "code template." Then, at the right, select "configure workspace." In the dialog box, expand "comments," select "methods," and press the "Edit..." button. You can then modify the template as follows:

/**
 * <br>REQUIRES:
 * <br>MODIFIES:
 * <br>EFFECTS:
 * ${tags}
 */

Other notes: During implementation, take advantage of tools available to you in Eclipse. In particular, remember about options in the Source menu (such as for creating getter/setter methods, and for overriding/implementing methods). Write short methods, so that subclasses can selectively override small pieces. In most cases, methods should be no longer than 10 lines of code. Long, confusing methods may result in a poor grade on the lab. Any code that is less than obvious should be carefully documented.

What to turn in:

Use a 3-ring binder to keep all of your design notes throughout the semester. Include each design decision, the reasons for that decision, and what other alternatives were considered. There are forms on the CSE132 web site for this purpose. You will need to submit your design notebook at the end of the semester.

On Thursday, February 7, you will do a demo of your completed Lab 0 during your lab section. After the demo, and any accompanying review of your code, you and your lab partner should prepare the following packet to be turned in for grading on Tuesday, February 11:

1. A completed cover sheet.
2. Your final contract form, showing who completed which items of the project. Include each major class (view components, controllers, model components, etc.)
3. Your GUI layout design sketch (draft and final, if different)
4. Your use case scenarios (your original drafts are OK, even if some things have changed).
5. One completed design decision form per person, reflecting on a significant design choice or design change you made. Each person should write their name on their design decision form.
6. A 1-page handwritten module interaction diagram showing each of the major objects in your system, with labeled arrows showing the way they interact (events going to controllers, etc.) Do not go overboard with this. This is a high level sketch to explain at a high level how your code fits together. Use whatever notation you find natural to express the relationships between the objects in your system.
7. 2-3 pages of code (double sided) per person. This should represent your best work and should be a good sample of the various aspects of the project (view components, controllers, etc.) Please do not turn in extra code. Be sure it is clearly identified who wrote which sections of the code.

Note: For the forms, handwritten is fine, but if you prefer to type them, there are Word documents for these available on the CSE132 menu.