DPS913 APD601 Lab 5

In this Lab 5, you build a multi-level navigation-based app. You will work with three related entities, and you will support the addition of new managed objects through standard view controllers. It is due on Monday, February 20.

.

DPS913 APD601 Lab 5 – due Mon Feb 20

Assigned: During Week 5

Due date: Monday, February 20, 2012, at 11:00pm ET

Grade value: 4% of your final course grade

Grading method: The following will be checked:

  • Completeness and adherence to iOS app coding principles
  • Correct interactive operation of the app’s logic

.

Objective(s)

Work with a navigation-based style application that uses Core Data.

Work with related entities.

Support the creation of new objects through a standard view controller.

Learn and apply new coding patterns.

.

Concepts that you will learn

  • Navigation-based app style that uses the Core Data stack
  • Patterns for creating/writing re-usable view controllers
  • App design fundamentals

.

Introduction to the problem that you will solve

Your app will display information about the world-famous Westminster Kennel Club (WKC) Dog Show.

The 2012 WKC Dog Show is on February 13 and 14, in Madison Square Garden, in New York City. See its web site for more information.

Your app will display information about dogs, breeds of dogs, and groups of breeds. It is a four-level navigation-based app, which starts with Groups (a list), then Breeds (a list), then Dogs (a list), then details about a specific Dog.

View this video to see how the app works.

In addition, at each list level, your app will enable the display of more detail about a selected row. Finally, at each list level, your app will enable the entry of a new entity object.

The following images are examples of its user interface (yours may look different). These three images show the top-level Group list, as well as the Group add view, and the Group detail viewer:

  

When a user taps a selected Group on the top-level list, information about the Breeds in the Group becomes available. These three images show the Breed list, the Breed add view, and the Breed details viewer:

  

When a user taps a selected Breed, information about the Dogs in the Breed becomes available. These three images show the Dog list, the Dog add view, and the Dog details viewer:

  

.

Specifications

Download the “Lab_5_files.zip” package from the iOS Programming Examples web site. This is a working app, and you will add to it.

You may also want to download the “Templates_as_of_Feb_12…” zip package, which contains updated source code templates for view controllers.

As you will see, the working app has the following components:

  • App delegate
  • Model class
  • Core Data object model
  • Root view controller to display a Group list
  • Standard view controller to add a Group
  • Standard view controller to display details about a group

.

View this video for information on programming the app.

Then, run the app to see how it works for you. Add a few Groups (e.g. Herding, Toy, Sporting, etc.). Become familiar with the problem/application domain, by studying the WKC Dog Show web site.

Study the existing code base to learn how it works.

Then, add view controllers for the next level of navigation, Breeds. Follow the naming pattern that exists for the Group level:

  • BreedList – table view controller, can use the Template_List template
  • BreedEdit – standard view controller, can use the Template_Add_Edit template
  • BreedView – standard view controller, can use the Template_Standard template

.

To support the Breed level of navigation, you will add a fetched results controller to the model class.

Then, create the user interface, and write the code, to make the Breed controllers work properly.

Next, add view controllers for the last level of navigation, Dogs. Follow the naming patterns.

  • DogList – table view, Template_List
  • DogEdit – standard view, Template_Add_Edit
  • DogView – standard view, Template_Standard

.

To support the Dog level of navigation, you will add a fetched results controller to the model class.

Then, create the user interface, and write the code, to make the Dog controllers work properly.

.

Core Data object model

As noted above, the app includes a Core Data object model. You do not have to change it, because it works as delivered. Here’s what it looks like:

.

There are four simple entities.

The Group entity has a groupName attribute, and a to-many relationship to Breed. (A Group can have many Breeds. A Breed is in only one Group.)

The Breed entity has a breedName attribute (and another that we’ll use later), and a to-many relationship to Dog. (A Breed can have many Dogs. A Dog is in only one Breed.)

The Dog entity has a dogName attribute, and some others.

The last entity is Award, which we will not be using in this Lab 5. (We will use it later.) You will notice that it has bidirectional to-one relationships with the other entities.

All attributes are non-optional (i.e. required; their “Optional” check box was un-checked/cleared.) All relationships are optional.

.

Two kinds of navigation (to the next level)

You will notice from the screen captures (above) that the Group and Breed list views show a different kind of navigation accessory on the right side of the table cell. This accessory – a right-pointing arrowhead inside of a blue circle – is known as a detail disclosure accessory.

If a user taps on top of the accessory, it means that the user wants to view detailed information about that row’s item. The Cocoa runtime will call the tableView:accessoryButtonTappedForRowInIndexPath: method. It will then typically display a standard view, which shows the detailed information.

Alternatively, if the user taps elsewhere on the row, it means that the user wants to navigate to the next level. (In this use case, it has the same meaning as the standard disclosure accessory, and the Cocoa runtime will call the tableView:didSelectRowInIndexPath: method.)

The detail disclosure accessory is often used in table views that are in the midst of a navigation stack.

.

Add/edit coding pattern

When you study the existing Group controllers, you will see the recommended and best practice way of presenting an “add/edit” view controller. An add/edit controller has a number of features, as described next.

The add/edit controller is presented modally (in our case, by the Group list controller), in response to the user tapping an “add” ( + ) button on the right side of the navigation bar. Before presenting the add/edit controller, it is placed inside a navigation controller, so that the add/edit controller has a navigation bar, on which to place “cancel” and “save” buttons.

The presenting controller will be the delegate of the add/edit controller; see the next paragraph.

An add/edit controller includes a definition of a “protocol”. The protocol will define (in this typical case) one method, which is called by the add/edit controller in a “cancel” or “save” operation. When the method is called during the “save” button handler, and a fully-configured new object is passed as an argument.

The presenting controller must conform to this protocol, and implement the method. The method implementation includes a statement that saves the new object (if one is passed in), and another that dismisses the modally-presented add/edit controller.

Notice the name of the protocol. The naming convention / format is somewhat important , if only to enable you to understand the concept, and then reliably implement it elsewhere. You should use a name similar to “Edit____Delegate”. The “____” (blanks) gets replaced by the name of the entity class name (or other business/model class name).

While this pattern has been embedded in the “Template…” source code templates, here is a summary of how you should implement this pattern:

In the add/edit controller

  1. Declare and define a protocol, in the .h interface (and follow the naming convention)
  2. In the .m implementation, in the viewDidLoad: method, create “cancel” and “save” buttons
  3. Continue by adding methods to handle these buttons; the “cancel” handler simply calls the delegate method and passes a “nil” object, while the “save” handler creates a new object, configures it with data from the user interface, and then calls the delegate method, passing it the new object

In the presenter controller

  1. In the .h interface, import the add/edit controller header
  2. Conform to the add/edit protocol
  3. In the .m implementation, in the viewDidLoad: method, create an “add” button
  4. Continue by implementing the button handler method; it will create, configure, and present the add/edit controller modally
  5. Implement the protocol method, which saves a new object (if present), and dismisses the modally-presented add/edit controller

..

Send me your work

Follow these instructions to send me your work:

  1. Make sure your project works correctly
  2. Locate your WKC 2012 project folder in Finder
  3. Right-click the folder, and choose Compress “WKC 2012”, which creates a zip file
  4. Visit this page: http://matrix.senecac.on.ca/~peter.mcintyre/dps913/, and upload WKC 2012

.


.

.

.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: