A Multi-Message Email Reader

Lab 3

Due: 23:00 Monday September 22

During last week’s lab, you constructed a program that could be used to retrieve email messages from a

POP server. The interface provided by that program was kept deliberately simple to compensate for the

limited set of programming tools we had covered in class before the lab. All of the program’s actions

were controlled by a single button. In addition, the program gave very little feedback. Meaningful feed-

back would be useful to the typical user of an email program.

The goal in this week’s lab is to exercise your new knowledge about if statements by modifying your mail

reading program so that it provides a more flexible and user-friendly interface. The type of window that

should be displayed by this new version of the program is shown below.

The most notable difference

compared to last week is that

there are now 3 buttons: Con-

nect, Disconnect and Get Mes-

sage. When the user clicks the

Connect button, your program

should connect and login to the

mail server. When the user

clicks the Disconnect button,

your program should send a

“QUIT” message to the POP

server and close the connec-

tion. When the user clicks the

Get Message button, your pro-

gram should retrieve the re-

quested message. The text

area should be cleared before

the new message is displayed

so that only one message ap-

pears in the window at a time.

Notice that with this user inter-

face it is not necessary to login

for each individual message

that the user wants to retrieve.

While your program will always display these three buttons, there are restrictions on the sequence in

which the buttons should be pressed. For example, initially the only thing the user should be allowed to

do is enter account information and press the Connect button. Pressing either the Disconnect or the Get

Message button before logging in would clearly be incorrect. The improved version of your program

should ensure that the user cannot make such mistakes by selectively enabling and disabling buttons so

that only appropriate button clicks are possible. When the program first starts, only the Connect button

should be enabled. Whenever the user is correctly logged in, the Connect button should be disabled and

the Disconnect and Get Message buttons should be enabled.

Finally, if the user makes a mistake, your mail program should provide feedback that is more informative

than displaying a -ERR message. Instead, a message expressed in English that is free of any protocol

specific codes should be displayed in the message text area (i.e. the upper text area).

CS 150 (Profs Lawson and Szajda) Fall 2008

Partial preview of the text

Download A Multi-Message Email Reader - Laboratory 3 Report | CMSC 150 and more Lab Reports Computer Science in PDF only on Docsity!

Lab 3

Due: 23:00 Monday September 22

During last week’s lab, you constructed a program that could be used to retrieve email messages from a POP server. The interface provided by that program was kept deliberately simple to compensate for the limited set of programming tools we had covered in class before the lab. All of the program’s actions were controlled by a single button. In addition, the program gave very little feedback. Meaningful feed- back would be useful to the typical user of an email program. The goal in this week’s lab is to exercise your new knowledge about if statements by modifying your mail reading program so that it provides a more flexible and user-friendly interface. The type of window that should be displayed by this new version of the program is shown below. The most notable difference compared to last week is that there are now 3 buttons: Con- nect, Disconnect and Get Mes- sage. When the user clicks the Connect button, your program should connect and login to the mail server. When the user clicks the Disconnect button, your program should send a “QUIT” message to the POP server and close the connec- tion. When the user clicks the Get Message button, your pro- gram should retrieve the re- quested message. The text area should be cleared before the new message is displayed so that only one message ap- pears in the window at a time. Notice that with this user inter- face it is not necessary to login for each individual message that the user wants to retrieve. While your program will always display these three buttons, there are restrictions on the sequence in which the buttons should be pressed. For example, initially the only thing the user should be allowed to do is enter account information and press the Connect button. Pressing either the Disconnect or the Get Message button before logging in would clearly be incorrect. The improved version of your program should ensure that the user cannot make such mistakes by selectively enabling and disabling buttons so that only appropriate button clicks are possible. When the program first starts, only the Connect button should be enabled. Whenever the user is correctly logged in, the Connect button should be disabled and the Disconnect and Get Message buttons should be enabled. Finally, if the user makes a mistake, your mail program should provide feedback that is more informative than displaying a -ERR message. Instead, a message expressed in English that is free of any protocol specific codes should be displayed in the message text area (i.e. the upper text area).

Getting started For this lab, you should start with a copy of the code you wrote last week. To do this, use the Finder to locate the folder containing your Lab 2 project. Select the Lab 2 folder then use the Duplicate command in the File menu to make a copy of it. Now, rename your project with a name identifying it as Lab 3 and include your name. For example, if your name is Chocolate, you might name the lab ChocolateLab3. Also, remember to not include spaces in the name. When you open BlueJ, it will show your lab from last week. Keep this project open for a moment, as BlueJ will quit if you close the last open project. Use the Open Project command from the Project menu to find and open your Lab 3 project. After opening the Lab 3 project, you should close your Lab 2 project to avoid getting confused. Implementation plan Last week’s lab was designed to rely entirely on the dataAvailable method to retrieve lines sent to your program by the server. That is, the only invocation of in.nextLine within the program should have been within the dataAvailable method. During this lab, you will change the structure of your program to more clearly reflect the back-and-forth nature of the dialogue between the server and your client. Instead of relying on the dataAvailable method to invoke in.nextLine, you will place invocations of in.nextLine immediately after the instructions in buttonClicked that send the re- quests that cause the server to send lines to your program. When you are all done, the dataAvailable method will be removed from your code. This is a significant change in the structure of your program. As a result, even though you will start the lab with your working program from last week, the implementation plan suggested below will very quickly lead you to produce a program that does not actually work correctly. Don’t worry! When you are all done, everything will work as desired. The plan:

