Ten Ways to Be a Happy Developer
In iOS app development, those little things you knew you were supposed to do, but didn’t, will catch up with you early and often, so learn to pay attention to from the very start in app development. Here are 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.
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. 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.
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.
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.
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.
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.
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 the best parts of Xcode 4.3 and iOS 5.0 and above, and you should use them in all your apps.
Remember the user
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.
The software isn’t finished until the last user is dead
Nobody gets it right the first time. The design evolves over time as you learn the capabilities and intricacies of the platform and the impact of your design changes. Object orientation makes extending your application (not to mention fixing bugs) easier, so pay attention to the principles.
Keep it fun
When you start programming for the iPhone and iPad, it might be the most fun you’ve 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. So don’t take it too seriously.