Your task is to turn the Java Clock from https://github.com/mo04gw/Clock
into a multi-alarm clock. More specifically:
1. Add a menu bar and menu or menus to control the other additional features specified below.
The design of the menu system — how many menus and what the exact items are — is up to you. Try to keep it simple, do not cluster it. Consider to include:
- Add a button to the clock with the label “About”. Make it so that when a user clicks on this button a pop-up window appears with a simple message saying that you wrote the program.
- Add a menu bar with a “Clock” menu. (General principle: often in GUIs there are several ways for the user to do the same thing. It makes sense to have one action listener for each operation that can take place in the program, and to have it listen to each of the GUI components that can trigger that action. This way there is no repeated code. Nothing could be more frustrating to a user than to find that different things happen when they press a button or select a menu item for what should be the same action).
- Add an optional digital display, so that the clock can run in either digital or analog mode.
- Add a display date;
- Modify the system so that there can be more than one view observing the model. By selecting a menu item for a digital display, the system now adds a new digital display window (rather than changing the current window's display mode). Make it possible to fill the screen with digital and analog clocks all part of the same running application, all updating themselves off a single Model.
2. Add a Priority Queue of Alarm objects, so that the “next” one is the next one.
You will need to figure out how to incorporate this functionality into the Model-View-Controller architecture. Where does it belong?
You will need to design and build an Alarm class for storing alarm data and with whatever functionality is required.
3. Add a dialogue box for setting and editing an alarm.
Java Swing has components for dialogue boxes. You will need to research this and work out how to adapt these to your needs. You might want to just use text inputs for the hours, minutes and seconds, or perhaps JSpinner widgets. You need to decide what you think is the best solution taking into account what is best for the user and what you can actually implement.
You will need to add some user interface controls to the main window to trigger this activity: buttons, menu items… it’s up to you. For editing existing alarms, you will need an additional dialogue box for allowing the user to select an alarm to edit from the list (queue) of alarms already set.
4. When an alarm “goes off”, the application must display a popup box and then remove the alarm from the queue.
If you want to make the main clock flash, or make a sound, that’s fine, look it up, but the requirement is just to produce a popup. Similarly, if you can figure out how to have the popup grab focus from other applications, that would be great, but it is again beyond the scope of this assignment.
5. Add a feature that allows the user to save the alarms on disk in (a subset of) iCalendar format and read them back in when the program restarts.
This will obviously need some user interface triggers: buttons, menu items… your choice.
When the program exits, it should prompt the user to save their alarms. When it starts up, it should prompt the user to load saved alarms from a file. In both cases you can use the standard Java Swing file selector dialogues to select the location and file name.
You will need to read the specification for iCalendar and make a careful selection of the items you need to include. Make your files as simple as possible (but no simpler!). One file must be able to store multiple alarms. I suggest that you look at the VEVENT and VALARM items, but I leave the details up to you.
Your program does not have to be able to read all iCalendar files, just those it writes. But the files it writes must be correct iCalendar files that could be read by another program. There are several iCalendar validator projects on the web. Pick one and make sure the files that your program writes pass the validator.
Here’s a link to the IETF standard for iCalendar: https://tools.ietf.org/html/rfc5545. The Wikipedia page for iCalendar file format is a good introduction and has several useful links:
6. Add some visual display of alarm status.
There are many possible ways to do this. You could add an extra hand (perhaps a different colour?) to the clock display, like on old-fashioned alarm clocks. If you do this, probably it’s best to only display the next alarm. You could add a label at the bottom of the clock displaying the time of the next alarm (and perhaps how many alarms are stored…?). Or some other design of your own choosing. You might want to look at some other clock programs, perhaps on your mobile phone, for ideas.
Task 1 — Coding
Starting from the original version of the Java Clock (available from GitHub at https://github.com/mo04gw/Clock ), add the features listed above(use Java Swing for GUI interface). Pay attention to the structure of your code, so that it still follows the Model-View-Controller architecture. Add extra classes as necessary. Think about when you store the alarm, to think about the option of different day, in case the alarm will have the same time but different dates.(consider to include the date on the number you store for the time )
You have to comment your code(each method should have at least one comment) and in the same time to reference your source code.
For the priority queue of alarms, you should import the priority queue into your NetBeans project. I can provide the working implementation of Priority queue project and import it to use the sorted array PQ or Sorted linked list PQ for the project.
The code must work for Java NetBeans 8.2 version.
Task 2 — Testing
Unit test all classes using JUnit. You don’t have to test the priority queue library – as tests were done before.
Test your program that is working for a minimum of 5 alarms.
For GUI programs, you can’t do all your testing with JUnit. You should also do some system testing by hand. Document all your testing using a testing form. Write down some tasks that they should attempt (e.g. set an alarm, change the time of an alarm, delete an alarm, save the stored alarms, read alarms from a file).
Task 3 – Documentation
Add Javadoc comments to the code and generate detailed documentation for all the code. (Again, the Priority Queue library is excluded.)