Purposes of this assignment

• To get you started with Swing GUIs
• To give you more experience with JUnit testing
• To give you some experience with file I/O

General idea of the assignment

People often have to learn pairs of things that go together (in psychological jargon, paired associates). Given one of them (the stimulus), the person has to come up with the other (the response). For example:

• What's Dr. Dave's phone number? (stimulus: Dr. Dave; response: 8-8122)
• What's the capital of Pennsylvania? (stimulus: Pennsylvania; response: Harrisburg)
• What's the German word for mountain? (stimulus: mountain; response: der Berg)
• What do you get when you multiply six by nine? (stimulus: 6 * 9; response: 54 (or 42 for HHG fans))

For many things, especially foreign languages, you can buy boxes of flash cards. In this assignment, you will write a computerized version of flash cards.

In this assignment there will be two classes with a main method, and each of those classes will implement a separate GUI. The user wishing to study will start from one of the "main" classes; the user wishing to create or edit a study list will start from the other. However, this does not mean that they are two separate programs; the classes containing data will be used both to edit and to study from.

Terminology: The stimulus is what is presented to the user; the response is what the user is expected to provide. These are more general terms than "question" and "answer." I am using item to refer to the contents of a single flash card, that is, the stimulus together with the desired response.

Details

The study GUI

When the user is trying to study, here's what should happen:

1. The program reads in the requested study list.
2. For each unlearned item in the study list,
   1. The program displays the item's stimulus.
   2. The user enters a response into a text field.
      1. If the user's response is correct, the program increments the Item's timesCorrect instance variable and goes on to the next item; but
      2. If the user's response is wrong,
         1. The program sets the item's timesCorrect instance variable to zero.
         2. The program does something to get the user's attention (for example, play a sound, or flash something, or turn something red).
         3. The program displays both the user's (incorrect) response and the correct response.
         4. The user has to type in the correct response.
            • If the user mistypes the response, s\he has to try again until s\he has entered it correctly.
3. When the user has responded to all the items in the list, the list is shuffled "slightly"--that is, items in the list should end up close to where they were originally, possibly a bit earlier or possibly a bit later in the list.
4. If an item has been gotten correct four times in a row, it is considered "learned." It should be left in the study list, but will not be presented to the user again.
5. Return to step 2.

The user can quit the program at any time. There should be a button or menu item provided for this purpose; in addition, simply closing the GUI window should quit the program. If the user tries to quit without saving the updated study list, the program should use a Confirm dialog to ask if the user really wants to quit without saving.

Behind the scenes (studying)

At the beginning of a study session, the data is read in from a file. Each item on the file consists of: the stimulus, a double bar (||), and the response. Optionally, there may be another double bar, and the times correct. If the times correct is unspecified, it defaults to zero. For example (English-Japanese):

I want || hoshii desu || 4
I don't want || hoshiku arimasen
now || ima || 2
yes (casual) || ee || 3
at my place || watashi no tokoro de
at your place || anata no tokoro de
you are skilled || jozu desu
I am not skilled. || Jozu ja arimasen. || 0

The program then randomly chooses, from the input data file, a fairly small number of items to use (15 or 20; make this number a single final variable) and ignores the rest. It does not choose any items with a "times correct" greater than 3. This way, you can have a study list of a thousand items, and the user does not have to learn all 1000 at once. However, if there are fewer items than desired on the input file, use as many as there are.

Each stimulus and each response should be trimmed, using string.trim(), so that the student does not have to "learn" which words have leading and/or trailing spaces.

The editor GUI

In addition to helping the student study, the program should help the teacher build lists of paired items. The GUI should display the items and provide these operations on the list:

• Display the contents of the list. You can do this by displaying the entire list (in a scrollable area), or one or a few at a time, by allowing the user to step through the complete list.
• Add a new item (stimulus/response pair).
  • No two items can have the same stimulus (for example, you can't have a German study list with both stimulus klein||small and klein||little. If this happens, you have to ask the user what to do.
  • It is OK for two different stimuli to have the same response.
• Find an item, given either the stimulus or the response.
• Edit an existing item (because errors do happen and need to be fixed).
• Delete an existing item.

Plus, of course, you will need to be able to read in the study list, and write out the modified study list. You will also need to be able to Quit the editor. If the user tries to quit without first saving changes, use a Confirm dialog to make sure this is what they want.

Program organization

Separation of GUI classes and model classes

The GUI classes, which handle interaction with the user, must do no, repeat no, manipulation of the data in any way. All they do is handle events and call methods in the StudyList class. As far as the GUIs are concerned, they have no idea what their buttons, text fields, and other widgets are being used for.

There are two GUI classes, StudyGui and ListEditorGui. Each has a main method. What the program does depends on which class the program is started from.

The model classes, Item and StudyList, do all the computational work (in this case, all the file I/O and list manipulation). They do not access the GUIs in any way. In fact, if the GUIs were removed from the project, this would not result in any syntax errors in these classes.

The StudyList class also acts as an intermediary in any file I/O--if a GUI wants a file loaded or saved, it asks StudyList to do that. StudyList does not interact with the user; if, while writing the StudyList class, you feel the need to interact with the user, one way is to throw an Exception, and let the GUI class catch it and do the interaction.

Exceptions should not cause program termination. If an exception of any sort should occur, present the user with a Message dialog describing the exception, but allow the program to continue.

The GUI classes

class StudyGui

• Has controls to Load and Save files, and to Quit the program.
• Controls the interaction with the user: Displays stimuli, gets responses, displays feedback (from the StudyList object) to the user.
• Has a Quit command.

• Has controls to Load, Save, and Save As... files, and to Quit the program.
• Controls the interaction with the user: Displays items from the StudyList object and allows them to be edited.
• Has controls to Add, Find, Edit, and Delete items.

The model classes

class Item

Each Item represents one stimulus/response pair. Each Item should have a way of viewing and changing its stimulus and response parts (getter and setter methods should be good enough for this).

class StudyList

The StudyList class does no printing or GUI work--it just keeps track of data. Data consists of all the Items from the file, and an array of those items (maybe 15 or 20) currently being studied.

Grading

Each member of your team should take primary responsibility for one of the GUIs, and should specify (with the @author tag in the class) who did each GUI. Both of you should work together on the model classes. Your grade will be based 50% on your part and 50% on the whole thing.

This is a team programming assignment. It's not quite a pair programming project, because each of you is responsible for part of the code, and both of you are responsible for part of it. You can work together on the GUIs, but each of you should "own" one of them.

If for some reason you do not have a partner for this assignment, omit the ListEditorGui. You can construct test files in your favorite text editor.

Structure of the assignment

Begin by downloading the starter code from GitHub, https://github.com/DavidMatuszek/FlashCards.git. You can download the entire project and File→Import... it into Eclipse or, if this gives you trouble because of differing Java versions, you can just download the source files.

The flashCards package contains all of the classes described above, and method stubs for all of the required methods. You are, of course, welcome to have additional methods. Methods in the simpleIO package can be accessed by prefixing the method name with SimpleIO. .

Programming hint: It is your job to break each line up into a stimulus, a response, and a times correct. The method line.split(" *\\|\\| *") will break line into an array of those three Strings.

• Project name: FlashCards
• Package name: flashCards
• Fill in the JUnit tests in ItemTest and StudyListTest.
• Provide Javadoc documentation for all classes and methods, except JUnit tests
  • Document JUnit tests if they are complex or do something non-obvious

You may have additional methods as needed, and they should be documented and unit tested as appropriate.

Due date

Turn your assignment in to Canvas before 6am Friday, November 21.