iOS 6 Application Development For Dummies (2013)

Part VI. The Part of Tens

Chapter 22. Ten Ways to Be a Happy Developer

In This Chapter

Finding out how not to paint yourself into a corner

Keeping it simple

Having fun

Avoiding “There’s no way to get there from here”

Think of all the things you know you’re supposed to do but don’t because you think they’ll never catch up with you. Not that many people probably enjoy balancing the checkbook or cleaning out gutters, and after all, not flossing won’t cause you problems until your teeth fall out years from now (right?).

But in iOS app development, those mañana gotchas will catch up with you early and often, so I want to tell you about what I’ve learned to pay attention to from the very start in app development, as well as give you a few tips and tricks that lead to happy and healthy users.

Keep Things Loosely Coupled

A loosely coupled system is one in which each of its components has little or no knowledge (or makes no use of any knowledge it may have) of other components. And because loose coupling refers to the degree of direct knowledge that one class has of another, it’s not about encapsulation or to one class’s knowledge of another class’s attributes or implementation, just knowledge of that other class itself.

I explain loose coupling more in Chapter 11.

Remember Memory

iOS does not store “changeable” memory (such as object data) on disk to free space and then read it back in later when needed. This means that running out of memory is easy, and you should use automatic reference counting (ARC) to make the most of the memory available to you. All you have to do is follow the rules:

Rule 1: Follow the naming conventions. This is really important. Good naming conventions help your code to be self-documenting. Sloppy, lazy, lethargic, sluggish, careless programmers who don’t take the time to follow the naming conventions will be dealt with harshly!

Rule 2: Do not send retain, release, or autorelease messages.

Rule 3: Do not store object pointers in C structures.

Rule 4: Inform the compiler about ownership when using Core Foundation–style objects.

Rule 5: Use the @autoreleasepool keyword to mark the start of an autorelease block.

If you follow the rules, all you have to worry about is the retain cycle. This cycle occurs when one object has a back pointer to the object that creates it, either directly or through a chain of other objects, each with a strong reference to the next leading back to the first. Use the weak lifetime qualifiers for objects and the weak property attribute.

But even if you do everything correctly, in a large application, you may simply run out of memory and need to implement the methods that UIKit provides to respond to low-memory conditions, as follows:

Override the viewDidUnload and didReceiveMemoryWarning methods in your custom UIViewController subclass.

Implement the applicationDidReceiveMemoryWarning: method of your application delegate.

Don’t Reinvent the Wheel

The iPhone and iPad are cutting-edge enough that opportunities to expand their capabilities are plentiful, and many of them are (relatively) easy to implement. You’re also working with a very mature framework. So if you think that something you want your app to do is going to be really difficult, check the framework; somewhere there you may find an easy way to do what you have in mind.

For example, I once needed to compute the distance between two points on a map. So I got out my trusty trig books, only to find out later that the distanceFromLocation: method did exactly what I needed.

Understand State Transitions

The UIApplication object provides the application-wide control and coordination for an iOS application. It is responsible for handling the initial routing of incoming user events (touches, for example) as well as dispatching action messages from control objects (such as buttons) to the appropriate target objects. The application object sends messages to its Application Delegate to allow you to respond, in an application-unique way, when your application is executing, to things such as application launch, low-memory warnings, and state transitions, such as moving into background and back into foreground.

You should implement the following UIAppDelegate methods in your application. Most of these methods are already basically implemented in the code provided by Apple’s templates, complete with comments explaining their purposes.

Mini Table Image

Do the Right Thing at the Right Time

When it comes to the view controller, you need to be aware of two methods, and you need to know what to do in each method.

The viewDidLoad message is sent to a view controller when the view has been loaded and initialized by the system. It is sent only when the view is created — and not, for example, when your app returns from background or when a view controller is returned to after another view controller has been “dismissed.”

The viewWillAppear: message, on the other hand, is sent whenever the view appears, including when the view reappears after another view controller is “dismissed.”

Do view initialization in viewDidLoad, but make sure that anything you do to refresh a view whenever it appears is done in viewWillAppear:.

Avoid Mistakes in Error Handling

Opportunities for errors abound; use common sense in figuring out which ones you should spend time on. For example, don’t panic over handling a missing bundle resource in your code. If you included it in your project, it’s supposed to be there; if it’s not, look for a bug in your program. If it’s really not there, the user has big problems, and you probably won’t be able to do anything to avert the oncoming catastrophe.

Having said that, here are two big potential pitfalls you do have to pay attention to:

Your app goes out to load something off the Internet, and (for a variety of reasons) the item isn’t there, or the app can’t get to it. You especially need to pay attention to Internet availability and what you’re going to do when the Internet isn’t available.

A geocoder may fail for any number of reasons. For example, the service may be down, a certain GPS coordinate may not have a street address, or the user may access the data before the geocoder has returned.

Use Storyboards

Storyboards are a great way to examine the flow of the application as a whole. In addition, they require you to use less code. They are one of my favorite parts of Xcode 4.3 and iOS 5.0 and above, and I use them in all my apps.

Remember the User

I’ve been singing this song since Chapter 1, and I’m still singing it now: Keep your app simple and easy to use. Don’t build long pages that take lots of scrolling to get through, and don’t create really deep hierarchies. Focus on what the user wants to accomplish, and be mindful of the device limitations, especially battery life. And don’t forget international roaming charges.

In other words, try to follow the Apple iOS Human Interface Guidelines, found with all the other documentation in the iOS Dev Center website at http://developer.apple.com/devcenter/ios in the iOS Developer Library section. Don’t even think about bending those rules until you really, really understand them.

Keep in Mind That the Software Isn’t Finished Until the Last User Is Dead

One thing that I can guarantee about app development is that nobody gets it right the first time. The design for RoadTrip (the example app in this book) evolved over time as I learned the capabilities and intricacies of the platform and the impact of my design changes. Object orientation makes extending your application (not to mention fixing bugs) easier, so pay attention to the principles.

Keep It Fun

When I started programming for the iPhone and iPad, it was the most fun I’d had in years. Keep things in perspective: Except for a few tedious tasks (such as provisioning and getting your application into the Apple Store), expect that developing iOS apps will be fun for you, too. So don’t take it too seriously.

Especially remember the fun part at 4 a.m., when you’ve spent the last five hours looking for a bug.