Vincent Gable’s Blog

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.

May 26, 2010

drain an NSAutoReleasePool Don’t release it

Filed under: iPhone,MacOSX,Objective-C,Programming | , , ,
― Vincent Gable on May 26, 2010

To clean up an NSAutoreleasePool, do [pool drain]; not [pool release];

In a garbage-collected environment, sending any object a release message is hardcoded by the runtime to do nothing (very quickly). So [pool release] won’t do anything. But [pool drain] will signal the garbage collector to cleanup, and works correctly (just like release) in a non-garbage-collected environment.

Why This Still Matters on an iPhone

The iPhone doesn’t have garbage collection today. That doesn’t mean it never will. RIM and Android both support some kind of garbage collection. I’m too grizzled an Apple developer to not future proof my code, because I’ve been effected by Apple making some major runtime changes (eg. switching between PowerPC, x86, x86_64, and ARM processors). Section 3.3.1 of the iPhone SDK agreement means Apple’s runtime is the only game in town. It pays to be sure your code always plays nicely with it.

Using drain also helps your code will play nice with Mac OS X. That gives you more options to re-use and monazite it. If you decide to go the open-route, it means more people will be able to use your code.

May 19, 2010

N.A.R.C.

Filed under: Cocoa,iPhone,MacOSX,Objective-C,Programming,Tips | , , ,
― Vincent Gable on May 19, 2010

How to remember Cocoa memory management:

Think NARC: “New Alloc Retain Copy”. If you are not doing any of those things, you don’t need to release.

–Andiih on Stack Overflow

Personally, I like to immediately autorelease anything I NARC-ed, on the same line. For example:

Foo* pityTheFoo = [[[Foo alloc] init] autorelease];

Admittedly, this makes for some ugly, bracey, lines. But I think it’s worth it, because you never having to worry about calling release if you also…

Use a @property (or Setter) Instead of retain

In other words I would write an init method that looked like:

- (id) init
{
	self = [super init];
	if (self) {
		_ivar = [[Foo alloc] init];
	}
	return self;
}

as:

- (id) init
{
	self = [super init];
	if (self) {
		self._ivar = [[[Foo alloc] init] autorelease];
	}
	return self;
}

(Or [self setIvar:[[[Foo alloc] init] autorelease]]; if you are one of those folks who hate the dot-syntax.)

It’s debatable if using acessors in init and dealloc is a good idea. I even left a comment on that post arguing against it. But since then I’ve done a lot of reflection, and in my experience using a @property instead of an explicit release/= nil solves more problems then it causes. So I think it’s the best practice.

Even if you disagree with me on that point, if the only places you explicitly NARC objects are init, dealloc, and setX: methods then I think you’re doing the right thing.

Cycles!

The last piece of the memory-management puzzle are retain cycles. By far the best advice I’ve seen on them is Mike Ash’s article. Read it.

April 29, 2010

What Am I About To Call?

Filed under: Cocoa,iPhone,MacOSX,Objective-C,Programming,Reverse Engineering,Tips | , ,
― Vincent Gable on April 29, 2010

Say you’re in gdb, and about to execute a call instruction for dyld_stub_objc_msgSend, how do you know what’s about to happen?

On i386

(gdb) x/s *(SEL*)($esp+4)

tells you the message that’s about to be sent.

(gdb) po *(id*)$esp

tells you the target object that’s about to get the message.

January 15, 2010

EULA Today Fail

Filed under: Announcement,iPhone | , , , , , ,
― Vincent Gable on January 15, 2010

The EULA1 for the USA TODAY iPhone App starts off

General

These Terms of Service govern your use of the USATODAY.com website (the “Site”) only and do not govern your use of other USA TODAY services, such as services offered by the USA TODAY print newspaper.

Clearly this invalidates the agreement on the iPhone, since the iPhone App is not “the USATODAY.com website”.

