IPhone Memory Management Special Cases

In this blog I would be discussing Special cases for memory management that one should consider while programming on IPhone.

Handling of NSDictionary and NSArray

First thing what you should think is why these are special? why we should treat them in different way?

When you copy/retain an array/dictionary(for now on i will say them Arrdict) to take its owner ship, it make you owner of that Arrdict. But what about its objects? Do you own them? Answer is NO. They can get dereference at any time, even you still need them. So What is the solution? Simple you should also take their(objects) owner ship.

For this you need a for loop which traverse through Arrdict. Get each object and copy them to other or retain them. Then put them in new Arrdict or retain old one. This is traditional way to do this. But fortunately, we(folio3) Extend Arrdict class and expose some new function to developers. Now what you have to do is to add PSArrayExtension and PSDictionaryExtension classes in your projects. Now you will find a new function copyAll in Arrdict. What it will do it will copy Arrdict to new Arrdict and now your are the owner of this Arrdict and its objects.

NSArray *myArray = [oldArray copyAll];

Its simple now isn’t it? But now, since you are owner of all objects, its your responsibility to release them. You also have a function for this purpose in Extension classes, releaseAll. This function will release all objects of array(this function will not release array itself).

[myArray releaseAll];

[myArray release];

Handling of NIB files

A method that creates an object for someone else is a typical user of the autorelease functionality. Another user of autorelease is a NIB file, or actually the method that load it. A NIB file contains a graph of objects where most objects are connected to each other using outlets. When the loader method rebuilds this object graph in memory, using the NIB file as a blueprint, it creates all objects with a reference count of 1 and then autorelease them.

When the connections between the objects are re-established, the loader method calls setter methods of the objects, which should retain the object reference if they want to prevent the newly loaded object from being deallocated. Ownership is transferred to these objects, meaning that the objects also are responsible for releasing the references in their ‘dealloc’ method. Setter methods for outlets are normally synthesized using the @property/@synthesize mechanism of Objective C.

@property (nonatomic, retain) IBOutlet someClass *someOutlet;

The ‘retain’ keyword of the property declaration will ensure that the corresponding setter method created by the @synthesize keyword will retain the reference passed to it.

However, there are also top-level objects in the file that have no natural owner. If you want to keep those objects around, which you normally do, you have to manually retain them (and then later manually releasing them). But how do you get hold of the references to them if they have no “owners”? Well, they do actually get a temporary owner during the loading process; references to all the top-level objects are stored in an array, returned by the ‘loadNibNamed:owner:options’ method.

As a simple alternative to iterating through the array and retain all the objects in it individually you could retain the array itself instead (and then later release it). This works since it prevents the array from being (auto) released and deallocated – if it was it would release all the references stored in it (decreasing the reference count to zero) and thus force all the objects in the array to be deallocated.

NSArray *nibArray = [[NSBundle mainBundle] loadNibNamed:@”Nib1″ owner:self options:nil];

if ( nibArray == nil ) {

NSLog(@”loadNibNamed failed”);

return;

}

[nibArray retain];

NIB files with “unconnected” top-level objects aren’t that common since it would be useless to define a lot of objects in a NIB that no one uses. Much more common is that the top-level objects are connected to outlets in the “File’s owner” object. When that is the case you don’t have to worry about implicitly retaining the objects since they will be retained by the setter methods in the “File’s owner”.


Advertisements

One thought on “IPhone Memory Management Special Cases

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s