Vincent Gable’s Blog

June 24, 2010

Retina Ready

Filed under: Announcement,Design,iPhone,Programming,Tips | , , , , , ,
― Vincent Gable on June 24, 2010

The iPhone 4’s ultra-sharp “Retina Display” really is a game changer. Until now, popular computer screens have been so low resolution, they could only display crude, low density, designs. It will take a few years for such high resolution screens to filter up into the personal computer space. But if you start writing an application that takes advantage of the iPhone 4’s display now, there will be millions of people who can use it by the time you’re done.

The best source I can recommend for understanding the kinds of designs that take full advantage of high PPI displays are Edward Tufte‘s classic design books:

If you just get one, make it The Visual Display of Quantitative Information.

PS: Tufte’s books are themselves examples of beautiful, complex, high density design, and as such really only make sense printed. At least for the next few years. Even if you can find an electronic version, I wouldn’t recommend reading it, because it won’t convey the power of a 1600 PPI display (printer).

June 17, 2010

The Arrow Points Up

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they’re current working at is exactly the right one for the task at hand. Anything lower-level is seen as barbaric, and anything higher-level is a bloated, slow waste of resources. This remains true even as the overall level of abstraction across the industry marches ever higher.

First the C guys can’t imagine writing in assembly anymore, but C++’s vtable dispatch is still just too slow to consider. Then the C++ guys look back with chagrin at the bad-old-days of rolling their own half-assed object systems in C, but Java is dismissed as a ridiculous pig. Still later, the Java guys sneer at pointers and manual memory management, but JavaScript is ridiculed as a toy “scripting” language for validating web forms. And on and on.

And in the short term, in the moment, they’re often right. But this arrow points only one way, and that’s in the direction of ever-higher abstraction. To judge how much time remains before the next leap forwards, look at the leading edge of the industry.

John Siracusa (emphasis mine)

Here’s my two cents on the future of abstraction: systems are clearly getting wider (paralell), not faster; technologies like Grand Central Dispatch help us deal with concurrency today, but longer term, I think a functional programming abstraction is the answer.

June 14, 2010

Ask F-Script!

Filed under: Cocoa,iPhone,MacOSX,Objective-C,Programming | , , , , , ,
― Vincent Gable on June 14, 2010

F-Script is an amazingly useful tool for answering quick API
questions, like “What happens if I pass in nil“. I use it several times a week. For verifying corner-cases, F-Script is faster than google, stackoverflow, or reading header files. Just type in a questionable expression and instantly see what happens.

There’s a good tutorial to get you started quickly. I’m not going to reproduce it here, so if any of these examples aren’t clear, go read it.

Example: NSMutableArray

Objective-C had historically poor support for exceptions, and the Foundation/Cocoa libraries are pretty inconsistent about using them. For example, trying to add nil to an array throws an exception, but trying to remove nil from an array has no effect. Here’s how I used F-Script to verify that,

> a := NSMutableArray array

> a addObject:nil
NSInvalidArgumentException: *** -[NSCFArray insertObject:atIndex:]: attempt to insert nil

> a addObject:'foo'

> a
NSCFArray {'foo'}

> a removeObject:nil

> a
NSCFArray {'foo'}

If you’re not impressed, I understand. Static text really can’t convey the power of an interactive console. Sure, the F-Script syntax is marginally more concise than writing the equivalent code in Objective-C, but not enough that it matters. What matters is the interactivity, I got my answer as soon as I hit return. No waiting on the compiler. No switching between the program and Xcode. Immediate feedback.

You might prefer to use python as a Cocoa console. That’s cool! I prefer F-Script because it’s closer to Objective-C, but any tool with a REPL console works. If you have a favorite, please leave a comment!

REPL consoles for exploring Objective-C on a Mac:

June 11, 2010

Simulator Advertising?

Filed under: Announcement,iPhone,MacOSX,Programming | , , , , ,
― Vincent Gable on June 11, 2010