This is mildly embarrassing for USA TODAY, and even more of a fumble for Mercury Intermedia, who built the app. But I can’t think of any way this actually hurts anyone, even in theory. Users are already bound by the App Store Terms and Conditions, so why bother putting your own EULA (that nobody’s ever going to read much less care about) in your app?

1To see the EULA, tap that little i near the bottom left of the homescreen, then tap Terms of Service. The text above was copied from version 1.5 of the USA TODAY iPhone App.

January 13, 2010

Splash Screens Are Evil

Filed under: Design,iPhone,Programming,Usability | ,
― Vincent Gable on January 13, 2010

Splash screens are evil. While branding is important, the proper place for it is in the iconography, optional “About” or “Info” screens, and App Store profiles. The most common interaction pattern with iPhone applications is to launch them frequently, close them quickly, and treat them as part of a set of tools that interact to comprise a single user experience. Splash screens break the perception of seamlessness.

The HIG offers a very useful suggestion for managing launch states, which may be quite slow, depending on the needs of your application. The suggestion is to provide a PNG image file in your application bundle that acts as a visual stand-in for the initial screen of your application. For example, if the main screen for your application is a table full of data, provide an image of a table without data to act as a stand-in. When your data is ready to be displayed, the image will be flushed from the screen, and the user experience will feel more responsive.

In this book, we will explore extensions of this, including a pattern for loading application state lazily

–Toby Boudreaux, iPhone User Experience, page 15; emphasis mine.

I’ve always hated splash screens, from the first time I turned on a computer. They get in the way of what I want to do. I want to write, or draw, or play — but if I launch Word, or Photoshop, or any game, I have to sit through a splash screen before I can get to it.

Branding a splashscreen is putting your name on a purely negative experience. Nobody wants to wait for their computer. Splashscreens, by definition, force you to wait. It’s hard for me to imagine why anyone wants to associate their brand with a computer not doing what customers want.

iPhone 4 Update

Fast App Switching, introduced in iOS 4, makes splash screens a much worse idea. They won’t consistently display, because sometimes the app will really be resuming, not starting for the first time, when the user “launches” it. Forcing a splash-screen to appear on a resume as well means breaking the “multitasking” experience.

December 9, 2009

Compile Safer

Filed under: Bug Bite,C++,Cocoa,iPhone,MacOSX,Objective-C,Programming | , , ,
― Vincent Gable on December 9, 2009

Peter Hosey explains what warnings he uses and why. It’s good, but long. Fortunately, you can just grab a script, and enable those warnings in your Xcode projects.

Warnings = Errors

If I could force just one compiler flag on everyone who’s code I use, it would be TREAT_WARNINGS_AS_ERRORS. As a rule, things don’t get improved if they aren’t broken. (How many times have you said “I’ll come back and fix this code later”? Yeah.) Warnings fester and grow on each other, until they cause a real breakage. It’s an inescapable evil of building software with finite resources.

If a warning isn’t worth stopping the build over — it’s not worth checking for in the first place.

Use the Latest Tools

Specifically, if you aren’t using Snow Leopard and Xcode 3.2 to build your Objective-C code, you are crazy. Trust me, painless static analysis is worth upgrading for. It catches maddening memory leaks, not just trivial type errors, like adding an int to an NSArray, that you would catch immediately.

November 15, 2009

Social Engineering iPhone Ratings

Filed under: iPhone,Quotes | , , ,
― Vincent Gable on November 15, 2009

The “Sex Jokes Lite” application is clever/manipulative about their ratings. They push people to give 5 star reviews with this little bit of a social contract: in their app-description they say,

“IMPORTANT: If you think the jokes are TOO dirty, please give a 1-star review. If you want them dirtier, give a 5-star review. This way we know what direction to take in the upcoming updates !”

—Dan Grigsby

Clever, but a bit of a dirty trick *rimshot*.

« Newer Posts — Older Posts »

Powered by WordPress