HOMEWORK 2: Building Custom Swing Components

Objective

Additionally, you'll learn how to use Swing's MVC (Model-View-Controller)-like design patterns. While these patterns require you to build a bit of extra boilerplate code, they're the foundation for how Swing supports pluggable looks and feels.

The learning goals for this assignment are:

• Experience with the Swing drawing pipeline.
• Experience writing a variety of input listeners.
• Experience with using the Swing MVC patterns to architect a custom component.

Description

In this homework, we'll create a custom Swing component that serves as the content area of the notebook application. The basic idea is that this notepage component serves as a container for text and drawn strokes, simulating the appearance of a page in a paper notebook. There are a number of specific requirements for this assignment:

#1: Basic component architecture.

For this assignment, I'd like you to use this style in the implementation of your component. It's pretty easy to do (although it requires a bit of boilerplate code), and it gives you some pretty cool extensibility in terms of just dropping new interfaces on top of the existing data structures for your component.

There are several things you have to do in order to use the MVC style in Swing:

• Create a separate model class for your component. The model is the piece that contains the core data structures that represent the state of your component. In this assignment, the model will likely contain the lists of the strokes and text associated with the page (see below).
• Create a separate UI class for your component (in Swing the UI essentially combines the View and Controller from MVC). This class will be responsible for responding to user input (mouse and key clicks), as well as for drawing the component.
• Application programmers do not typically work with the model or the UI classes directly; rather, these classes are an internal architectural feature of a component's implementation. Your new notepage component should extend JComponent and have the necessary boilerplate to set up the model and UI objects that it'll use internally.

Hint: Look at the "MVC Meets Swing" link off the Supplemental Readings list for an overview of how this all works. Also, the Java Swing book has a nice section that shows how to do this in detail; look at pages 1133-1155.

#2: Paper-like background.

Hint: You can simply write a little routine that draws the necessary fills and lines, and call it first thing in your UI class's paint routine. This will ensure it gets drawn before any stuff that you render later in that route.

#3: Support for drawn strokes.

Hint: Remember that you'll need to redraw all of these same strokes anytime the Swing repaint pipeline tells you that you need to paint your component. So, the classic way to do this is to add strokes to a display list that contains the things to be rendered, and then in your paint code you simply iterate through the items to be painted, rendering them to the screen.

Hint: Painted strokes will look much better if you use Java2D's anti-aliasing mechanism. Look at the setRenderingHints() method on Graphics2D.

#4: Support for typed text.

• You should implement word wrap. This means that when your typing hits the end of the line you should find the rightmost whitespace in the line, break the line there, and put the remaining word on a new line. If there is no whitespace in the line then you can just break the line at the last character that will fit on the line.
• Use reasonable linespacing. Remember: ascent + descent + leading.
• You should reflow the text if the content area is resized. This means re-word wrapping the lines so that they fill the new page size appropriately.

• Backspacing over already entered characters.
• The ability to put the insertion point into already-entered text and edit it.
• The ability to select a span of text.

Hint: While all the word wrapping and reflowing stuff may seem difficult, it's possible to architect the code in such a way that you kill lots of birds with one stone. The key is to remember that, like with stokes above, you'll need to keep a data structure containing the text that will be rendered by your component. So one way to architect things is to simply create a new object to hold a text block whenever the insertion point is set; this object only needs to remember the insertion point and the set of characters entered at that point. Whenever characters are typed they are simply added to the current text block object. The job of your paint code, then, is simply to iterate over the list of text blocks and draw them to the screen, wrapping as you draw based on the current size of the page. This strategy will take care of word wrap and refilling via one implementation in the component's painting code.

#5: Integration with the rest of the application

Selecting New Page should create a new page and take you to it. Selecting Delete Page should delete the current page (unless there's only one page--your notebook should always have at least one page). You'll probably want to update your application to have a list of your notepage components so that you can keep track of them.

Selecting Previous and Next should move between the pages.

Extra Credit

• Fancier text processing
  • Allow editing of already-entered text. +2 points
  • Support backspace of entered text. +1 point
• More options
  • Customizable fonts. Either on a page-wide basis (+1 point), or for individual spans of text (+3 points).
  • Pen sizes and ink color: +2 points.
• Fancy features
  • Saving and loading of pages. It'd be cool if this happened automatically as strokes or characters are entered, so you never have to remember to hit "save." +3 points.
  • Other stuff. If you build in some particularly neat feature, make sure you let us know about it when you turn it in and we'll consider it for possible extra credit.

Deliverable

While this assignment is significantly more difficult than the previous one, most of the parts should be fairly straightforward. Start with the basic PLAF component architecture and get that working in your application first; one easy way to do this is to implement the UI class's paint method so that it only draws the page background. This way you'll be able to see your component show up and know it's working correctly. After this do the stroke processing (it's the next easiest), followed by the text processing (slightly more complicated). Finally, once all of this is working, it should be fairly straightforward to keep a list of notepage components in your application and make the New/Delete/Next/Previous controls work.

To turn in the assignment, please follow the same process as last time:

0. Make sure your program is runnable from the command line using the command "java NotebookApp" when run from inside your project directory (described below). Use exactly this name (with no package) to make things easier on me and the TAs.

1. Create a new directory using your last name as the name of the directory.

2. Compile your application and place both the sources and classfiles into this directory (they can be at the top-level or in a subdirectory, whatever you want).

3. Put a README.txt file into the top level of the directory. This file should contain your name and email address, the version of Java you used (1.5.x or 1.6.x, please) as well as any special info we migiht need in order to run your code.

4. ZIP this directory and submit via T-Square (instructions are here).

Please take care to remove any platform dependencies, such as hardcoded Windows path names or depencence on a particular look-and-feel that may not exist on all platforms. Also, if you use any images in your application, please make sure that you include these in your ZIP file and that your code will refer to them and load them properly when from inside the directory that's created when I unZIP your code.

Grading for this assignment, and future assignments, will roughly follow this breakdown:

• 60% functionality
• 40% good architectural design, coding style, commenting