Final Projects

All of the mock app store submissions have been posted online.

Final Projects

Final Project — Presentation & Demonstration

Due Date (for Slide Submission)

Wednesday, December 15^th — 11:59pm

Background

Final project presentations and live demonstrations will occur during the time allotted for the final exam (Thursday, December 16th 6–8pm). Each group will be scheduled a 3½ – 4 minute chunk of time for their presentation and demonstration. This time limit will be strictly enforced. The specific order of presenters will be determined next class.

Your presentation should consist of a minute or so of slides which present an introduction to your application, followed by an actual live demonstration of your app.

Your slides must be in PDF format and should contain the following content…

• Title slide — consisting of app icon, app name and team member names
• App Description slide — a one slide overview of your application
• Frameworks, Libraries & 3rd Party Services slide — a one slide that lists frameworks, libraries or services used by the app and mentions what they were used for
• Backup Demo Slides — in the event that something fails during your live demo, you should have screen captures that are capable of being used as backup

Your demonstration should highlight the key features of your application. You are strongly encouraged to rehearse your demonstration ahead of time.

Demo Information

I will be building and installing all apps into the iPhone Simulator on my laptop for the demonstration. To ensure a smooth demo, I recommend the following…

• When testing your app, I would strongly suggest that you remove your app from the simulator and try a fresh build & install before submitting to avoid any issues caused by (lack of) residual artifacts.
• Perform a dry run on the demo hardware — I will be holding special office hours Tuesday, December 14^th 5:30–6:30pm where you can stop by and do a dry run on the actual machine that will be used for the demos.

If your app requires features that are not supported on the simulator (such as camera, accelerometer, etc.) email me as soon as possible so we can make the necessary accommodations.

Submission

To submit your slides, open up a terminal, navigate to the directory containing your slides then issue the command:

submit cs491i final-slides slides.pdf

Final Project — Mock App Store Submission

Due Date

Tuesday, December 14^th — 11:59pm

Background

If you were publishing an application on the App Store, you would need to provide information about your app for submission. To simulate that experience, you will prepare a mock App Store submission.

For this write up I’ve provided a zip file which you must use as a template for writing up the details of your app. This zipfile includes an HTML file that when viewed in a web browser displays a page similar to that on the App Store.

All mock App Store submissions will be aggregated and posted on the course blog prior to the final presentations.

Zip File Structure

The zip file contains the following directory structure…

