Java text (Savitch), p.162-164: choose one of #2, #5, or #8.
(#8: also generate or come up with your own cryparithmetic puzzle)
Java text (Savitch), p.247-248: choose one of #2 (Fraction), #3
(Odometer), #4 (BlogEntry), or #6 (StudentGrades).
Java text (Savitch), p.469-472: choose one of #3 (Alien), #6 (Truck),
#7 (Patient), or p.509 #4 (predator-prey).
The last option (p.509 #4) is worth up to 5 pts extra credit (45 total)
if done correctly and completely.
- In each case, you should have at least two classes: one which is
your solution to the lab, including attributes, constructor, and other
methods (e.g., Fraction), and another class which tests your main class
(e.g., FractionTest). The testbed class can have several methods in it;
you may use this for unit-testing each method in your main class.
- Your class should have at least: attributes (made private as appropriate),
constructors, set/get methods (including a toString() method),
plus whatever other methods are needed to meet the requirements.
- Provide constructors that take various different arguments to initialize
attributes, plus a constructor that doesn't need any arguments (choose default
values), plus a "copy constructor" that takes another object of the same type.
Create a simple database! ch10 p.637 #10 or #11, or a similar project of
your own design.
- For all options (this lab only),
provide detailed JUnit4 unit-tests for all classes
and all public methods (You do not need to do unit tests for private/protected
methods.) For example, unit tests for Truck and Vehicle would go in
TruckTest and VehicleTest.
- Write your test cases based on the pre-conditions and post-conditions for
your methods. Think about valid and invalid values for parameters.
- Try to be exhaustive in your test cases -- if any bugs creep into the
code for the main classes, then the unit tests ought to be able to catch them!
You can have multiple assertions within each test case.
- Files to upload:
- Parent.java, Parent.class (or whatever you've called your superclass)
- Child.java, Child.class (or whatever you've called your subclass)
- ParentTest.java, ParentTest.class
- ChildTest.java, ChildTest.class
- Write-up (doc, odt, pdf, html, txt, etc.)
Develop your own GUI program using Java Swing! Here are the requirements:
- Your program should provide
functionality -- this means that (at a minimum) the user should be able to:
- (C)reate new records,
- (R)ead (display) existing records,
- (U)pdate (modify) an existing record, and
- (D)elete an existing record.
- This also means you need to provide a way for the user to search
the database in various ways (e.g., by first name, by phone#, by title) so
the user can select which entry to read/update/delete.
- You should also allow the user to create an empty database,
save the database to file,
and load a previously-saved database from file.
- What is stored in the database is up to you -- list of people, list of
songs, list of ski resorts, list of creatures, etc.
- Define a class to represent a single record -- e.g., Person,
Song, SkiResort, Creature, etc. Make this class serializable and
use object-based I/O for the loading/saving of the database.
- To store the list of records in memory, you may use either an
array (but then you have to worry about the size of the array)
or an ArrayList (see ch14 for details).
- You do not need exhaustive JUnit unit-tests, but provide a simple
testbed program that clearly shows off all the functionality you
worked so hard to put in your program.
Suggestions for possible project ideas:
- It must be a cohesive program with a clear purpose
(i.e., not just a technology demo of Swing widgets).
- It must make extensive use of Java Swing for the GUI: this
includes widgets (buttons, menus, and/or text boxes)
and use of a layout manager.
- It must be interactive: you may use ActionListener or another
EventListener interface (e.g., MouseListener, MouseMotionListener).
- The design of the UI should be user-friendly, easy to use, and
not unbearably ugly. An average non-programmer computer user should be
able to figure out the controls even without help text.
- Have fun and make it cool!
- "Memory game": click on cards to turn them over; match pairs of cards to
clear them from the board.
- Calculator: either RPN or build an expression.
- Fast food ordering kiosk: select meals, options; get a total bill.
- GUI for your Lab4 database.
- Choose one of the following two options, either Android or TCP/IP client-server.
- On Tue 12 Apr, you will demonstrate one of your projects in-class, in the senior lab!
You may demonstrate any one of your labs, but you want to choose something cool to show.
If you don't want to use the lab computers, you may demonstrate it on your own laptop.
The presentation counts for the last 10pts of the project.
- Be creative and make it interesting! (That's part of the assignment!)
Write a cool Android application! You may demonstrate it on the software emulator.
If you like, you may also demonstrate it running on an Android phone (either my
phone, or your own)!
We might not have time in-class to get very far on Android, but there are many
resources to help you learn Android on the
Android developer site:
- Start with
how to get+use the Android Developer Kit with Eclipse (this is not provided
in the senior lab; you have to install it on your own computer).
- You may then want to try the
tutorial just to see what a running Android program looks like.
- The complete "book" on developing for Android is
the Developer's Guide.
- To supplement the book, you may enjoy watching
series of videos giving an overview of the Android software architecture.
- If you've seen
Android App Inventor,
you may also use that to build a cool Android app. However, it does not
produce editable Java code! The programming environment is a visual one
called Scratch, designed to be
easy for high-schoolers to learn.
If you elect to use App Inventor for this lab, you are responsible for
figuring out how to install and use it on your own computer.
Come up with your own cool client-server network application (e.g., chat/IM,
stock-ticker, sending pictures, web server)!
- Your application should have
(at least) two running programs, one for the server and one for the client.
- Both should have Swing GUIs that use multithreading to keep the GUI
- Your server should use multithreading to handle multiple clients simultaneously (demonstrate this).
- The messages you send over the network may be either plain-text or serialized objects.
- To facilitate running the demo, please make it easy to change the server and port,
on both the client and server (e.g., without recompiling).
- You may try your applications on two different computers in the lab!
Use ports 4410 and/or 4411.