Add code to your constructor to display the additional JButtons that are part of the new interface. Eventually, you will want to be able to tell which button was clicked. To make this possible, you should associate each of these buttons with an instance variable name.
Modify the buttonClicked method to behave differently depending on which button the user clicks. To do this, you need to include the declaration of a JButton parameter in the method’s header as in: public void buttonClicked( JButton whichButton ) Within the method, use an if statement to decide which button is clicked and execute only those state- ments relevant for that button. When you do this, the invocation of addMessageListener from last week’s code should end up in the branch of the if statement that handles the “Get Message” button. As a result, your program will no longer work quite correctly. The problem is that you are not allowed to add a message listener to a NetConnection if you have added one already. Therefore, if you press the “Get Message” button several times in a row, your program will try to add itself as a message listener redundantly and you will receive an error message. We will address this issue in a few steps. For now, just check that you can connect, get one message, and then disconnect.

if ( condition ) { a list of statements that may or may not be executed } you can write while ( condition ) { a list of 1 or more statements to execute repeatedly } When the execution of a program reaches a while loop, the computer first checks to see if the condition specified currently is true. If not, it skips the list of statements provided in the body of the while loop just as an if statement would skip the statements it controlled. If the condition in the while loop is true, how- ever, it executes once the list of statements provided in the body of the loop and then it repeats the whole process. That is, it again checks to see if the condition is true, and then either skips the statements in its body or executes them a second time and then repeats the process again. While loops can be used to process multiple lines of data received from a server by repeatedly executing the statements required to process a single line. For example, in the WHOIS protocol client shown below (you need not understand the actual WHOIS protocol) , we use the dataAvailable method to process the lines of data received: public class WHOISClient extends GUIManager { //Size of the program's window private final int WINDOW_WIDTH = 600, WINDOW_HEIGHT = 600; // The name to request information about private JTextField query = new JTextField( 20 ); // Used to display the information requested private JTextArea results = new JTextArea( 20, 40 ); // The connection to the server private NetConnection toServer; // Display field, a button, and a text area; public WHOISClient() { this.createWindow( WINDOW_WIDTH, WINDOW_HEIGHT ); contentPane.add( new JLabel( "Name to look up:" ) ); contentPane.add( query ); contentPane.add( new JButton( "Request Info" ) ); contentPane.add( new JScrollPane( results ) ); } // Request and display information from the server public void buttonClicked( ) { toServer = new NetConnection( "dns411.com", 43 ); toServer.out.println( query.getText() ); results.setText( "" ); toServer.addMessageListener( this ); } public void dataAvailable( ) { results.append( toServer.in.nextLine() + "\n" ); } } We can revise this program to use a loop by replacing the line that invokes addMessageListener with the while loop shown below: while ( toServer.in.hasNextLine() ) { results.append( toServer.in.nextLine() + "\n" ); } The body of this loop is just the statement that had been used to handle lines received from the server in the original program’s dataAvailable method. The condition in this loop uses a method named hasNextLine. The resulting condition is true as long as there are still lines coming from the server. It

becomes false once the program has retrieved all the lines sent by the server before the server closed its end of the network connection. We would like you to use a while loop to process the lines of email messages your program receives from the POP server. In your mail program, however, you cannot use the hasNextLine method to describe the condition that determines when your loop should stop. The POP server does not close its connection when it finishes sending your program the last line of an email message. It does not close its connection until your program sends a “QUIT” command. Instead, the POP server tells your program that it has fin- ished sending all the lines of a message by sending a line consisting of just a single period. Therefore, the condition you should use will have the form: ! lineReceivedFromServer.equals( “.” ) (under the assumption that the variable named lineReceivedFromServer is associated with the text of the last line from the server). This condition states that the loop should be executed as long as the last line received does not (the! is interpreted as “not”) equal a single period. To use this condition, you will have to execute an assignment statement that associates such a name with each line retrieved from the server. This assignment statement, together with an invocation to append the contents of the line to your program’s large text area will form the body of your loop. The tricky part is that the computer will check the condition of your loop before executing its body for the first time. Your loop’s body will contain an assignment to associate a variable name with a line retrieved from the server, but this assignment will not be executed for the first time until after the loop’s condition is checked. If you ask the computer to check a condition involving a variable for which no assignment statement has been executed, your program will be terminated with an error since the computer will not be able to interpret the condition in any reasonable way. To avoid this, you have to retrieve the first line of the email message using an additional assignment statement to the same variable that is placed just before the loop. Thus, the overall structure of the lines to process an email message sent by the server will be: lineReceivedFromServer = toServer.in.nextLine(); while (! lineReceivedFromServer.equals( “.” ) ) { statements to process a single line lineReceivedFromServer = toServer.in.nextLine(); } Enter such a loop in your program to complete step 6 of our implementation plan. Submission Instructions Take a final look! When your program seems to be working correctly, take the time to test it thoroughly. Make sure to see how it behaves when you do unexpected things like leaving text fields empty or entering invalid message numbers. Make sure that fields come into and out of focus as you would expect. (Put yourself in the user’s shoes -- is your implementation as easy as possible to use?) After you are confident that your program is correct, you should take a few extra minutes to look over the code before turning it in. Look carefully for any errors that might exist but not have been serious enough to cause your program to malfunction during your testing. Next, look carefully at your programming style. Make sure your code is formatted in a way that makes it easy to read. Blank lines should be used to separate distinct components of your program. Indentation should be used to distinguish relationships. For example, the instructions that make up the body of a

A Multi-Message Email Reader - Laboratory 3 Report | CMSC 150, Lab Reports of Computer Science

Related documents

Partial preview of the text

Download A Multi-Message Email Reader - Laboratory 3 Report | CMSC 150 and more Lab Reports Computer Science in PDF only on Docsity!

Lab 3

A Multi-Message Email Reader

Due: 23:00 Monday September 22