Final Project — Background & Initial Proposal

Due Date

Tuesday, October 6th — 11:59pm


A significant portion of your course grade (40%) is based on your final project. However, your overall final project grade will be based not only on your final application (which itself is graded on originality as well as the criteria for the week-long projects), but also on the quality of other deliverables.

The final grading breakdown…

  • Written Initial Proposal (5%)
  • Oral Proposal Presentation (5%)
  • Written Final Proposal (15%)
  • Oral Final Presentation (15%)
  • Actual Application (60%)


For the final project, you may choose to work by yourself of with a partner.

Your app should strive to be interesting, novel, and unique. With over 85,000 apps on the store this may seem like a daunting task, especially if someone has already implemented your idea. However, if there already exists an app for your idea, think about how you can differentiate your app to make it stand out. Or, think about how you can do do something better and go with it.

Any type of application is acceptable, as long as it follows Apple’s general guidelines and would be rated less than Apple’s 17+ category. Apple’s current 17+ description is listed below for reference — if you have any questions or concerns that this might be an issue for your app, come talk to me.

You must be at least 17 years old to purchase this application.
Applications in this category may also contain frequent and intensive offensive language; frequent intense cartoon, fantasy or realistic violence; and frequent and intense mature, horror, and suggestive themes; plus sexual content, nudity, alcohol, tobacco, and drugs which may not be suitable for children under the age of 17.

Your app could be a game, a musical related-app, a social or location aware app, a business app, reference app, etc. Your app must include more than one view and must persist some form of data (preferences, game state, data, etc.). It is recommended that you consider including some form of animation and sounds into your app. You are encouraged to explore areas of the SDK and APIs beyond what is discussed in class. Part of being a professional developer is the ability to read documentation, research APIs and write code without instruction.

Project Scope

It is easy to become excited about a project and bite off more than you can chew. Some things to keep in mind…

  • You will have until the end of the semester to complete your project — about 2 1/2 months
  • The weekly projects should taper off around mid-November leaving the last month or so of the semester to dedicate to your final project
  • Be sure to think about your other coursework and commitments when describing what you plan to hand in at the end of the semester

If you have an idea for a larger project think about how you might be able to segment it into discrete parts that are doable within the semester. I’d much rather see a smaller app (or portions of a lager app) that are polished and done well versus a larger unfinished/unpolished/buggy app.

Initial Written Proposal

Your initial written proposal and should contain the following elements…

  • A working title that sums up your app
  • Listing of team members — name and myUMBC username
  • A brief (a paragraph or two) description of what your app will do


Below is an example (based on Apple’s stock app) that shows the level of detail I’m looking for at this point…

Initial Proposal

Initial Proposal


Your initial project proposal should 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 proposal.

Submit using the command:

submit cs491i initialproposal proposal.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.


On-Device Development

On-Device Development


In order to install and run your own apps on your iPhone or iPod touch a couple of things need to happen — namely both you and your device must be added to the university program.

In order for you to sign applications you must obtain a digital certificate. This process is roughly as follows…

  1. You must be sent an invite from the University Program admin (your instructor)
  2. Once you receive your invite, you must generate a certificate signing request though the Keychain Access app in OS X
  3. Once generated, you must submit this certificate request to the program portal for approval by the University Program admin (your instructor)
  4. Once approved, you must download and install your signing certificate

In order to install your signed app to an iPhone or iPod touch, it must be added to a provisioning profile which identifies who can publish to what devices. This process is roughly as follows…

  1. Your device’s Unique Device Identifier (UDID) must be added to the course’s provisioning profile
  2. Your approved developer certificate must be added to the course’s provisioning profile
  3. Once your certificate and device have been added to the provisioning profile, you may download and install the it into Xcode

Once you’ve installed your certificate and provisioning profile, you can build and publish applications to your iPhone or iPod touch.

Requesting an Invite

