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!
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.
NSHomeDirectory() in Your ProjectsAdd 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)
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.
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.
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.
As soon as you give a class a new instance variable (ivar), update the class’s dealloc method (and viewDidUnload, if the ivar is an IBOutlet) to clean up the ivar. Do this before you write the code using the new ivar. Here’s why:
You can’t forget to release an ivar, if the code that reaps it is in place before the code that creates it. Updating dealloc first means less memory leaks.
Even with an impossibly good testing protocol, that catches every memory leak, it’s faster to fix memory leaks before they happen than to track them down after the fact.
Sometimes there’s an important step that must be done when cleaning up an ivar. Maybe you need to set it’s delegate to nil, or unregister for a notification, or break a retain cycle. You know this when you setup the ivar. But your coworkers don’t know this a priori. When you checkin code that leaks or triggers an analyzer warning, they’ll want to fix it, and since they know less than you do about your code, they’re more likely to miss a crucial step. (Even if you work alone, remember Future You! In N weeks, Future You will have to deal with all the code Present You wrote today … and they’ll be in the same situation as any other co-worker, because they won’t remember everything Present You knows. )
Never name a variable index, especially in C.
Instead say what it indexes. For example, if it is used to index an array of Foo objects, call it fooArrayIndex, or currentFooIndex.
If the index variable is just used to enumerate over a collection of objects, (eg. for(int i = 0; i < arraySize; i++){…} ) then iterate smarter, using a simpler construct that doesn’t require declaring auxiliary variables. (Eg., in Objective-C use Fast Enumeration). It’s not always possible to do this, but it’s always a good idea to try.1
index is Especially Bad in CThe standard strings.h header declares a function named index, that finds the first occurrence of a charicter in a C-string. In practical terms every C program will have the index function declared everywhere.
But when a variable is declared with the name index it shadows the function — meaning the local variable named index takes over the name index, so the function can’t be called anymore:
char * world = index("Hello, World", 'W');
NSLog(@"'%s'", world);
Prints “‘World'”, but
int index = 0;
char * world = index("Hello, World", 'W');
NSLog(@"'%s'", world);
Won’t compile, because an int isn’t a function.
Obviously this is a problem for code that uses the index() function — but honestly modern code probably uses a safer, unicode-aware string parsing function instead. What’s given me the most trouble is that shadowing index makes the compiler give lots of bogus warnings, if you have the useful GCC_WARN_SHADOW warning turned on.
There are other good reasons as, specific to Objective-C, which Peter Hosey covers.
1If you really can’t think of a better name than “index”, I prefer the more terse i. It sucks, but at least it’s shorter. Brevity is a virtue.
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…
@property (or Setter) Instead of retainIn 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.
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.
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];
}
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?
(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.
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
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.
Powered by WordPress