IOS4 note 13 (4)

Memory Management of Pointer-to-Void Context Info

A number of Cocoa methods take an optional parameter typed as void*, and often?called context.?An id is a universal object type; void* is just a C pointer. This means that Cocoa won’t?treat this value as an object. So the use of the void* type is a clue to you that Cocoa?won’t do any memory management on this value.?

As an example, ?I’ll use beginAnimations:context:. You call ?this on a UIView before?changing one or more of its property values, such as its size, position, or opacity, to?make ?those changes appear animated.

A better approach is to make these context objects persistent, as instance variables or?globals, and manage their memory as you would any persistent pointer. A context?object will thus persist even after it is no longer needed, but it won’t actually leak,?provided you release it before you yourself (the managing object) go out of existence.

Here’s a complete example:

static id g_animcontext = nil;

- (void) animate {

? ? // set up context info pointer with memory management

? ? [g_animcontext release];

? ? g_animcontext = [NSDictionary dictionaryWithObject: @"object" forKey: @"key"];

? ? [g_animcontext retain];

? ? // prepare animation

? ? [UIView beginAnimations:@"shrinkImage" context:g_animcontext];

? ? [UIView setAnimationDelegate:self];

? ? [UIView setAnimationDidStopSelector:@selector(animationDidStop:finished:context:)];

? ? [imv setAlpha: 0];

? ? // request animation to start

? ? [UIView commitAnimations];

}

?

- (void) animationDidStop:(NSString*)anim

? ? ? ? ? ? ? ? ?? ??finished:(NSNumber *)f context:(void *)c {

? ? NSDictionary* d = c; // cast back to dictionary, use as desired

? ? // no memory management for context info here

? ? // ...

}

?

- (void)dealloc {

? ? [g_animcontext release];

? ? // ... other releases and so forth ...

? ? [super dealloc];

}

?

Considerations of this sort do not apply to parameters that are typed as objects. For?instance, when you call postNotificationName:object:userInfo:, the userInfo is typed?as an NSDictionary and is retained for you (and released after the notification is posted);?its memory management is not your concern.

?

Memory Management of C Struct Pointers

A value obtained through a C function that is a pointer to a struct (its type name will?usually ?end ?in “Ref”) is a kind of object, even though it isn’t a full-fledged Cocoa?Objective-C object, and it must be managed in much the same way as a Cocoa object. The rule here is that if you obtained such an object through a function whose name?contains the word Create or Copy, you are responsible for releasing it. In the case of a?Core Foundation object (its type name begins with CF), you’ll release it with the?CFRelease function; other object creation functions are paired with their own object?release functions.

An ?Objective-C ?object ?can ?be ?sent ?messages ?even ?if ?it ?is ?nil. ?But?CFRelease ?cannot ?take ?a NULL ?argument. Be ?sure ?that ?a pointer-to-struct variable is not NULL before releasing it.

The matter is not a complicated one; it’s much simpler than memory management of?Cocoa objects, and the documentation will usually give you a hint about your memory?management ?responsibilities. As an example, here (without further explanation) is?some actual code from one of my apps, strongly modeled on Apple’s own example?code, in which I set up a base pattern color space (for drawing with a pattern):

- (void) addPattern: (CGContextRef) context color: (CGColorRef) incolor {

? ? CGColorSpaceRef baseSpace;

? ? CGColorSpaceRef patternSpace;

? ? baseSpace = CGColorSpaceCreateDeviceRGB ();

? ? patternSpace = CGColorSpaceCreatePattern (baseSpace);

? ? CGContextSetFillColorSpace (context, patternSpace);

? ? CGColorSpaceRelease (patternSpace);

? ? CGColorSpaceRelease (baseSpace);

? ? // ...

}

Similarly, you can retain a Core Foundation object, if you are afraid that it might go?out of existence while you still need it, with the CFRetain function, and you are then,?once again, responsible for releasing it with the CFRelease function.

When a Core Foundation object type is toll-free bridged with a Cocoa object type, it?makes no difference whether you use Core Foundation memory management or Cocoa?memory management. For example, ?if you obtain a CFStringRef and assign ?it to an?NSString variable, sending release to it through the NSString variable is just as good?as calling CFRelease on it.?