Learning iPhone Programming (2010)
Chapter 14. Going Further
We’ve managed to cover a lot of ground over the preceding 13 chapters, but there is still a lot more ground to go. While you should by now be confidently building solid applications for the iPhone and iPod touch, there is still a lot to learn.
Cocoa and Objective-C
The Objective-C language has a number of powerful features, and the Cocoa framework that is layered on top of the language is extensive. I’ve obviously not had the time or space in this book to cover either one in the depth it really deserves.
If you intend to continue developing for the iPhone, you should consider reading further on Objective-C, especially if you’re having difficulties with memory management or the Model-View-Controller pattern around which most iPhone application development revolves.
Apple provides some excellent tutorial material on its developer website and that should certainly be your first port of call. I also recommend Programming in Objective-C by Stephen G. Kochan (Addison-Wesley) and Cocoa and Objective-C: Up and Running by Scott Stevenson (O’Reilly), for a more detailed look at the language. See also Cocoa Design Patterns by Erik M. Buck and Donald A. Yacktman (Addison-Wesley) for a detailed look at design patterns in Cocoa.
The iPhone SDK
Predictably, I’ve focused on the parts of Cocoa and Objective-C that will be most helpful in allowing you to write your own applications for the iPhone. But even there I’ve left out a lot in an attempt to simplify and get you started quickly. A more in-depth look at the iPhone SDK is available in iPhone SDK Application Development, First Edition by Jonathan Zdziarski (O’Reilly).
A good cookbook to help you solve specific problems is The iPhone Developer’s Cookbook: Building Applications with the iPhone SDK by Erica Sadun (Addison-Wesley). Erica’s book consists of an excellent collection of recipes that solve the vexing question: “How do I make my application do X, Y, or Z?” She provides some solid example code that you can lift off the page and use yourself, often without any modification, in your own applications.
This book looked at how to build native applications. As I mentioned in Chapter 1, there is an alternative: you can build your application as a web application, taking it entirely online and doing away with the native SDK altogether. However, many native iPhone applications sit on a blurry line between the native and web worlds, wrapping custom content in a UIWebView inside the application, with much of the backend processing done “in the cloud.” For instance, I know of several developers who are using Google App Engine to power their applications and store user data, with little or no number crunching actually going on in the iPhone device. Knowing how to build web applications is a useful skill, even for a hardened Objective-C programmer building a native application.
If you’re thinking about using Google App Engine as a scalable backend for your iPhone application, you should look at Using Google App Engine by Charles Severance and Programming Google App Engine by Dan Sanderson (both published by O’Reilly).
One of the most important additions to the iPhone SDK, at least from the perspective of the developer community, was Core Data. It is a powerful and efficient framework for data management and persistence, and while it was new to the iPhone at the time it was added, it had been available to developers on the Mac since the release of Mac OS X 10.4 (Tiger).
Core Data allows you to easily define your application’s data model, creating a managed object model that allows you to specify an abstract definition of your model objects. In a similar fashion to how Interface Builder takes much of the heavy lifting out of building complicated user interfaces (the view), Core Data takes the heavy lifting out of building the model.
We didn’t even touch on Core Data in this book; if you’re interested in this framework, I recommend that you look at Core Data: Apple’s API for Persisting Data on Mac OS X by Marcus S. Zarra (Pragmatic Programmers). I also recommend that you look at Core Data for iPhone: Building Data-Driven Applications for the iPhone and iPod Touch by Tim Isted (Addison-Wesley Professional).
The Apple Push Notification Service (APNS) APNSallows applications to notify their users of remote events. If the user has turned on Notifications from the Settings application, her device will maintain a persistent IP connection to the APNS. Only one connection is maintained and all third-party notifications are forwarded (by providers) through Apple’s own servers (see Figure 14-1).
Figure 14-1. A push notification from a provider to a client application
When a device receives a notification for an application and that application isn’t running, it notifies the user through an alert message or a sound, or by adding a numbered badge to the application. The APNS does not provide any feedback as to whether the message was successfully delivered to the user.
Apple argues, “Push notifications serve the same purpose that a background application would on a desktop computer” and that running applications in the background really isn’t necessary on a mobile platform outside of core services that the platform provides, such as phone calls and push email. It is not possible to run your own third-party applications in the background on the iPhone or iPod touch. Apple says, “...on a device such as the iPhone, background applications are, for performance and security reasons, prohibited. Only one application may be executing at a time.”
However, while Apple has provided detailed documentation regarding how to implement push notifications on the client (device) side, it provides only a high-level overview for implementing the provider (server) side.
Details of the APNS are given in the Apple Push Notification Service Programming Guide available via the iPhone Dev Center.
Unfortunately, there is also little in the way of third-party documentation at the time of this writing as to how to communicate with the APNS to send the messages that are then pushed to the phone. However, some off-the-shelf third-party implementations are available. If you intend to implement push notifications in your application, these are probably the best places to start:
Perl wrapper code implementation that acts as a provider allowing you to send push notifications using the APNS. See http://github.com/typester/anyevent-apns-perl and http://search.cpan.org/~typester/AnyEvent-APNS/ for more details.
Python wrapper code for the APNS. See http://code.google.com/p/apns-python-wrapper/ and http://pypi.python.org/pypi/APNSWrapper/ for more details.
A set of PHP scripts which you must run as services and which allow you to send push notifications using the APNS. See http://code.google.com/p/php-apns/ for more details.
A daemon written in Ruby that acts as a provider to the APNS. The daemon maintains a persistent connection to the APNS for best performance. See http://code.google.com/p/ruby-apns-daemon/ for more details.
javaapns and apns-provider
Two independent Java implementations of the APNS. See http://code.google.com/p/javapns/ and http://code.google.com/p/apns-provider/ for more details.
The Store Kit Framework is an in-application payment engine for paid applications allowing you to request payment from your users (e.g., for accessing additional content).
You can also simplify your development by creating a single version of your application that uses In-App Purchase to unlock additional functionality, eliminating the need to create two versions of your application: a paid “pro” version and a free “lite” version. You can distribute your application for free, and then ask users to upgrade using In-App Purchase.
Only digital items may be sold using In-App Purchase, not physical goods or services, and these digital goods must be delivered to the application from which they were purchased (and in addition be available on all devices that the user may own). The framework leverages the App Store to collect payment, even sending the user the familiar App Store receipt email she would normally receive after purchasing.
Details of the Store Kit Framework and the In-App Purchase service are given in the Apple Store Kit Programming Guide available via the iPhone Dev Center.
Built on top of the OpenGL libraries, Core Animation was designed from the ground up to allow developers to build lightweight but graphically rich UIs, and is the framework that underlies both Apple’s Front Row application and the now almost ubiquitous Cover Flow effects.
If you want to learn more about the Core Animation framework, I recommend Core Animation for Mac OS X and the iPhone: Creating Compelling Dynamic User Interfaces by Bill Dudley (Pragmatic Programmers) and Core Animation by Marcus Zarra and Matt Long (Addison-Wesley).
Despite the name, the Game Kit framework is not just for games, as it offers two important technologies to developers: peer-to-peer networking using Bonjour over Bluetooth, and in-application voice chat. Interestingly, the voice chat features included in Game Kit work over any network connection, not just the peer-to-peer Bluetooth connections established by the Game Kit framework.
A good general book on peer-to-peer networking with Bonjour, Apple’s name for zero configuration networking, is Zero Configuration Networking: The Definitive Guide by Daniel Steinberg and Stuart Cheshire (O’Reilly). You can find some good iPhone-specific examples using Game Kit in iPhone SDK Development by Bill Dudley and Chris Adamson (Pragmatic Programmers).
Apple has advertised the iPod touch as “the funnest iPod ever” and is pushing it heavily as a game platform competing directly with the Nintendo DS and Sony PSP platforms.
However, writing good games is a lot harder than most people would imagine, and is certainly not within the scope of a book such as this. If you’re interested in developing games for the iPhone platform, I recommend you look at iPhone Game Development by Paul Zirkle and Joe Hogue (O’Reilly). You’ll find that this book is a solid guide to the basics of game development, with good coverage of both graphics and audio topics as well as coverage of in-game physics engines.
Look and Feel
Apple has become almost infamous for its strict adherence to its Human Interface Guidelines. Designed to present users with “a consistent visual and behavioral experience across applications and the operating system,” the interface guidelines mean that (most) applications running on the Mac OS X desktop have a consistent look and feel, and behave in the same way. Long-time users of the platform generally view applications that don’t adhere to the guidelines with some suspicion, and even novice users sometimes get the feeling that there is something “not quite right” about applications that break them.
Even for developers who are skeptical about whether they really need to strictly adhere to the guidelines, especially when Apple periodically steps outside them, the Human Interface Guidelines have remained a benchmark against which the user experience can be measured.
With the introduction of the iPhone and iPod touch, Apple had to draw up a radically different set of guidelines describing how user interactions should be managed on a platform radically unlike the traditional desktop environment.
I heavily recommend that you read the mobile Human Interface Guidelines carefully, if only because violating them could lead to your application being rejected by the review team during the App Store approval process.
A copy of the iPhone Human Interface Guidelines is available for download from the App Store Resource Center in the “App Store Approval Process” section at http://developer.apple.com/iphone/appstore.
However, if you’d like to read more about how these guidelines are interpreted, and how to design engaging and effective user interfaces, I recommend that you read Programming the iPhone User Experience, First Edition by Toby Boudreaux (O’Reilly).
If you’re interested in using the External Accessory framework to work with third-party hardware, you need to consider becoming a member of the Made for iPod/Works with iPhone Developer Program. Licensed developers gain access to technical documentation, hardware components, and technical support so that they can develop their own hardware and software in parallel. More information about this program is available at http://developer.apple.com/ipod/.
However, if the thought of yet another set of NDAs is off-putting, you might want to look at iPhone Hacks by David Jurick, Adam Stolarz, and Damien Stolarz (O’Reilly). Among other things, this book discusses the pinout for the dock and headphone jack connectors, allowing you to connect external devices to your iPhone without having to join the Made for iPod/Works with iPhone Program.