appstore/
|-- resources/
|   |-- images/
|   `-- ...
`-- username/
    |-- 1.png
    |-- 2.png
    |-- 3.png
    |-- 4.png
    |-- 5.png
    |-- Icon-175.png
    `-- index.html

You’ll be doing all your work under the username directory (which you’ll rename). The contents of the resources directory are supporting files referenced by the index.html document and should not be edited.

Modifications

You will need perform the following…

1. Rename the username directory to your myUMBC username. Multi-person teams should hyphenate the names (e.g. user1-user2).
2. Replace Icon-175.png with a 175px x 175px PNG icon for your app.
3. Replace [1-5].png with 3-5 screenshots from your application. Screenshots should adhere to the following size constraints…
   • iPhone & iPod touch — 320px x 480px (portrait) or 480px x 320px (landscape)
   • iPad — 360px x 480px (portrait) or 480px x 360px (landscape)
4. There are several things you need to edit in the index.html file. Each item that needs to be updated has been tagged with a “TODO:” in the comments (use a text editor and search). These include…
   1. Replace “App Name” with the actual name of the app (2 places)
   2. Update “John Doe & Jane Smith” with the actual author(s) (2 places)
   3. Replace the sample description with a description of your app. Do not use any special HTML or emoji within the paragraphs. If your app requires features found on certain devices (i.e. a camera) state so in the description. Do not include testimonials or reviews like you may see in some descriptions.
   4. Update the Website link to your web page (or remove the link)
   5. If you do not include 5 screenshots then remove the links for the extra screenshots (again, you must include between 3–5)
   6. Identify the category that best fits your application — a full list can be found in the comments
   7. Modify the list of devices to reflect the devices your app supports
   8. If your app required iOS 4.1 or iOS 4.2.1, then update the iOS requirements to reflect what is needed

Tips

• iOS News and Announcements for iOS Developers — App Store Tip: Creating A Great Presence on the App Store
• See the “Use the App Store to Your Advantage” section in the iTunes Connect Developer Guide for app store submission tips
• Browse the App Store from within iTunes or preview apps online to get a feel for descriptions used by apps on the store

Submission

Once you’ve made the changes to the provided HTML file and swapped out the sample icon and images with your own package it up by zipping up the entire directory tree.

To submit your mock app store submission, open up a terminal, navigate to your zip file then issue the command:

submit cs491i final-appstore appstore.zip

Final Project — Source Code Submission

Due Date

Monday, December 13^th — 11:59pm

Grading Criteria

Grading criteria for the final project will be based on the criteria from the week-long assignments…

• Correctness of application
• Appearance of application
• Adherence to Objective-C and iPhone coding conventions
• Neatly formatted and indented code
• Well documented header files
• Absence of significant performance issues
• Absence of memory leaks

…as well as…

• Scope — Is the app sufficiently complex? Does it deliver what was proposed?
• Polish — How polished is the app? Does it have a launch screen image? Does it have an app icon? Are high-resolution Retina display graphics included? Is the app appropriately named? Is the user experience well thought out?
• Interesting, novelty and uniqueness — Is the app interesting, or is it just a remake of an already existing app? What’s the overall coolness factor?
• Required Elements — Does it contain multiple views? Does it persist some form of data?
• Suggested Elements — Does it contain sound effects? Does it contain animation?

Submission

Like all of the short projects this semester, you will need to submit your source code and necessary resources for grading. You should remove your build directory and zip up the directory containing your Xcode project.

To submit your final project source code, open up a terminal, navigate to your zip file then issue the command:

submit cs491i final-code project.zip

Final Project — Progress Report & Code Submission

Due Date

Slides and current project source code must be submitted electronically by: Wednesday, November 24^th — 11:59pm

Background

With just under a month left before final projects are due, you will be submitting a progress report that describes in detail the overall flow of your application as well as your progress against the final project delivery. You will be expanding your oral presentation into a progress report that documents how the project implementation is progressing.

This progress report will be used for the following:

• As a last chance to make sure that the project is of sufficient scope and make course corrections (if needed)
• To communicate the overall flow and interaction between the various screens of the final app
• To establish a more detailed expectation as to what the final app will look like
• To try to nail down and identify all Apple and third party frameworks/APIs used by the app
• Identify progress against the final project delivery

Please note — the syllabus had originally called out the “Detailed project plan” and “Progress report” as two distinct deliverables. To save time and duplication of effort, both of these items will be condensed into this single progress report and source code submission. Since this progress report will contain the same content (albeit in one document) it will carry the combined weight of both assignments as originally detailed on the syllabus.

Slides

Your progress report should contain the following slides:

• Title slide — name of app & group members
• Overview slide — a couple of bullets that summarize what your app does (you should only need to update this slide if there are significant changes).
• Changes From Proposal — if you’ve dropped or added anything since your oral proposal detail those changes here (e.g. if you’re using different data sources, different APIs, dropping some features and adding others, etc.).
• Significant Completed Tasks — several bullet points mentioning significant accomplishments thus far (e.g. screens that you have started or completed, 3rd party data sources or libraries/frameworks/APIs that you’ve successfully integrated, etc.).
• Significant Incomplete Tasks — detail what large outstanding tasks you have yet to complete.
• Significant Issues — if you’ve hit any roadblocks, setbacks, or do not know how to get started with something, detail those issues here.
• Apple Frameworks Used — bullets detailing what Apple frameworks (or sample code) you’re using.
• 3rd Party Frameworks Used — if you’re using any 3rd party frameworks (e.g. Twitter, Facebook, Core Plot, etc.) call them out here.
• 3rd Party Data Sources — if you are consuming any 3rd party services (e.g. RSS feeds, web services, etc.) document them here.
• Anticipated Final App Flow — here you should document the various screens of your application and illustrate the flow between those screens in the form of a flowchart or state diagram. The boxes should represent the different screens and the arrows should indicate the actions that result in the transition between screens. This chart should include all anticipated final screens of the application.
• For each screen detailed on the flow chart slide, you should provide a slide containing the following elements
  • Screenshot — an actual screen capture of that screen taken from either an iOS device or from within the simulator. This should be a screen shot and not a screen mockup — everything appearing in the capture should also appear on the device/simulator when running your submitted code. Note that it is fine if screens or portions thereof are not complete or just have place holders at this time.
  • Completed Bullets — based on the screen shot, document what portions of the screen have actually been completed and what was implemented to back them (e.g. if you have a table view with data, explain that the data source has been implemented and where it’s getting its data from). If something is only partially completed (e.g. data in a table might be displayed, but it’s currently canned and not live data) document it as such.
  • Incomplete Bullets — If you are missing screens or have not implemented portions of a screen, document what’s left to be completed and how it is going to get done.
• Self Evaluation of Progress — evaluate your progress against what you’ve documented as delivering by the end of the semester. If you feel you’re on schedule say so. If you feel you’re ahead or behind schedule try to specify specifics as to what you feel your ahead or behind on. If behind, please document how you’re going to catch-up.

Example

Below is an example progress report for the Stocks app that’s been used as an example for previous final project deliverables.

Progress Report

Source Code

You must also zip up and hand in your source code thus far. Your source code is not expected to be pretty, nicely formatted, well commented or even free of memory leaks/crashes at this stage. However, your source code should be build-able and run-able.

As a reminder, be sure to remove the build directory and ensure all necessary resources to bundle up the app have been copied into the project.

Submission

Like the previous final project deliverables, your slides must be submitted as a PDF document. Your source code should be zipped up and submitted as well.

If you are working with a partner, only one of you should submit the slides & source code.

Submit using the command:

submit cs491i progressreport slides.pdf project.zip

If authoring on your own machine, you’ll need to transfer the file into your GL account (via SCP) and then SSH into GL and issue the submit command.

Assignment 5 — Four in a Row

Due Date

Monday, November 8^th — 11:59pm

Background

This project is designed to give you some hands on experience with…

• Using Core Graphics to generate custom UIViews
• Using action sheets to prompt for user input
• Handling touch-based events and updating graphics accordingly

Task

For this assignment you will be writing a basic Four-in-a-Row app. Your implementation will be a 2-player version of the game where the iOS device could be passed back and forth between two players. This saves you the overhead of implementing an AI to play against.

Your application needn’t look identical to the one shown in the description, but must it contain the following elements…

• A toolbar with a button that allows the user to start a new game
• A large game board that must be rendered using Core Graphics and contain the following elements:
  • The main game board section that has holes in it to see the dropped piece (yellow in my screen shots)
  • Legs on each side that protrude below the bottom of the main board section (blue in my screen shots)
  • Pieces visible through the board as they are dropped into a column (red and black in my screen shots)
  • The piece about to be dropped should be rendered above the currently selected column (red and black in my screen shots)
• A “status” label that informs users of whose turn it is and alerts users to wins/losses/ties
• Running totals for:
  • Red Wins
  • Black Wins
  • Ties

Main App Behavior

When your app initially loads it should look similar to the screen shown below. When the app is launched a game should automatically start and whose turn it is should be shown in the status area.

Initial Screen

The user starts the column selection process by pressing their finger down over a column. When the finger is pressed down (and not yet released) the player’s piece should appear centered above the column their finger is over. The user should be able to drag their finger left and right, and as they do so, the marker should switch columns as needed. You’ll need to detect where the user has their finger and draw accordingly (in my implementation the finger can appear anywhere “in” that column for the full height of the UIView). A finger press is shown below.

Finger Press over the Center Column (Red's Turn)

Only when the user lifts their finger should the selection be finalized and the piece dropped to the bottom-most free row as shown in the screen shot below. Note that the status has also been updated to reflect black’s turn.

Finger Release over the Center Column (Red's Turn)

The screen shot below shows the finger press down for the black player. Notice that the piece is now black at the top when the user presses their finger down.

Finger Press over the Center Column (Black's Turn)

Again, only when the user’s finger is released should the current column be selected as shown below. Notice that the status is once again updated to reflect the red player’s turn.

Finger Release over the Center Column (Black's Turn)

As users drop pieces into the game board your app should check to see if a user has one by getting four-in-a-row on the horizontal, vertical or either diagonal. If a four-in-a-row is detected, your app should notify the winner in the status area. Additionally, your app should draw a line on the board indicating the four-in-a-row as shown below.

Red Win

If the game board is not currently in play (someone won or there was a tie) and the user presses the “New Game” button, the app should clear the board and alternate user turns. Below we see the result of pressing the button — it is now Black’s turn.

New Game

If the game is not over and the user presses the “New Game” button, an action sheet should should pop-up to confirm that the user really wants to abort the current game as shown in the screen shot below. If the user accepts, the board should be reset. If they decline, then game play should continue uninterrupted.

New Game Confirmation

Your app should be smart enough to not show the user’s piece above the board if the column is full (or if the game is over). For example, if the user presses their finger down in the column immediately left of center the piece should appear…

Finger Press over the Left of Center Column (Black's Turn)

…then if they drag to the right, the piece should disappear from the column left of center, and when moving to the center column should appear as a hollow piece since the center column is full…

Finger Press over the Center Column (Black's Turn)

…but if they continue to drag to the right, once they clear the full column, the marker should reappear as normal…

Finger Press over the Right of Center Column (Black's Turn)

If the board gets completely full without a win, an appropriate status message should be updated. Pressing over any column should have no effect.

Tie Game

Persisting Data

There are no persistence requirements for this assignment.

Hints

As usual, the first thing I’d probably do is to design the initial screen and identify outlets, action methods, etc. You can probably build out the initial UI pretty quickly — less the custom UIView being drawn to by CoreGraphics.

To tackle the UIView that’s rendering the game board I’d recommend starting by sketching out on a piece of paper the overall outline of the board and position of notable items (e.g. legs, main board, position of holes & location of hover pieces). You really need to plan out the dimensions of all of these elements before digging in. I’d recommend making this UIView as large as you can in IB and jotting down the dimensions so you know what your constraints are.

Once you know the positions of the items you will be drawing, I’d move into actually building out and rendering those items. It probably makes sense to start with the 2 legs and main board. Once you have that positioned appropriately, I’d them move onto painting the pieces in the board (perhaps hard coding some to make sure you have that logic figured out). You’ll want to figure out how to do this using loops — you really don’t want to specify the coordinates of all 42 holes.

After you have the static board drawn, I’d then move onto capturing the finger events and simply logging which column on the board you’re over. Once you know you have that correct, you can move onto actually trying to render the piece in real time. Next, I’d probably write the code to actually drop a piece into the correct position when the finger is released.

Once you have that done, it’s a matter of implementing the game logic — alternating turns, checking for wins, updating UI labels, etc. You’ll want to handle suppressing the piece if it shouldn’t be displayed. You’ll also need to wire in the “New Game” button and add the action sheet.

Lastly, don’t forget that you need to draw a line through the four-in-a-row. Think about what information you need to draw this line and where/when you have it.

Additional Ideas

The following items are provided as thoughts as to how you might extend or improve the project beyond the basic requirements. You are not required to implement any of these.

• Customize the game pieces
• Add in some animation (e.g. show the piece dropping to the correct slot)
• Try out alternate color combinations — just don’t make my eyes bleed
• Feel free to play with the layout and style of elements — just be sure that things are neatly aligned and that there is at least some justifiable method to your madness
• Add your own images

Submission

Like the previous assignment, you are required to submit a zip file of your project directory. Be sure to manually remove the build directory before zipping things up.

To submit the assignment, open up a terminal, navigate to your zip file then issue the command:

submit cs491i assignment5 Assignment5.zip

If developing on your own Mac, you’ll need to transfer the file into your GL account (via SCP), then SSH into GL and issue the submit command.

Assignment 4 — Geospatial Photo Album

Due Date

Wednesday, October 27^th — 11:59pm

Background

This project is designed to give you some hands on experience with…

• Using the Map Kit APIs to display various maps and annotations
• Use of various delegates and protocols — e.g. UITableViewDelegate, MKAnnotation, etc.
• Saving and restoring GUI state
• Saving and restoring information via iOS’s preferences (defaults) system — e.g. NSUserDefaults
• Displaying modal views
• Loading data from plist files

Task

For this assignment you will be writing an app that allows a user to take a tour of several pre-defined locations on a Map. Your application needn’t look identical to the one shown in the description, but must it contain the following elements…

• A toolbar where the user can select which type of map they want to see — standard map, satellite, or a hybrid
• A large map view that will contain pins for each pre-defined location that will display an annotation (with disclosure arrow) for the current pin that allows the user to get additional information
• A second toolbar that contains several buttons…
  • A locate button that shows the user’s current location on the map
  • Previous and next buttons that allow the user to visit the previous/next site

Additionally, your application must also include a flip-side view that presents more detailed information for a given location…

• The name of the location
• An image associated the location
• A multi-line description
• A button to return to the map

Main App Behavior

When your app initially loads it should look similar to the screen shown below. When the app is launched all locations should be drawn on the map with pins.

If it is the first time that the user has ever launched the app, it should automatically select the first location from a list of locations, zoom in on it and display its annotation. If the user had previously launched the app then the map view, selected map style and show location status should be restored as well as opening the annotation of the last location selected by the previous/next buttons.

Initial Screen

The application must support allowing the user to switch between the 3 various map types. Below shows the resulting screen after the user presses the satellite segment.

Satellite View

If the user presses the disclosure arrow on an annotation, it should trigger a flip-style animation to a view that shows details about the location that was selected. Below, we see this animation mid-flip.

Animating to the Flip-Side

The flip-side view must neatly present the title of the location and associated image. Additionally, the description associated with the location is shown in a multi-line text view that allows the user to scroll. This back-side view should also contain a button to return back to the front-size of the application. None of the fields on the flip-side should be editable by the user. When the user presses the button to return back to the map the view should animate (flip) back to the front.

Location Details on the Flip-Side

If the user presses the previous or next buttons they should be displayed the previous/next location in the list. These navigation buttons should act in such a way that they wrap around. When navigating in either direction, the new location should be centered on the map and its annotation should be automatically opened. Below we see the result of the user pressing the next button.

Navigating to the Next Location

If the user presses the show location button (bottom left of the screen shot below), then the users location should be shown on the map as illustrated below. You shouldn’t recenter the map, but just show the user’s location. Note that this button acts much like a toggle button — when the user presses the button it should appear on until they press it again to turn it off (similar to the the Maps app).

Showing Location

The user should be able to pan and zoom with the map. Below is an example of pinching to zoom out.

Zoomed Out

Persisting Data

For this assignment, you must use the preferences system (i.e. NSUserDefaults) to persist and restore the following 4 pieces of data between app restarts…

1. The map style selected — when the app exits the current map style should be saved and when the app starts back up both the map and control should be put back as the user left them.
2. The current location — the last location that the user had opened using the navigation buttons should be remembered, such that if the user clicks next, the pick up where they left off.
3. The map region — the last view that the user had should be restored when re-opening
4. Show location state — if the user had their location shown on the map when exiting, it should be restored and put back on upon restart.

Provided Resources

For this assignment I’ve provided a zip file that contains the following:

• A sample locations.plist data file
• 5 photos (JPGs) that are referenced in the data file
• The icons (PNGs) that I used for displaying the location, previous and next

The plist data file describes the various locations. The plist is structured as an array of dictionaries, where each dictionary represents a specific location. Each location contains the following 5 keys/values…

• title — the name of the location (a string)
• description — the description of the location (a string)
• image — the name of an image file that should be displayed for the location (a string)
• latitude — the latitude of the location (a number/real)
• longitude — the longitude of the location (a number/real)

Hints

One of the first thing I’d probably do is to identify properties, outlets, and action methods for both the front and flip sides. Next, I’d probably recommend building the font-side part of the app and get that working. Then add in the annotations and the flip-side view. Lastly, I’d add in the ability to save and restore the required preferences.

You might be tempted to use a utility app for this project, though that’s not what I did. I stuck with a view-based app and built out a second view controller and then programmatically displayed the second view.

Poke around UIBarButtonItem to figure out how to get a highlighted button style when the show location button is pressed (as shown in the example above). You’ll find something that gives you that highlighted (and regular) look.

In terms of documentation, I found the following useful…

• Location Awareness Programming Guide
  
• Map Kit Framework Reference
• The documentation within Xcode the various Map Kit APIs reference several example projects — there’s some useful examples in there for the more complex annotations used in this application

Additional Ideas

The following items are provided as thoughts as to how you might extend or improve the project beyond the basic requirements. You are not required to implement any of these.

• Create different lists of locations and provide a UI to let the user choose which one(s) to view
• Try out alternate color combinations — just don’t make my eyes bleed
• Feel free to play with the layout and style of elements — just be sure that things are neatly aligned and that there is at least some justifiable method to your madness
• Add your own locations

Submission

Like the previous assignment, you are required to submit a zip file of your project directory. Be sure to manually remove the build directory before zipping things up.

To submit the assignment, open up a terminal, navigate to your zip file then issue the command:

submit cs491i assignment4 Assignment4.zip

If developing on your own Mac, you’ll need to transfer the file into your GL account (via SCP), then SSH into GL and issue the submit command.

Assignment 3 — Task List App

Due Date

Monday, October 18^th — 11:59pm

Background

This project is designed to give you some hands on experience with…

• Using additional iOS widgets — e.g. UIPickerView, UIDatePicker, UITextField, UISegmentedControl, etc.
• Use of the Navigation-based app template
• Use of various delegates — e.g. UITableViewDelegate, UITextFieldDelegate, UIPickerViewDelegate
• Use of various delegates and data sources — e.g. UITableViewDataSource, UIPickerViewDataSource
• Persistence of custom data types

Task

For this assignment you will be implementing a navigation-based app that allows a user to manage a list of tasks.

You are welcome to reuse your Task and TaskList classes from assignment 1. You may also change the implementation of these classes as you see fit for this assignment. There is no requirement that you preserve the same API that was detailed for the first assignment.

Behavior

When your app initially loads it should look similar to the image shown below. The user should be presented with a large table view with a task bar at the top. The task bar should contain 3 elements:

• A text title
• An add button
• An edit button

Task List View — Initial View

If the user presses the add button, the next view should slide in (right to left) that allows the user to edit the 4 properties of a task. There should be several UI elements on this page:

• The title bar (with a back navigation button and title)
• A text field for entering the task name
• A widget to select between completed and not completed. The actual widget you use it up to you (a UISwitch probably isn’t appropriate since the labels of the switch are “ON” and “OFF” — here I’ve used a segmented control)
• A widget to display the priority of the task and bring up a view to specify the priority (widget selection is up to you — here I’ve used a button)
• A widget to display the due date of the task and bring up a view to specify the due date (again, widget selection is up to you — here I’ve used another button)

Initial Edit Task Screen

In the screenshot below, the user has specified some text as the task text and has dismissed the keyboard (you’ll need to implement a UITextField delegate to dismiss the keyboard). The task text field should display the clear widget icon (the “X” at the right) once text has been typed into it.

Edit Task Screen — with Text

If the user selects the priority widget, another view should be brought in (again right to left) that allows the user to change the priority. This priority screen must contain the following widgets:

• A toolbar with an appropriate title
• A custom picker that allows the user to select a priority of Low, Medium or High
• A button that allows the user to complete the selection (in the implementation shown below, it’s the “Done” button in the toolbar above the picker

Priority Screen

If the user changes the priority, the widget representing the priority must be updated to reflect the current priority as shown below.

Edit Task Screen — Changed Priority

If the user selects the due date widget, another view should be brought in (again right to left) that allows the user to change the due date. This priority screen must contain the following widgets:

• A toolbar with an appropriate title
• A date picker (just date, no time) that allows the user to select a due date
• A button that allows the user to complete the selection (in the implementation shown below, it’s the “Done” button in the toolbar above the picker
• A button that allows the user to specify that there’s no due date associated with the given task (in the implementation shown below, this is the “No Due Date” button in the toolbar).

Due Date Screen

If the user specifies a due date, the widget representing the due date must be updated to reflect the current due date. This date should be formatted as shown below.

Edit Task Screen — Changed Due Date

Once the user enters his/her data and taps the arrow to go back to the main screen the item they edited should be added to the list. Take note that the table cell displays 2 lines of information:

• The task text
• The due date in the same format as the task editing view (or a reasonable message if no date is specified)

Task List View — with Added Task

Below we see the main screen after several tasks have been added to the list. Tasks should be color-coded based on the following rules:

• If the task is complete (regardless of due date) it should be colored gray
• If the task is past due (and not complete) it should be colored red
• If the task is not past due and not complete it should be colored normally

Task List View — with Multiple Tasks

Editing and Deleting Tasks

Above I’ve shown screenshots for creating a new task. However, in addition to listing the tasks on the main screen and adding tasks your app must also support editing and deleting tasks.

The editing flow should be pretty much the same as what’s shown above. When a task is selected, it should be shown in the editing view with all of it’s current values populated in the UI — meaning that the text should be in the text field, the widget represented completeness should be selected to the correct value, the priority should be the task’s specified priority and the date should reflect the current value for the task’s due date (or a message if not specified). Likewise when the priority and due date screens are shown for an existing task, they should be pre-set to that task’s values.

The app should also support the standard deletion mode as shown below. When the user presses Edit, this mode should be enabled.

Delete Mode

Persistence

Your application must persist the task list between runs of your application. There are many ways to do this, however the underlying implementation of how to do this is up to you.

Additional Ideas

The following items are provided as thoughts as to how you might extend or improve the project beyond the basic requirements. You are not required to implement any of these.

• Your task list from the first assignment should have many capabilities not leveraged in this sample implementation. You could choose to leverage them here to provide additional functionality (e.g. provide another toolbar/button to remove completed tasks)
• You could add sorting options (e.g. sort by priority, due date, etc.)
• Author a more complex table cell view that displayed additional info (e.g. render a check mark in the cell if the task is complete)

Submission

Like the previous assignment, you are required to submit a zip file of your project directory. Be sure to manually remove the build directory before zipping things up.

To submit the assignment, open up a terminal, navigate to your zip file then issue the command:

submit cs491i assignment3 Assignment3.zip

If developing on your own Mac, you’ll need to transfer the file into your GL account (via SCP), then SSH into GL and issue the submit command.

Final Project — Initial Presentation

Due Date

Slides must be submitted electronically by: Monday, October 11^th — 11:59pm
Presentations will occur in-class on: Tuesday, October 12^th and Thursday, October 14^th (as needed)

Background

You will be presenting an in-class overview of your application proposal. This presentation serves several purposes:

• As part of developing software, you are frequently required to develop and express your ideas for building out new components. This exercise is designed to give you some experience presenting your ideas to a group of of your peers.
• Several proposals had a good bit in common — this allows you to learn what other people are working on and gives you an opportunity to team up to work on the final project if you wish.
• This presentation will give you the opportunity to express areas of concern (i.e. not sure how I’d do something) and solicit feedback.
• It will allow others to ask (brief) questions of the presenter which may expose something that you haven’t thought about, etc.
• Provides a venue to start to think about and formalize aspects of your project that you will need to document as part of your final (formal) written proposal.

Slides

You should prepare some slides for use in your presentation. Specifically, I’m looking for the following…

• Title slide — name of app & group members
• Overview slide — a couple of bullets which summarize what your app does
• Mock-up slides — you should put together some basic mock-ups which show what you are envisioning in terms of a UI. You should have 2 or more mock-ups (but no more than 4).
• Thoughts slide — this is a catch-all for noting significant APIs, data sources, issues, questions, etc.
• Questions & Comments — signals the end of your presentation and opens things up for brief Q&A.

Presentation

You should aim for keeping your presentation around the 3 minute mark — if you grossly exceed this time limit, you’ll be cut off. You should practice your presentation ahead of time to work out kinks and make sure you have adequate time.

You should start your presentation by first introducing yourself (and team members), move onto your material and end with the opportunity for people to ask (very brief) questions.

The order of presenters will be determined in Thursday night’s class and emailed out after class.

Example

Below is an example presentation, again based off of the stocks app that was shown as an example in the initial written proposal.

Sample Slides

Mock-Up Advice

There are varying techniques for mocking-up or wire-framing user interfaces. I’ve tried to give you some different approaches in the provided example slides. Some of the more common approaches I’ve run into include…

• Sketching it by hand
• Using an image editing program to compose a UI from a bunch of images representing different widgets
• Designing using something presentation software (i.e. PowerPoint, Open Office Impress, Keynote, etc.)
• Building the actual GUI with canned data — this might be easier than you think, especially given the how powerful Interface Builder is)

I’ve added a wireframing section to the resources page with links to stencils in a variety of formats, printable wireframe templates and online wireframing tools. There’s also some links to some example wireframes.

Submission

Your slides must be submitted as a PDF document. Both Macs and Linux have supported exporting/printing to PDFs for some time. If writing your proposal in MS Windows there are a couple of free PDF generation options including: Save as PDF Plugin for MS Office or PDFCreator (a PDF print driver for MS Windows).

If you are working with a partner, only one of you should submit the slides.

Submit using the command:

submit cs491i initialpresentation slides.pdf

If authoring on your own machine, you’ll need to transfer the file into your GL account (via SCP) and then SSH into GL and issue the submit command.

Assignment 2 — The Game of Pig

Due Date

Wednesday, September 29^th — 11:59pm

Background

This project is designed to give you some hands on experience with…

• Using Xcode as a development environment
• Using Interface Builder to create iOS user interfaces
• Declaring and wiring up IBOutlets
• Declaring and wiring up IBActions
• Using various iOS widgets — UILabel, UIButton, UIImageView, UIProgressView, etc.
• Testing applications in the iPhone Simulator

Task

For this assignment you will be implementing the game of Pig for iOS. Your application must contain the following UI elements…

• Labels for Player #1 and Player #2
• Scores for both players
• Progress views for both players
• An image view that will display the die rolls
• A game status area that displays info about the current turn/score.
• A dual purpose new game/tap to continue button
• A roll button
• A hold button

Game of Pig

The rules for the game of Pig are rather simple. The following description (care of Wikipedia) defines the rules of the game…

Each turn, a player repeatedly rolls a die until either a 1 is rolled or the player holds and scores the sum of the rolls (i.e. the turn total). At any time during a player’s turn, the player is faced with two options:

• roll — If the player rolls a
  • 1: the player scores nothing and it becomes the next player’s turn.
  • 2–6: the number is added to the player’s turn total and the player’s turn continues.
• hold — The turn total is added to the player’s score and it becomes the next player’s turn.

The first player to score 100 or more points wins.

We’ll add one additional rule for this assignment — players must alternate turns going first between games.

Behavior

When your app initially loads it should look similar to the image shown below. Note that the states of the “Roll” and “Hold” buttons are disabled when the app starts up.

Initial App State

Once the “New Game” button has been pressed, it should be disabled and relabeled (since all subsequent touches will be to continue with the next player’s turn, I changed it to “Tap to Continue”). Additionally, the “Roll” button should be enabled and the user should be given a message to tap Roll to begin.

New Game Started

After the user presses the roll button, a random die face is selected and is shown to the user. If this number is a not a 1, then the “Hold” button should also be enabled so that the user may score his/her turn, as shown below. The running total of the current turn should be shown to the user under the die face.

Player 1 After Rolls

Once the user scores his/her turn the current turn should be added to the previous total (a zero in this case). This new total score should be shown as a number next to the user’s name. Additionally, the progress bar should be updated to show how far along the user is to reaching the goal of 100.

In addition to scoring the turn, you must enable the “Tap to Continue” button and disable the “Roll” and “Hold” buttons. The message should be updated to indicate the number of points scored and display whose turn it is.

Player 1 Holds

This allows the user to tap “Roll” and begin his/her turn. Below player 2 has tapped “Roll” once and rolled a 5. Note that the “Hold” button has been re-enabled once the user has rolled a die face (other than 1). Again, the running turn total is shown below the die face.

Player 2 Starts Turn

Here player 2 has held. Like when player 1 held, the turn total was scored, the “Roll” and “Hold” buttons have been disabled, the “Tap to Continue” button has been re-enabled, and we’re at a similar state to when player 1 started. Once again, the status has been updated to shown how many points were scored and whose turn it is.

Player 2 Holds

Here player 1 has tapped to unlocked, but hasn’t yet rolled — the message has been updated accordingly.

Player 1's Turn

If a player happens to roll a 1, then he/she should be notified that his/her turn is over and that it’s the other user’s turn. “Roll” and “Hold” buttons should be disabled, and the “Tap to Continue” button re-enabled as shown below.

Lost Turn

The following screenshot picks up many turns later with player 2 starting his/her turn.

Continued Gameplay

If a the score of the current turn plus the user’s existing score reach or exceed 100 points, then the user should be congratulated on his/her win in the status area under the die face. The “Roll” and “Hold” buttons should be disabled. The “Tap to Continue” button should be changed back to “New Game” and re-enabled.

Pressing “New Game” should return the game to the second screenshot, except that it should start with the other player’s turn.

Player 2 Wins

Images

Below are the images I used in my implementation — you may use these if you wish…

• 1.png
• 2.png
• 3.png
• 4.png
• 5.png
• 6.png

Additional Ideas

The following items are provided as thoughts as to how you might extend or improve the project beyond the basic requirements. You are not required to implement any of these.

• Try out alternate color combinations — just don’t make my eyes bleed
• Feel free to play with the layout and style of elements — just be sure that things are neatly aligned and that there is at least some justifiable method to your madness
• You may use your own or alternate images for the die faces

Getting Started

Create a new project by selecting File → New Project… then under iOS select View-based Application. Be sure that the Product is set to iPhone, then select Choose…

New View-Based App

Feel free to name the project as you see fit — though remember that things such as the app name and class names will get generated based on the name you give the overall project.

Submission

Like the previous assignment, you are required to submit a zip file of your project directory. Be sure to manually remove the build directory before zipping things up.

To submit the assignment, open up a terminal, navigate to your zip file then issue the command:

submit cs491i assignment2 Assignment2.zip

If developing on your own Mac, you’ll need to transfer the file into your GL account (via SCP), then SSH into GL and issue the submit command.