Create an app “home” or “launch” view

This document can be used by new iOS programmers to create a “home” or “launch” view for an app that has a number of modules.

This document was updated most recently in October 2011.

.

Is the topic coverage in this document authoritative; a best practice? No. Its goal is to enable a new iOS programmer – the typical DPS913 / APD601 student – to build on the concepts they have learned, and their coding experience so far. Production-quality apps (like many on the App Store) will typically use customized approaches, or a library component (e.g. the Three20 library, which includes the TTLauncherView).

What about a tab bar app style? Well, that is an option. However, the tab bar (typically) is at the bottom of all views, and the functions/modules provided by each tab are reasonably closely related to each other. Your app may not be a good fit for a tab bar app style. If not, you can use the approach that’s discussed in this document.

.

Foundational concepts

At this point in time, the new iOS programmer has created a number of fairly simple apps. Some of the apps had only one view, while others (especially navigation-based apps) had a number of views.

By now, you’ve learned that the view controller – consisting of its .h, .m, and .xib parts –  is the building block for an app. You’ve also learned design and coding techniques that enable a view controller to be portable, and used elsewhere. We’ll take advantage of that in this document.

.

Getting started

We recommend that you start by creating a project that uses the Window-based Application template, and uses Core Data for storage. In this kind of app, the Core Data stack is initialized in the app delegate, and is ready to use by the app’s modules.

How do you use the Core Data stack in each module? Simply pass on the managed object context to the (root) view controller in each module.

.

Designing the home/launch view

Visually, a home/launch view will have a number of buttons or image icons, which will load/launch – conceptually – an app module. A module is actually a logical grouping of view controllers, whether there’s one or many in that group.

Each button/icon will have a handler method in the home/launch view controller. When a specific button/icon is tapped, the idea is to present a module’s initial view controller modally. That is, each will slide up from the bottom. As a modal view controller, the user will work with it, and then end their work with it by exiting the view somehow.

We ensure that the view includes a way to exit, so that the user can return to the app’s home/launch view. Often that’s provided by a button in the upper-left area of the screen; on the left side of a navigation bar. Often, but not always.

What if a module’s initial view controller is part of a nav-based module? Well, the typical initial (root) view controller in a nav-based app does not have a button on the left side of its navigation bar. So, we’re not violating any design recommendations by following these guidelines.

.

Presenting a nav-based module

Weeks ago, the DPS913/APD601 student learned how to create a nav-based app, by starting with a Window-based Application template. We follow that general approach here, with one exception.

We will be creating a navigation controller (UINavigationController) in code. (Before, you added it as a nib document object, and connected it to an outlet in the view controller.)

By now, you are very familiar with the sequence for presenting a new view controller:

  1. Create an instance of the next view controller
  2. Configure it
  3. Present it

.

Here, we will modify the sequence:

  1. Create an instance of the next view controller
  2. Configure it
  3. Create an instance of a navigation controller, and add the above controller as its root
  4. Present the navigation controller

.

Remember… if your module requires the Core Data stack, then pass on the managed object context in “2. Configure it” above.

Also, in the “2. Configure it” step, you will add a “go back” button to the left side of the navigation bar. You’ll see that in the code example.

Note: Apple recommends that the delegate pattern – as seen in the “…To Do Add” example app – be used to dismiss a modal view controller. Agreed. However, the technique presented here is easy to understand and implement. After success, you can then modify the configuration to conform to the recommendation.

.

Presenting a standard module

The pattern for presenting a standard module, as a view controller, is similar:

  1. Create an instance of the next view controller
  2. Configure it
  3. Present it

.

As above… if your module requires the Core Data stack, then pass on the managed object context in “2. Configure it” above.

What’s different?

A standard view controller does not have a navigation bar. In the Launcher example app, your professor decided that it needed one, to preserve the visual style of the app, and enable the user to “go back” to the home screen, using the same user interface as the nav-based module.

Therefore, in the Launcher example app, you will see a coding pattern that adds a navigation bar and button to a standard view controller. It’s done in code, in viewDidLoad.

.


.

.

.

  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: