2D1640 GRIP 2009
Cristian Bogdan

Lab 2: GUI programming

Goal

Give the students the possibility to learn the basics of well-architected GUI programming by practicing the Model-View-Controller paradigm and by using the Java Swing framework.

Estimated time

About 40 hours.

Background material

• Lecture material
• The Java Swing tutorial http://java.sun.com/docs/books/tutorial/uiswing/
• Google!

Task

Implement according to the video prototype below a production planner where the user can plan tasks on production lines. Task planning is visible in graphic and tabular view. Task data is visible in tabular view.

Redovisning

Please email to cristi at kth dot se (subject: GRIP Lab2) by March 3rd, 23:59:

1. Name of the (max 2) participants, personnumer
2. Application in runnable format, preferrably as executable jar file so it can be checked rapidly
3. Application source code as a ZIP
4. sketch of a UML diagram showing the most important classes and their relations

Please expect feedback, especially on the interaction. You may be asked to improve (especially the interaction) by March 6th.

Detailed description

The user should be able to:

• enter task data (customer, duration in days, earliest start date, latest delivery date)
• view graphical representations of tasks on production lines in a "task planning chart", visualize at a glance which tasks are planned too early or too late, and which come from the same customer.
• view a table representation of the tasks and their planing, where they can be created and edited.
• drag-and-drop tasks on the graphical representation to re-plan them on another production line, or to another time point on the same line. No tasks should ever intersect on a production line.
• either see the non- planned tasks in a "parking line" and drag them from there to production lines, or be able to drag and drop them directly from the table to the production lines, or both
• scroll the production line view to earlier or later time
• optional: resize the window to visualize the planning over a longer or shorter period. The table should grow/reduce in size proportionally on all columns (JTable usually does that), i.e. the table should take all the width it can take.
• optional: zoom the production line view on the time axis
• optional: mark weekends in the task planning chart and do not assume that a task is worked upon on a weeked (so if it reaches a Saturday, its duration is prolongued with at least two days)
• optional: sort the table by clicking on any of its headings

Attention should be paid to the intuitivity of the task drag-and-drop (see the suggestions in the video prototype), and on the effectiveness of entering new tasks in the table, or editing tasks in the table.

At startup, the program can show no tasks, or read the task data (and maybe some task planning data) from a file. It does not need to save the task and planning data at the end (we are interested in interaction, not persistence).

Please find a list of hints at the end.

Video prototype

For reference please use the video prototype below. It is meant to illustrate how the interaction described above could look like. Below the prototype movie you can find its approximate transcript, which you can use for your reference.

If you cannot view the prototype in your browser, try the YouTube version.

This is a simple production planner. It allows me to plan various tasks to a number of production lines that I have in my factory. I can see in the upper part a task planning chart with some production lines, on which tasks can be planned in relation to time, which i see marked at the top. In the lower part there is a table which keeps the task data. Each task has a customer, a duration in days, a date for its earliest start and a date for its latest delivery. Now it's time to enter some tasks. So I can press "new task" and fill in the data. And then add more tasks. The unplanned tasks are visible in a parking space at the bottom of the planning chart. If there is enough space, a task shows its customer name. When clicking on a task in the table, its graphical representation is highlighted, and it becomes the current task. To help me in the planning, the planner visualizes guidelines for the current task's earliest start and latest delivery dates. Another way to set the current task is to click on it in the planning chart. Then its table information becomes visible and highlighted. To find more information about a task in the chart without making it the current task, I can hover the mouse cursor over it to see the tooltip. It is time to plan the tasks I created. I can plan a task by dragging it and dropping it on a production line in the planning chart. [dragging makes it current task => highlighting] Once the task is planned, its execution start date, end date and production line are shown in the table. The new information is also visible on the task tooltip. If I plan a task before its earliest start or after its latest delivery, the respective parts of the task should be emphasized by a different color or texture. When planning a task, the task next to it might need to move to the future to make space for the newly planned task. Sometimes multiple tasks will have to move, like dominoes. If a task is already planned at the day when I want my task to start, I can drop my task explicitly over that task. The task previously planned at that date, and possibly others, will then move to the future. When I move a task away from a line, the tasks after it move to the left to fill the gap, as long as they don't move before their earliest start date. A similar move to the left happens when a task duration gets shortened, or when I delete the task all together (using the Delete button). When getting more specifications from a customer, I might have to change the duration of the current task in the table. Then it also has to be re-planned, possibly affecting the tasks planned after it. I might also need to change the earliest start or latest delivery of a task in the table. This does not involve re-planning but may change the task appearance. If I want to see tasks planned earlier or later than the ones visible, I can use the top scrollbar. To see a longer or a shorter time period, I can simply adjust the size of the window. The columns of the table should grow in width when the width of the window grows and decrease in width when the width of the window decreases.

