Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Meet The Authors of iPad Programming : A Quick Start Guide for iPhone Developers

DZone's Guide to

Meet The Authors of iPad Programming : A Quick Start Guide for iPhone Developers

· Mobile Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

A couple of weeks ago I started reading my first book on iPad development, from The Pragmatic Bookshelf. iPad Programming: A Quick Start Guide for iPhone Developers is a great read, and very easy to get into, as we've come to expect from the pragmatic series. I got the chance to ask the authors, Daniel Steinberg and Eric Freeman, some questions about iPad development, to get a better appreciation of it, and the differences to programming for other mobile devices. 

DZone: What are the core differences between developing for the iPhone and the iPad?

Daniel: It sounds like a silly answer --- but the size of the devices.

I know it's very tempting to write once and then try to run the same application everywhere but you have to look at each device individually from the point of view of your end-user. You can do text input and audio editing on your iPhone, but these tasks are more easily accomplished when your finger isn't masking such a large portion of the screen. So to start with, the tasks you're going to allow the users to perform are different on the phone and the iPad.

Second, the smaller iPhone screen means that you will tend to have deeper hierarchies. The user will make a choice from a table and then navigate to the next level and make another choice. With the iPad, Apple's advice is that you look to flatten these hierarchies as you can present more data at once on the screen.

An easy example is the standard split-view on the iPad. The user can make a selection in the left pane and see the detail view for their selection in the right pane. On the iPhone you would navigate from one to the other and only one level would be visible at a time.

So if you look at the two devices from the consumer's point of view you'll nail the differences. As for the similarities, with iOS 4 a lot of the features introduced for the iPad are now available on the iPhone. Soon when iOS 4 comes to the iPad you'll find the two platforms will merge. Fortunately, many of the topics we covered for the transition to the iPad are also core features that you'll want to take advantage of in iOS 4.


DZone: You mention that before you start developing you need to feel the device in your hands. What are the dangers of developing based on the emulator?

Daniel: The reason I suggest getting the device in your hands is that it is different than a laptop or an iPhone. If you develop on your Mac and never touch an iPad you won't fully embrace the gestures available to you and the rhythm of moving from screen to screen. Interacting with your laptop is different than interacting with an iPad. You get the basic idea if you own an iPhone but then you won't truly grasp what the additional real estate provides.

So I wasn't really warning about the dangers of developing based on the emulator when I gave that advice but, of course, you need to deploy to the device throughout your development process. The emulator has gotten much better recently and it now takes advantage of the modern runtime. You'll see that we rewrote the code in the book to take advantage of the fact that, for instance, you don't need to explicitly declare the ivars that back up your properties. The main reason that you now want to make sure that you are deploying to the device is to make sure that you haven't fooled yourself into thinking your app is more performant than it actually is. I'd hate for you to do all your development on one of those sexy new 12 core machines and then deploy it to your single core iPad to discover that the profile is just a bit different.

DZone: I've heard about a way that I can write an application for both the iPhone and the iPad. How does this work? I presumed that it was not an appropriate solution for UI based applications?

Daniel: We begin the book with an example of taking an iPhone app and turning it into an app that works on both platforms. You're right, you need to think carefully about the UI differences. This is a good solution if your app is doing the same thing on both platforms but in different ways. You'll share your model code and make adjustments in the View Controllers for the two platforms. You'll probably find even there that you are sharing some base code in the controller layer for both platforms and customizing some of the functionality in sub classes.

So you need to again look at the app from the point of view of the consumer. If this is essentially the same app on both devices then a common code base might make a lot of sense. Maybe you have two different apps. Say the iPhone version is for browsing and consuming some type of media while the iPad app adds the ability for creating and organizing some of the assets. In that case you'll want two different binaries and you'll need to start thinking about whether its time to split your development into two projects or not.

DZone: What do you think of cross-compile approaches such as Appcelerator in place of pure Objective-C?

Daniel: For me it's kind of like the iPad and the iPhone. You need to look at different mobile devices from the consumers point of view not from the company creating the app's point of view. If you can capture the model logic in some common code then that probably makes sense. But you really want your iOS apps to feel like other iOS apps. We saw desktop Java apps on the Mac and they didn't tend to look and feel like other native applications --- not without a good deal of custom work. I can see the appeal to companies to have a common code base with tweaks and a cross-compile for each platform. I can equally see how Apple isn't so interested in this approach. What is special about their devices in that world?

When Apple first shipped the iPhone they told developers that they could create web apps for the iPhone. Developers screamed. They wanted access to the same APIs as Apple.They wanted to create native applications. I think that's great. Apple complied and gave us APIs and tools---we should use them.

DZone: How do you find Objective-C as a development language? For a Java developer who wants to develop for the iPad, what tips could you give to make things easier?

Daniel: I've come to love Objective-C and as Xcode improves this becomes a better world in which to live. I teach Objective-C as part of the iPhone Studio (for Pragmatic Studio) and find different people object to different parts of it. Java developers are often bothered by the dynamic nature of the language whereas Rubyists complain that its not dynamic enough.

Ruby programmers also complain about the verbosity. In Objective-C it sometimes feels as if a method signature is longer than its body. Once you get used to the verbosity you'll come to rely on it. The methods describe the parameters they expect which makes calling a method start to feel natural. I don't know if it's true but it feels as if you write a lot less code in Cocoa applications. On the other hand, it sometimes takes you longer to write this lesser amount of code than in different settings.

Also, you can take advantage of the code completion to avoid typing in those long method names. It's not IntelliJ or Eclipse. You'll hear Java and .Net developers complain about the tools for working with code. First of all - just wait. We've got some very cool tools on the way with Xcode 4. Second, a lot of it comes from folks who are fighting the language. They are trying to write code in Objective-C that is essentially Java or C# rather than embracing delegates and properties and so on. You'll also find the going is a bit tough if you insist on writing everything in code. Embrace the nib - you'll be much happier.

DZone: What do you think will be the killer apps on the iPad?

Daniel: For me the killer apps are the ones that disappear. When I'm using them the device and the app melts away and I become immersed in a task. My background is math education so I'd love to see some solid math teaching apps for the iPad. I'd love to be able to have Apps and books work together or to embed little apps in books so that books come alive for students and are truly interactive.

DZone: What do you think of Androids chances against iOS?

Daniel: It's, of course, impossible to predict the future but I would never bet against Google. I spent a lot of time writing Java code and would rather be writing in Obj-C for the Mac and for the iPhone and iPad right now. I remember when I had just finished co-writing the Java 2 Bible and my editor asked me if I wanted to write the first book on C# (it was then known as COOL). I talked to friends and they reminded me that you live in the world of the technology that you're writing about. You speak at conferences, you teach classes, and you consult in the areas that you write about. At the time I loved the people and the the community that I was a part of with Java and didn't want to jump to the world of C#.

 I feel the same way about Cocoa. I love the technology, the people, and the ecosystem around the iOS devices and Mac OS X. These are the people I want to hang with and the technology I want to work on. That's not a slam against Android, I just love what I'm doing.
 



DZone: What do you think will be the killer apps on the iPad?

For me the killer apps are the ones that disappear. When I'm using them the device and the app melts away and I become immersed in a task. My background is math education so I'd love to see some solid math teaching apps for the iPad. I'd love to be able to have Apps and books work together or to embed little apps in books so that books come alive for students and are truly interactive.

DZone: What do you think of Androids chances against iOS?

It's, of course, impossible to predict the future but I would never bet against Google. I spent a lot of time writing Java code and would rather be writing in Obj-C for the Mac and for the iPhone and iPad right now. I remember when I had just finished co-writing the Java 2 Bible and my editor asked me if I wanted to write the first book on C# (it was then known as COOL). I talked to friends and they reminded me that you live in the world of the technology that you're writing about. You speak at conferences, you teach classes, and you consult in the areas that you write about. At the time I loved the people and the the community that I was a part of with Java and didn't want to jump to the world of C#.

 I feel the same way about Cocoa. I love the technology, the people, and the ecosystem around the iOS devices and Mac OS X. These are the people I want to hang with and the technology I want to work on. That's not a slam against Android, I just love what I'm doing.
 

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}