Vincent Gable’s Blog

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.

May 17, 2010

Don’t Check For nil in Your dealloc Methods

Filed under: Cocoa,Programming | , ,
― Vincent Gable on May 17, 2010

There’s no need to check if a variable is nil before release-ing it, because calling a method on a NULL variable is a no-op in Objective-C. And the runtime already has a super-fast check for this case.  So adding an extra if test into your code will probably slow things down.

Doing a pointless ” ==?nil”  test is bad for two reasons.

Firstly, it’s more code for no good reason. Even if it’s just one more line, It’s one more line to debug and test. It’s one more place where something could go wrong.

Secondly, it’s not idiomatic Cocoa-code, so it signals that something strange is going on. That’s a problem for whoever is reading the code, because they have to stop and look around more carefully to figure out why the pointless tests are happening.

In summary, do NOT do this:

– (void)dealloc;

{

if(baseImage) {

[baseImage release];

baseImage = nil;

}

[super dealloc];

}?

Do this:

– (void)dealloc;

{

[baseImage release];

baseImage = nil;

[super dealloc];

}

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.

March 29, 2010

No Love and No Science

Filed under: Design,Quotes,Usability | , ,
― Vincent Gable on March 29, 2010

…But in practice, nearly all the great analytical designs have come from those possessed by the content; people who have learned something important and want to tell the world about what they have learned. That is, content-driven and thinking-driven, and not at all driven by bureaucratic externalities of marketing, human factors, commercial art, focus groups, or ISO standards.

In working on 4 books on analytical design, I have often turned to the human factors literature, and then left in despair, finding few examples or ideas (beyond common-sensical) that were useful in my own work. This contrasts to the work of scientists, artists, art historians, and architects–work overflowing with ideas about evidence, seeing, and the craft of making analytical displays.

I believe that work about analytical displays should be self-exemplifying; that is, the work should show us amazing displays of evidence. My despair about human factors began many years ago upon going through volumes and volumes of the journal, Human Factors, where evidence was reported using statistical graphics of wretched quality, with thinner data and worse designs than even in corporate annual reports.

Also the methodological quality of the research was poor, and so nothing was credible. The findings seemed entirely context-dependent, univariate (design and seeing are profoundly multivariate), and without scope: what did it matter if some students in freshman psychology in Iowa preferred one clunky font compared to another clunky font in an experiment conducted by a teaching assistant? Later, while consulting, I saw this naive dust-bowl empiricism fail again and again for nearly a decade in trying design a competent PC OS interface. (And with the Mac interface sitting there, smiling, all the time. Apple’s superb interface guidelines seemed to me to be a retrospective account of the beautiful hands-on craft of a few brilliant designers, not a reason to have experimental psychologists attempt to design OS/2 and Windows.)

At any rate, if this was the scientific practice and the design craft of applied psychology, I concluded the field did not have much to contribute to my own work on analytical design.

I happily fled to the classics of science, art, and architecture.

Edward Tufte, November 27, 2002 (emphasis mine).

It’s still pretty bleak.

March 25, 2010

“Otherwise there’d be no sense to it”

Filed under: Announcement,Quotes | , , ,
― Vincent Gable on March 25, 2010

…She bent forward to put a white hand on my knee. “There is wealth in that cellar beneath the garage. You may have whatever you ask”.

I shook my head.

“You aren’t a fool!” she protested. “You know-”

Let me straighten this out for you,” I interrupted. “We’ll disregard whatever honesty I happen to have, sense of loyalty to employers, and so on. You might doubt them, so we’ll throw them out. Now I’m a detective because I happen to like the work. It pays me a fair salary, but I could find other jobs that would pay more. Even a hundred dollars more a month would be twelve hundred a year. Say twenty-five or thirty thousand dollars in the years between now and my sixtieth birthday.

“Now I pass up about twenty-five or thirty thousand of honest gain because I like being a detective, like the work. And liking work makes you want to do it as well as you can. Otherwise there’d be no sense to it. That’s the fix I am in. I don’t know anything else, don’t enjoy anything else, don’t want to know or enjoy anything else. You can’t weight that against any sum of money. Money’s good stuff. I haven’t anything against it. But in the past eighteen years I’ve been getting my fun out of chasing crooks and solving riddles. It’s the only kind of sport I know anything about, and I can’t imagine a pleasanter future than twenty-some years more of it. I’m not going to blow that up.

Excerpt from The Gutting of Couffignal by Dashiell Hammett. All monies are in 1927 US Dollars. It’d buy me a couple of nice houses today.

March 23, 2010

Cocoa Influenced The Gang of Four

Filed under: Cocoa,Design,Objective-C,Programming,Quotes | ,
― Vincent Gable on March 23, 2010

Next time you want to gloat about how seminal Cocoa is,

Erich Gamma: Yes, and it is funny that you mention the iPhone. The iPhone SDK is based on the NeXTStep object-oriented frameworks like the AppKit. It already existed when we wrote Design Patterns 15 years ago and was one source of inspiration. We actually refer to this framework in several of our patterns: Adapter, Bridge, Proxy, and Chain of Responsibility.

Richard: Which is a great example of the enduring nature of good design, and how it survives different technical manifestations.

Erich: Just as an aside, it is also easy to forget that we wrote design patterns before there was Java or C#.

Source: Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson

March 18, 2010

The Most Depressing Thing I Heard in 2008

Filed under: Programming,Quotes | , , , ,
― Vincent Gable on March 18, 2010

In a way ideas only count for a little in computing, because you kind of have to implement this stuff. This is the part of the story that really makes me clutch at my throat, because every time you implement something, 5 years go away.

Alan Kay

February 15, 2010

Usability Problems are Cultural

Filed under: Accessibility,Programming,Quotes,Usability | , , , ,
― Vincent Gable on February 15, 2010

Obstacles to getting real feedback are now mainly cultural, not technological; any business that isn’t learning from their users doesn’t want to learn from their users.

Clay Shirky, on Meetup’s Dead Simple User Testing

February 9, 2010

This Usually Makes Me Feel Better

Filed under: Announcement,Bug Bite,Design,Programming,Quotes,Usability | , , , , ,
― Vincent Gable on February 9, 2010

February 6, 2010

All Your Facebook Friend’s Phone Numbers

Filed under: Announcement | , ,
― Vincent Gable on February 6, 2010

http://www.facebook.com/friends/?filter=pfp

That’s the link to all your facebook-friend’s phone numbers.

Every time I see one of those “I need ya phone numbers” things on facebook I post that link. Please do the same. At least until the phone companies fix the real problem by automatically backing up contacts from the phone “in the cloud

« Newer PostsOlder Posts »

Powered by WordPress