I wish I could take credit for this idea, but it’s from someone else, will Apple sell iAds that only show up in the iPhone simulator? Probably not, but it would be a hell of a targeted demographic.

For those of you who aren’t familiar with how building iPhone software works, we developers spend thousands of hours testing and debugging our programs in an iPhone Simulator application that runs on our Macs. The simulator can’t run Apps from the App Store, only programs compiled from source code with Xcode. So the only people using the simulator are programers, or otherwise deeply involved with building iOS apps. Apple could make it so that any iAds in the simulator would show special ads targeted to developers.

Better still, iAds in the simulator could show something useful like rules from the Human Interface Guidelines (that too few read), good tips or even inspiring quotations.

June 9, 2010

Apple’s Typographic “Perfection” Sucks

Filed under: Design,iPhone,Quotes | , , , ,
― Vincent Gable on June 9, 2010

…one particularly outrageous moment stuck out for me. At about three minutes into the video, senior vice president for iPhone software Scott Forstall extolls the virtues of the Retina Display by declaring that “The text… is just perfect!” Meanwhile, the central image in the video at just that moment is this little typographic calamity:

2010-06-08-ibooks.png

I urge you to fast-forward the time code to 3:02 to hear this for yourself. Forstall is quite literally claiming perfection while a hand model holds up this terrible example of everything that’s wrong with Apple’s commitment to typography. While the letterforms on that virtual page may look gorgeous, it’s apparent to any designer that the text is far from perfectly typeset. It’s hideous, scarred as it is by unsightly “rivers” of bad spacing within the text. No self-respecting typographer would dare call that perfect.

Khoi Vinh

The unrelenting drive for perfection was a quality I always admired in Apple. I hope this is just bullshit spin, and an unfortunate choice of sample frames.

June 7, 2010

Quality is Money

Filed under: iPhone,MacOSX,Programming,Quotes | , , , ,
― Vincent Gable on June 7, 2010

The truth is that an iPad app is neither easier nor harder to make than an iPhone app (or a Mac or Windows app), in any general, reasonable, defensible way. Software doesn’t work like that; we don’t have to work twice as hard to cover twice as many pixels on screen. It’s all about the elusive quality factor.

Matt Legend Gemmell, on iPad App Pricing

Amen!

June 2, 2010

NSHomeDirectory() is a Bad Thing

Filed under: Announcement,Cocoa,iPhone,MacOSX,Objective-C,Programming | , ,
― Vincent Gable on June 2, 2010

Code that uses NSHomeDirectory() is probably doing The Wrong Thing. It’s not appropriate to clutter up the user’s home directory — internal application-data should be stored in the Application Support directory (or a temporary file if it’s transient). So I can’t think of a good reason to get the path to the user’s home directory. Every use of NSHomeDirectory() I’ve seen is spamming the home directory, or getting a subdirectory in a brittle way.

For sample code that gets a directory robustly, using NSSearchPathForDirectoriesInDomains(), see Finding or creating the application support directory.

Because NSHomeDirectory() encourages so many bad practices, it should be deprecated.

Disabling NSHomeDirectory() in Your Projects

Add the following macro to your prefix file:

#define NSHomeDirectory() NSHomeDirectory_IS_DISCOURAGED_USE_NSSearchPathForDirectoriesInDomains_TO_GET_A_SUBDIRECTORY_OF_HOME

Then any use of NSHomeDirectory() will give the compiler error:

error:
‘NSHomeDirectory_IS_DISCOURAGED_USE_NSSearchPathForDirectoriesInDomains_TO_GET_A_SUBDIRECTORY_OF_HOME’ undeclared (first use in this function)

Tell Me I’m Wrong

If you’ve seen a legitimate use of NSHomeDirectory() please leave a comment! Just because I can’t think of one doesn’t mean they don’t exist.

Powered by WordPress