10 Ways to Be a Happy iOS App Developer
In iOS app development, those problems you put off until tomorrow will catch up with you early and often, so here are a few things to pay attention to from the very start in app development, as well as 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 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.
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.
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.
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 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.
Understand state transitions
The UIApplication object provides the application-wide control and coordination for an iOS app. It is responsible for handling the initial routing of incoming user events as well as dispatching action messages from control objects to the appropriate target objects.
The app object sends messages to its Application Delegate to allow you to respond, in an app-unique way, when your app is executing, to things such as app launch, low-memory warnings, and state transitions, such as moving into background and back into foreground.
Implement the following UIApplicationDelegate methods in your app.
|Method||What You Do with It|
|application:didFinishLaunchingWithOptions:||In this method, do what you need to do to initialize your app
after it’s launched.
|applicationWillResignActive:||This message is sent when the app is about to move from the
active to inactive state. Use this method to do things such as
pause ongoing tasks and anything based on a timer.
|applicationDidEnterBackground:||This message is sent when your app is going to be entering
background. At this point, you need to assume that your app may
eventually be terminated without warning, so save user data,
invalidate timers, and store enough app state information.
|applicationWillEnterForeground:||This message is sent when your app has been rescued from
background. In this method, reverse what you did in applicationWillEnterBackground:.
|applicationDidBecomeActive:||Your app is now active. You should reverse whatever you did in
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
Here are two big potential pitfalls you do have to pay attention to:
Your app goes out to load something off the Internet, and 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. 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 app as a whole. In addition, they require you to use less code.
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.
In other words, try to follow the Apple iOS Human Interface Guidelines, found with all the other documentation in the iOS Dev Center website in the iOS Developer Library section.
Keep in mind that the software isn’t finished until the last user is dead
One thing that is guaranteed about app development is that nobody gets it right the first time. Your designs will evolve over time as you learn the capabilities and intricacies of the platform and the impact of your design changes. Object orientation makes extending your app easier, so pay attention to the principles.
Keep it fun
Keep things in perspective: Except for a few tedious tasks, 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.