Hints

The Model can be represented as a list of Task objects, each containing its customer (String), its duration, its earliest start Date and latest delivery Date.

As a task can be planned at most once, we can also represent the planning information in the Task object, or in an object it refers to. The Task planning information is some description of the production line, and the starting Date (the date when the task is planned to be executed on the line). The end date does not need to be represented as a field, as it can be determined by adding the duration to the starting Date (you can use e.g. Calendar.add), so a method is enough.

The Model must expose a task creation method. Then come the most important methods, of task planning to a line on a date (this can be also used when moving from a line to another), task editing and task deletion. When implementing these methods the model must ensure that no two tasks intersect on a line, so tasks already planned might need to move to the future (i.e. to be re-planned later) to make space for a newly planned tasks. To be able to rapidly detect whether there is potential for task intersection, it may be a good idea to keep the planned tasks sorted after their planned start date.

An important advice is to try to get this "no task intersection" functionality to work in a standalone, non-graphical program. This is a benefit of MVC, it allows us to separate the concerns of data storage and manipulation from those of data visualization and interaction.

Optionally (for easier task planning) the model could also provide the functionality of re-planning tasks earlier (as long as they do not go before their earliest start date) if "space" on the production line becomes available.

To be able to notify its views, the Model could extend Observable. The views can then implement Observer. You can use the object passed to the Observer update method to tell what happened in the model (a Task was added, edited, planned, etc). One operation (e.g. a task planning) can generate one or more updates of the views.

There should be no reference to the view classes (or to java.awt, or to javax.swing) in the model code. Models don't know how they are viewed.

View1: the task table

Can be easily implemented using JTable, and reading the underlying Model to populate the table. The task planning start, end and line columns (the rightmost 3 columns) are not editable, this can be configured in JTable.

View2: the planning chart

The planning chart could include the parking line or a separate view can be created for that.

Important parameters of the planning chart is the "visualization period", i.e. which date is represented by the leftmost margin of the chart, and which date by the righmost. The visualization period can be regarded a higher-level data model, which the planning chart can use, on top of the basic model described above.

The production lines (and the parking line) can be represented as components that are grouped in e.g. a vertical FlowLayout so they remain nicely aligned. Implementing the production line components can be done in various ways:

• one single component that draws (using paint() ) the tasks planned within the visualization period, as rectangles
• a container that includes each planned task as a separate component. In this case, no layout manager should be used (set it to null) as the tasks are often not adjacent to each other, and don't need to change their size when the application window changes size.

Another goal of the planning chart is to show and change (with a scrollbar) the visualization period. In some way the user needs to know what period is being visualized and also see some markers for days and possibly weeks.

The "current task" data model

This higher-level data structure is a piece of data that is needed by both the table view (to highlight a table line) and the planning chart view (to highlight a task rectangle). Both views can register themselves as observers also to this model (in addition to the basic Model above). In such a way, when a view changes the current task, the other view will be notified and can update the current task in its turn.

Controllers

Some of the most important controllers in the application:

• The New button controller (ActionListener) can simply add an empty task to the Model. This will lead to the views being notified so the table will add an empty line, which will alow the user to enter task data.
• The task Delete button controller must also read the "current task" data model to find out which task to delete from the basic Model.
• To allow for planning, drag and drop is needed. You can do that in three ways:
  • Own-programmed drag and drop using mouse listener, mouse motion listener, and painting the drag cursor in the paint(Graphics g) method (or paintComponent) of a Container (like the upper Panel, or the whole JFrame). Don't forget to call super.paint(g) so that the usual Swing painting takes place as well. Own-programmed drag and drop is enough for the lab purposes.
  • AWT 1.1 drag and drop. Quite complex to use. Allows for inter-application drag-and-drop which is not needed here.
  • Swing Drag and drop, a bit easier to use, works well on standard Swing components. For own-defined components it needs some elements of AWT drag-and-drop.
• When the task is dropped on a line, the method exposed by the Model to move a task will be invoked.
• The table must have a controller attached, which listens to table cell change events and asks the model to change accordingly. Also, changes of the current task (clicking on another table row) can be detected by this controller, and the "current task" model can be changed then.
• The planning chart view controller will also need to detect clicks (with no drag or just before the drag) on the task rectangles, to change the "current task" model.
• Optionally, drag and drop can be programmed from the table cells so a task can be planned by dragging any of its table fields to the production lines.