Due Date: Thursday, August 11 (last day of class)
- event-driven program execution
- state dependence in application (the State design pattern)
- Model-View-Adapter architecture
- Android framework
Functional Requirements (5.5 points, worth 65%)
The timer has the following controls:
- (0.5) One two-digit display of the form 88.
- (0.5) One multi-function button.
The timer behaves as follows:
- (0.5) The timer always displays the remaining time in seconds.
- (0.5) Initially, the timer is stopped and the (remaining) time is zero.
- (0.5) If the button is pressed when the timer is stopped, the time is incremented by one up to a preset maximum of 99. (The button acts as an increment button.)
- (0.5) If the time is greater than zero and three seconds elapse from the most recent time the button was pressed, then the timer beeps once and starts running.
- Note: if the time reaches the preset maximum of 99 the timer acts the same way as if three seconds had elapsed - it beeps and starts running.
- (0.5) While running, the timer subtracts one from the time for every second that elapses.
- In particular, the display only changes 1 second after the 3-second timeout occurs or the timer value reaches 99.
- (0.5) If the timer is running and the button is pressed, the timer stops and the time is reset to zero. (The button acts as a cancel button.)
- (0.5) If the timer is running and the time reaches zero by itself (without the button being pressed), then the timer stops and the alarm starts beeping continually and indefinitely.
- (0.5) If the alarm is sounding and the button is pressed, the alarm stops sounding; the timer is now stopped and the (remaining) time is zero. (The button acts as a stop button.)
- (0.5) The timer handles rotation by continuing in its current state. Note: there is nothing specific you have to do to get this to happen.
Extra Credit (2 points, worth up to 24% extra credit)
- (2.0 extra credit) Add a 2-digit editable text area, editable only when the timer is stopped, where the user can type in the time and then press enter or click the button to start the timer.
- Note that this will require the emulator or device to have a physical or on-screen keyboard to enter the digits, and it is a non-trivial addition to the project!!
Nonfunctional Requirements (1 point, worth 12%, plus 1.5 points, worth up to 18% extra credit)
- Ensure your application is testable.
- (1.5) Ensure your application includes comprehensive unit, integration, and functional tests using the techniques from the clickcounter and stopwatch examples where appropriate. (See also http://developer.android.com/tools/testing/testing_android.html) - now extra credit: if you add timer-specific tests you can earn up to 1.5 extra points
- (0.5) Follow the design principles discussed so far.
- Maintain a clear, responsibility-based separation among the different building blocks. It is recommended that you start with the stopwatch example.
- The adapter should be lean (as in the stopwatch example).
- Most of the complexity should be buried in the model (also as in the stopwatch example).
- Unlike the stopwatch example, the dynamic model (state machine) has guards involving the current time. Think carefully how to inject the dependency on the time model into the state machine. Do not use static members!
- (0.5 extra credit) Use of the state pattern (APPP chapter 36) is recommended. If you reuse and update the stopwatch example, you will likely get this extra credit.
- Generally follow good Android development practice: http://developer.android.com
- Use this Timer class: http://developer.android.com/reference/java/util/Timer.html
- (0.5) For beeping, use media playback to play a notification sound (or some other suitable mechanism):
Written Part/Documentation (2 points, worth 24%)
Please include these deliverables in the doc
folder of your project 4.
- (0.5) Include the model from a future in-class group activity. (Minimally, a cell phone scan of your drawing is acceptable.)
- (0.25) Use inline comments to document design details in the code.
- (0.25) Use javadoc comments to document how to use the abstractions (interfaces, classes) you designed.
- Include a brief (300-500 words) report on
- (0.5) Your group development journey during this project. Focus on aspects you find noteworthy, e.g., process, group work, testing, design decisions, refactoring, use of the repository.
- (0.5) The relationship between your state machine model from this project and your actual code. Possible talking points are:
- What are the similarities and differences between model and code?
- Is it more effective to code or model first?
- Now that you have the code, what, if any, changes would you make to your model?
- Stated percentages for the major categories
- Stated points for the specific items
- Total 8.5 points (100%) with opportunities for up to 3.5 points (42%) of extra credit
- Deductions of up to 1 point for
- deviation from the required project folder structure (see clickcounter)
- inability to run and/or test
How to submit
As the first step in working on this project, one of your larger team members will push the code skeleton to a private Bitbucket repository shared among all of you and your instructor and TA. The name of the repository is cs313su16groupNp4 or cs413su16groupNp4, where N is your group number found in the state machine class exercise slides from Week 9. When your work is ready to be graded, please notify your instructor via Piazza and/or submitting a note in the Sakai Project 4 assignment.