CCP – common coding pattern – nav bar buttons

In this post, you will learn common coding patterns (CCP) for placing buttons on a navigation bar in a nav-based app.

.

This post was most recently updated in October 2011. The target audience of this post will be those who are entry- or mid-level iOS programmers.

.

What is the problem that needs to be solved?

In some nav-based apps, we need to support editing operations.

The best practice solution is to add an “edit” button to the navigation bar. Where? On the right.

If that seems obvious, then consider what happens when you create a new project in Xcode 4, and use the Navigation-based Application template, and Core Data. You get an app delegate, and a root (table) view controller. However, notice that the root view controller’s navigation bar has two buttons – “edit” and “add”. And, the “edit” button is on the left.

A general design rule, for a table view controller that’s part of a navigation stack, is that the left side of the navigation bar is reserved for the “back” button. Of course, this applies to the default state (i.e. the initial presentation) of the view controller.

Therefore, the template violates this rule. You must not design your view controllers to mimic this design. The author suspects that the reason was to support an easy-to-understand template, with one-tap access to “edit” and “add” functions.

.

The solution – a common coding pattern for nav bar buttons

The solution in this document will work for table view controllers, and for standard view controllers (which typically display details about a tapped/selected row).

The table below shows the solution for a nav-based app that has three levels of navigation:

  1. The root level, identified as “level 1”, appears when the app launches
  2. When a row is tapped/selected, the next level, identified as “level 2”, appears
  3. Tapping a “level 2” row will present a standard (i.e. detail) view controller

.

You will notice that you could, if you wish, insert another level of navigation. The rules will remain the same.

At each level that displays a table view controller, the design features the ability to add new items to that level. If that doesn’t work for your app (e.g. maybe a web service response is providing the data for the table view), then you simply modify the pattern to suit your needs:

  • If you do not permit editing or adding, the “edit” button is not needed
  • If you permit editing, but not adding, then it means that you will support delete and/or table cell move operations; in this situation, the “edit” button is replaced with a “done” button

.

Navigation Bar Items
Left Title Area Right
Default/initial view (level 1 list title) Edit
Tap the Edit button + (level 1 list title) Done
Tap the + button (which presents an add/edit view controller for level 1 items) Cancel Add (level 1 item) Save
Tap a row in the (level 1) list, which navigates to a table view controller (back) (level 2 list title) Edit
Tap the Edit button + (level 2 list title) Done
Tap the + button (which presents an add/edit view controller for level 2 items) Cancel Add (level 2 item) Save
Tap a row on the (level 2) list, which navigates to a standard (i.e. detail) view controller (back) (level 2 item title) Edit
Tap the Edit button + (level 2 item title) Done
Tap the + button (which presents the same add/edit view controller for level 2 items) Cancel Edit (level 2 item) Save

.

Program code examples

(more to come)

.


.

.

.

  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: