Marcus Zarra and Matt Long on Core Animation
Matt Long and Marcus Zarra are currently working on a book on Core Animation, Apple's new user interface layer used for visual effects on OS X and the iPhone, due out later this year. I talked to both of them about their experiences with Apple platforms and their hope for the upcoming keynote.
David Chisnall: There are lots of rumours about what will be announced at the keynote this year. Is there anything you're particularly hoping for?
Matt Long: All of the rumors we're hearing about right now are either terribly non-compelling or they are recycled wishes we've been hearing for years (blu-ray support or integrated 3G on the Mac Book). I don't see any of those happening. This is the first year where I'm going in with pretty low expectations. With no Stevenote it's either going to be a big yawn, which is what I'm anticipating, or they're going to blow us away with something exciting that no one saw coming. iPhone 3.0 is very exciting in itself, but it's old news by now. We're already familiar with the new APIs and are looking forward to its release. That won't happen until the new phone hardware is out though.
Marcus Zarra: One that has not seen a lot of rumors that I am hoping for is a revision of the 30" ACD. While the new 24" is very nice, I am looking forward to the 30" being Mini-Display port compatible.
I am also looking forward to the iPhone tethering that has been dangled in front of developers on more than one occasion.
DC: How important do you think Steve Jobs has been to Apple's recovery since the 90s?
ML: He is so iconic that it's hard to believe anyone else could have had his impact and subsequent success. Maybe someone else could have turned the company around, but I can't think of who. Steve and Apple have a special bond. The company wouldn't be the same without him.
DC: Ignoring business realities for a moment, are there any markets where you'd like to see Apple products?
ML: Netbooks, maybe? I'm not sold on this one by an means, but I did purchase an inexpensive netbook recently and was impressed by what it could handle for the price. I think the Macbook Air is intended to compete in this ultra-portable space, but the cost of a Macbook Air is roughly $1500 more than I paid for the netbook. The Air is sexy and from what my friends tell me a decent computer even for developers (I haven't actually used one on a daily basis). It's not that the price is out of reach. It's just that once I'm at that price point I would go ahead and spend a couple hundred more to get the low-end Macbook Pro.
DC: Have you spent any time working on the iPhone, and if so what do you think the most difficult thing is for people coming from a desktop-Cocoa development environment?
ML: This is what is amazing about the iPhone. It's not embedded systems programming. There are certainly memory limits that you will bump into from time to time, so you do have to think about optimization a lot earlier and more often. However, in general it's a very familiar and comfortable environment. I've done embedded systems programming and this is not that. As has been said elsewhere, the iPhone is not just a phone. It's a computing platform. If you already have desktop experience on the Mac OS X, you will feel right at home on the iPhone. I can't really think of any insurmountable hurdles for programmers who already have experience on the Mac.
MZ: The biggest difficulty I believe is the lack of bindings. Desktop OS X developers are used to and comfortable with having Interface Builder access values and set values within the controllers directly. On the iPhone we do not have that capability (yet).
A close second is memory. As Desktop developers we are used to having effectively unlimited memory for our applications thanks to ever-growing memory capacities and virtual memory. However on the phone we have some very hard limits.
DC: You mentioned memory usage being a problem for iPhone development. Is the presence of garbage collection on the desktop making it harder to adjust to the iPhone's NeXT-style reference counting?
MZ: Not at all, as I do not use GC on the desktop. GC is a relatively new concept (it was first released in Leopard in late 2007). I spent many years working with reference counting before the iPhone and still prefer it to this day. Java has really caused me to dislike GC in general.
DC: I'm interested to hear Java turned you against GC, as Java, running in a VM without pointers, can make use of accurate GC, while Objective-C is limited to conservative GC. What made you dislike it?
MZ: Java's GC was terrible for many years, especially when working on a User Interface. It would frequently freeze the entire application while the GC ran and cause performance hick-ups. It may have improved in the last few years but the first 8 were enough for me.
DC: On a related topic, do you think it's easier for people unfamiliar with Objective-C to learn to program the iPhone or OS X on the desktop?
ML: It is probably easier to start learning Objective-C on the Mac OS, but I only say that because it *feels* so. The only reason I can think of to start on the desktop is because the project templates are a little easier to deal with. You can create a simple Cocoa app with the basic template. Drag a few controls on the window and hook them up and you're ready to add some code. The same is mostly true for the iPhone, but you do have to have some familiarity with view controllers and the like before you can get too far.
Honestly, learning Objective-C itself is probably the biggest challenge coming from other languages regardless of whether you develop on the Mac or the iPhone. My advice to anyone doing so is to avail yourself to the fact that you don't do things the way you're used to. I've done a lot of Windows development and I had to unlearn a lot in order to become a more effective and capable Objective-C developer. Don't try to make the Mac/iPhone dev environment into what you're used to. You'll get frustrated and give up.
MZ: If you are just coming to Objective-C, I believe that the iPhone is easier to get up to speed on. It has a smaller API to wrap your head around and it does not have a lot of legacy code which can be confusing to newer developers. Also the hard limits with regard to screen, memory, networking and storage can instill good habits in a new developer.
DC: Was OS X your first introduction to Objective-C, or had you encountered it before elsewhere?
MZ: Yes, OS X was my first introduction to Objective-C.
ML: When I started to pursue programming the Mac I tried to stick to the familiar and just use straight C or C++, but found it very frustrating. When I met Marcus Zarra, my co-author on the Core Animation book, he encouraged me that if I wanted to become a Mac developer, I needed to learn Objective-C. From there it was just a short time under Macus' tutelage before I felt comfortable with it and started to love it. There are certainly quirks in the language--string concatenation for example, but some of the conventions built into it such as key-value-coding (KVC) and key-value-observing (KVO) were pretty revolutionary to me. Also the fact that method parameters are all named helps the code be more self documenting. This is pretty compelling for when you have to read and figure out existing code.
I've not been this excited about a programming language in a long time if ever. Though I have to confess I am a perl guy from way back. I still love it if that tells you anything.
DC: What other languages do (or did) you regularly use, and are there any features or idioms you miss, either going to or from Objective-C?
ML: Objective-C is not alone in this, but the main thing I miss is having regex built into the language. There are some great libraries out now, but any regex library feels cumbersome compared to the world of Perl. I admit that the amount of text parsing I do isn't a ton, but when you're in a position where you need to extract some text, it's nice to just throw a regex at it and get what you need quickly. NSScanner just doesn't cut it most of the time, and character iteration is great if you're a glutton for punishment. I've been tempted on occasion to call out to the perl command line interpreter to parse HTML, but I've found that if an HTML document is well-formed, you can simply load it into an NSXMLDocument and access the fields you need using XPath. It's actually a pretty slick solution assuming the document is in fact well formed, but when it's not I *need* regular expressions.
DC: Had you used other Smalltalk-family languages before learning Objective-C, or been inspired to learn others since?
MZ: I had worked with Smalltalk itself in the late 90s when I worked in the banking industry.
DC: Coming from Smalltalk to Objective-C, I imagine that losing blocks (closures) was a shock. Now that Apple is reintroducing them, do you think you will make much use of them? How, if at all, will they change your style of programming?
MZ: I have been focusing on the iPhone so much lately that I have not had a chance to really play with them, but I am looking forward to them once my development efforts turn back towards the Desktop.
DC: What do you like most about developing with OS X?
MZ: The language is quite elegant and the UI is a pleasure to look at. Objective-C feels closer to the metal than some of the "4th" generation languages out there, and the fact that it is a thin layer on top of C makes it feel more so. Also, the developer teams are very small both inside and outside of Apple. Each individual developer can truly make a difference on this platform.
DC: CoreAnimation is present on both desktop and mobile Cocoa, but how easy do you find it to move code between the two?
ML: The differences between the two are not huge. Naming is different as everything in UIKit, the iPhone SDK for the user interface, is named starting with UI while the desktop counterparts in AppKit start with NS (for NextStep), e.g. NSView vs UIView. There are a few basic nits that we cover in the Core Animation book where you'll have to be careful as well. Colors, for example while using the same low level class, CGColorRef, create the object differently. On the Mac OS, you have to use a C call such as CGColorCreateGenericRGB which takes the red, green, blue, and alpha values as parameters where on the iPhone, you can simply use the UIColor class methods such as [[UIColor redColor] CGColor] which returns the CGColorRef you need.
MZ: It is surprisingly easy. Core Animation was original developed for the iPhone and then "ported" to the desktop. While there are more features available on the desktop (today), they are still quite comparable and code moves between them quite easily.
DC: UIKit on the iPhone seems to encourage using CoreAnimation as a replacement for the NSCell model in AppKit. Are there any other patterns you can think of that are more appropriate to CoreAnimation on one of the platforms?
ML: The Core Animation layers that Apple has provided on the desktop give you incentive to start using them. For example, the CAOpenGLLayer abstracts a lot of the setup code for rendering OpenGL textures. It makes it pretty easy to start using OpenGL, even if you've never used it before. Of course mastering OpenGL takes a much greater investment of time, however, the OpenGL layer makes it feel more like wading in rather than being thrown in the deep end head first. This is also true of the other media-related layers such as QTMovieLayer, the QuickTime movie layer, or QCCompositionLayer the Quartz Composer layer. Both of these are extremely easy to use and only require a couple lines of code to see them in action.
MZ: While not necessarily a pattern, Core Animation has introduced the concept of a Layout Manager to the desktop. Prior to Core Animation, layout was handled by Springs and Struts and there really was no other option. With Core Animation we can write our own custom layout managers that can handle any situation we can dream up.
DC: Like any improvement to a GUI toolkit, CoreAnimation can be used to produce more intuitive user interfaces and for distracting eye candy. What advice would you give to developers aiming to avoid the second option?
ML: The more time I've spent working with Core Animation, the more I'm convinced you have to try hard to use it for evil. Basic design principles apply regardless, so there is ultimately nothing new in this discussion. Keep it simple, stupid. Having obeyed that rule I think developers should animate whatever, wherever to their heart's content. Just don't forget the first rule.
MZ: Keep it simple. That is always the best advice. A User Interface is not complete when there is nothing left to add, but it is complete when there is nothing left to take away. Users are impressed by simple elegant solutions.
DC: If you were allowed to change UIKit, AppKit, and CoreAnimation in any way, including things that would break backwards compatibility, what would you change first?
ML: I've spoken with some Apple engineers and realized we are not playing with the same set of God-given abilities. These folks are sharp, and frankly I don't think I have the chops to go toe-to-toe on the merits of design decisions they make. I guarantee there are bone-headed decisions happening because hubris is a virtue to software engineers and pride, as they say, goes before a fall, but Apple is pretty good about listening to developers. If I bump into something frustrating, I find the workaround (and there almost always is one) and then file a radar. That's the way you work with Apple. If you don't like something, let them know. They might ignore you, but they might not.
MZ: The one I fight with the most is the CGImageRef requirement for Core Animation layers and their content. I would prefer if it could accept a NSImage and handle the translations under the hood for me. Hmmm, perhaps I should write a Category for that.
That is one of the very nice things about Objective-C in general. If you do not like something about an API or feel that it should work in another way, it is easy to extend the functionality to fit your needs.
DC: Are there any lessons from CoreAnimation that you think designers of other GUI toolkits should learn?
ML Absolutely. The simplicity of its design is one of the things that makes it so valuable. It is one of the few APIs that handles the tweening for you and is still simple.
DC: What projects are you currently working on?
ML: I'm currently working on an iPhone app that provides a simple interface to Amazon's S3 (Simple Storage Solution) web service. It allows you to manage your assets from your iPhone. It's been a pretty fun app to develop. I'm almost at a 1.0 so hopefully that will be in the App Store soon--probably not by WWDC, though.
MZ: I am currently working on several client projects that are under NDA. I am working on a new release of iWeb Buddy which is due out in June. I am a frequent writer on the Mac Developer Network, which I highly recommend as a resource for new developers. I am finishing up our Core Animation book. And lastly I am finishing up a book on Core Data.