If you would like to do on-device development on your iPhone or iPod touch, you must send me an email with the following information:

  • First Name
  • Last Name
  • Email address — see Email Address Considerations below
  • myUMBC username
  • The UDID of the device you wish to use — see Finding your Unique Device Identifier (UDID) below

When I get your request I’ll send you an invite. Once you get this invite, you’ll be able to log into the portal and submit your certificate signing request.

Once you submit your certificate signing request to the portal I’ll be automatically notified. When I get this notification, I’ll add your device to the list and approve your certificate request. You will automatically get an email once the approval happens. You will then be able to log back into the portal and download your certificate and the provisioning profile.

Email Address Considerations

I’d strongly recommend that you use your UMBC email address and not a personal email address. If you think that you’ll ever want to sign up as a regular developer and submit apps to the store, I’d recommend that you keep that separate and re-enroll to the Apple Developer Connection with a UMBC specific identity.

Finding your Unique Device Identifier (UDID)

To find out your device’s UDID, simply connect your device to your Mac and then open Xcode (if you connect while Xcode is open, it may not see the device). In Xcode, select “Organizer” from the “Window” menu option. Once the window opens, select your device under the DEVICES category on the sidebar. The 40 character string in the Identifier field is your device’s UDID. I strongly recommend that you copy and paste this into your email.

Locating Your UDID

Locating Your UDID

A Note About Keys

If you are going to do on-device development in the labs, you must export your private key and certificate and save it to your AFS home directory before logging out and re-import it when logging back in. If you do not save it and log off your private key used for signing will be lost and cannot be recovered!

Whether you are working in the labs or not, I strongly recommend that you export your keys and certificate and save them to some other media (such as within your home directory on AFS or a thumb drive).


The development provisioning profile is currently valid through December 24th 2009.

Unfortunately, due to legal issues it appears that we will be unable to issue distribution profiles, so once the development provisioning profile expires your apps will cease to launch. If you wish to distribute an app beyond the scope and duration of this class, you’ll need to register as a paid developer.

More Information

For more information see the following:

ENG 005 Classroom Schedule

A couple of you have asked about the scheduling of classes in ENG 005 since the sign outside the room was apparently missing or incorrect. The response I received from the Division of Information Technology stated that the classes may vary week to week. However, they were able to provide the days/times that courses are scheduled to be in that room…

  • Monday/Wednesday 10:00am – 11:50am — ART 488
  • Tuesday/Thursday 9:00am – 10:50am — ART 384
  • Tuesday/Thursday 4:00pm – 5:50pm — ART 484/649J

I’ve also been told that the schedule posted outside ENG 005 has been corrected.

Lecture 9 — Navigation-Based and Tab Bar Views

Navigation-Based and Tab Bar Views

Navigation-Based and Tab Bar Views

Assignment 3

Due Date

Thursday, October 1st — 11:59pm


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

  • Using Xcode as a development environment
  • Using Interface Builder to create iPhone user interfaces
  • Declaring and wiring outlets and actions
  • Testing applications in the iPhone Simulator
  • Exposure to additional user interface elements
  • Using delegates and dataSources for a variety of purposes


For this assignment you will be writing a converter app for the iPhone. Your application must contain the following elements…

  • A toolbar containing a centered segmented control that allows the user to choose between 2 or more different categories
  • A picker wheel that allows the user to choose between units of conversion (a “from” and a “to”)
  • A customized set of buttons that allow the user to specify and edit the “from” value. This set of buttons should include:
    • The numbers 0-9
    • A decimal point
    • A delete (backspace)
  • A label that is used to display the “from” and “to” values


When your app initially loads it should look similar to the image shown below:

Initial State

Initial State

When a user presses a button, the number should instantly appear in the “from” label under the left wheel (just like a calculator echoes the numbers as you type them). Additionally, the conversions should happen in real-time as the user types. In the example below we see that the number 1 is also immediately displayed as the “to” value under the right wheel. In this case both values are the same, as the “from” and “to” units are the same.

After Pressing 1

After Pressing 1

Here the user presses the number 2 which is immediately echoed to the right side of the “form” label to form the number 12. Again, the conversions happen in real-time as soon as the user presses the button. Since both wheels are still the same, we still have 12 on both sides.

After Pressing 2

After Pressing 2

If the user spins and releases one of the wheels, immediately upon releasing the wheel, the “to” value should be immediately recalculated and displayed. Here we see that as soon as the left wheel was changed to Kilobytes, the conversion to Bytes immediately happened and the “to” value was updated to the correct value.

After Sliding Left Wheel to Kilobyte

After Sliding Left Wheel to Kilobyte

A more interesting example of calculations happening in real-time is shown below. As the user presses “.” then “5”, the “to” values are immediately computed and updated.

After Pressing .5

After Pressing .5

If the user presses the delete key the values are immediately removed from the right side of the “from” label — one removal for each delete press. Just like when adding digits, when we remove digits from the “from” value, we should perform real-time conversions against the changing value and update the “to” value accordingly.

After Pressing Delete Twice

After Pressing Delete Twice

The following screen simply shows that the “to” value need not be a whole number as shown in the previous screen shots.

After Sliding Right Wheel to Megabyte

After Sliding Right Wheel to Megabyte

If the user selects a different segment in the control at the top of the app, the wheels of the picker should switch over to the appropriate category and contain the corresponding labels. The “from” value should be preserved and conversion should happen immediately upon selecting the new segment.

After Switching to Temperature

After Switching to Temperature

In the screen shot below, the value has been deleted out and a new value entered. Again, conversions happen as the user manipulates the “from” value.

After Deleting and Re-Entering a New Value

After Deleting and Re-Entering a New Value

Below the left wheel has been spun, conversions have automatically happened between the new “from” and “to” units.

After Sliding Left Wheel to Fahrenheit

After Sliding Left Wheel to Fahrenheit

A spin of the right wheel. The “to” value is updated immediately after releasing the wheel.

After Sliding Right Wheel to Kelvin

After Sliding Right Wheel to Kelvin

Error Handling

Since we’re providing the input by the way of our own buttons, we know exactly what data can be entered. However, there’s still some error checking to be done. Your app should not allow the user to press the “.” button more than once and end up with a string like “”.

Conversion Requirements

At a minimum you need to provide options for converting between Data and Temperature.

For Data, you should at a minimum support converting between Byte, Kilobyte, Megabyte and Gigabytes. Yes, I know that my calculations using 210 are now technically called Kibibytes and the like — call me old fashioned. Feel free to follow in my footsteps, or choose to implement it as 103, or use the [KMG]ibibytes notation — your choice.

For Temperature, you should at a minimum support converting between Celsius, Fahrenheit and Kelvin. Wikipedia’s Temperature Conversion Formulas page provides the formulas for these conversions.

Feel free to add additional categories and units if you wish.


The first thing I’d probably do is to print out one of the images of the UI from this assignment and start to think about and identify…

  • Where do you need outlets?
  • Where do you not need outlets?
  • What instance variables you will need?
  • What action methods do you need?
  • Which of the action methods forms are you using (and thus what’s getting passed in)?
  • What interactions call which action methods?
  • Will all of the interactions behave as described?

Aside from the documentation for the relevant UI, delegate and dataSource classes, I also found NSDecimalNumber useful in my implementation. You will also want to take a good look at the UIPickerView docs to figure out how to reload the wheel values when switching between categories.

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
  • Add images to the app if you think it will improve the look and feel of the application
  • I’m open to using alternate input/display mechanisms — just send me an email to tell me what you’re thinking and I’ll let you know if it is acceptable


Your projects will be graded on the following criteria:

  • 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


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

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.

Lecture 8 — Table Views

Table Views

Table Views

Lecture 7 — Widget Tour

Widget Tour

Widget Tour