There aren't too many cases where you HAVE to autorelease. In fact, due to the limited resources available on the iPhone, you want to avoid autoreleasing as much as possible.
Generally speaking, your variables should have a 3-step life.
As long as you do the release before you hit the last } in your method (or loop, depends on where you created it), you should be fine.
Other than that, I'd say that the rest of what you said is generally correct. You would need to post some specific examples of where you are crashing in order to get better help.
Edit:
Option 1 is correct (well, that may not be the best initialization example, since the string really doesn't have a value, but you get the idea). Option 2 is a leak.
IMO, do yourself a favor and avoid dot-syntax. Ex:
One of the things that I have found is that on the device it may crash because of a low-memory warning. You do not get these crashes in the simulator because your computer lets programs use more than 20MBs of RAM. One of the ways to avoid these crashes is to respond to the didReceiveMemoryWarning method. In this method you should release anything that you are not using so that the program doesn't crash. IMPORTANT: If you do use this method, do NOT use the normal "release" command on whatever you need to release! This can lead to it crashing because of it releasing an object more than once. The memory warning method can be called more than once in an app's lifecycle. Releasing an object that has already been released will crash your app. To combat this, instead of using [myObject release]; use myObject = nil;. This is very important and can be a pain to debug later on (I know the hard way).
Hope this helps! If there was anything that was not clear, feel free to ask and I will try to clarify.
Here is one of the example where im trying to read a file from my sandbox directory, when i try to release pathToDefaultPlist and documentsDirectory, it crashes. (trying to release all)
whats the correct release in this situation.
One of the things that I have found is that on the device it may crash because of a low-memory warning. You do not get these crashes in the simulator because your computer lets programs use more than 20MBs of RAM. One of the ways to avoid these crashes is to respond to the didReceiveMemoryWarning method. In this method you should release anything that you are not using so that the program doesn't crash. IMPORTANT: If you do use this method, do NOT use the normal "release" command on whatever you need to release! This can lead to it crashing because of it releasing an object more than once. The memory warning method can be called more than once in an app's lifecycle. Releasing an object that has already been released will crash your app. To combat this, instead of using [myObject release]; use myObject = nil;. This is very important and can be a pain to debug later on (I know the hard way).
Hope this helps! If there was anything that was not clear, feel free to ask and I will try to clarify.
so what you do is set everything to nil inside the mothods?
and in didReceiveMemoryWarning
do the following code
Only release it if it was made with alloc and init. If its just like NSString *mySTR = [NSString stringWithFormat:@"Hello World %f", myFloat]; Then you do NOT need to release it and if you do then it WILL crash.
Releasing an object that has already been released will crash your app. To combat this, instead of using [myObject release]; use myObject = nil;
I'm 99% certain this is a leak. Assigning nil is not the same thing as releasing. Take the combo approach:
Code:
[myObject release], myObject = nil;
So, you honor the rules of memory management by releasing the object, and you avoid crashes later by assigning to nil, since sending a message to nil doesn't actually do anything.
Now, if you're talking about a property, that's different. In that case:
Code:
[self setMyProperty: nil];
...is perfectly acceptable, since the property will release the old value.
Only release it if it was made with alloc and init. If its just like NSString *mySTR = [NSString stringWithFormat:@"Hello World %f", myFloat]; Then you do NOT need to release it and if you do then it WILL crash.
True, but this creates an auto-released object. See my first post in this thread.
I'm 99% certain this is a leak. Assigning nil is not the same thing as releasing. Take the combo approach:
Code:
[myObject release], myObject = nil;
So, you honor the rules of memory management by releasing the object, and you avoid crashes later by assigning to nil, since sending a message to nil doesn't actually do anything.
Now, if you're talking about a property, that's different. In that case:
Code:
[self setMyProperty: nil];
...is perfectly acceptable, since the property will release the old value.
Ok that makes sense. So in the didReceiveMemoryWarning method, you should just do if(myObject!=nil) [myObject release];
That way it won't release something more than once but it will actually get released.
Only release it if it was made with alloc and init. If its just like NSString *mySTR = [NSString stringWithFormat:@"Hello World %f", myFloat]; Then you do NOT need to release it and if you do then it WILL crash.
I see.
so these i dont need to release any of these?!
Here is one of the example where im trying to read a file from my sandbox directory, when i try to release pathToDefaultPlist and documentsDirectory, it crashes. (trying to release all)
whats the correct release in this situation.
when i release shoppingkartImage, it crashes.
do i need to release uiimage?
shoppingKartImage is an autoreleased object, therefore you should not release it. However, as stated previously, you want to avoid autoreleased objects. If it is a small image, and for a nav button I assume it is, I probably wouldn't worry too much about it. If it becomes an issue, go more of an alloc/init route, perhaps with initWithContentsOfFile:, and then manually release.
Quote:
Originally Posted by svveet
and do we release NSUInteger and Int object?
Those are primitives, not objects. Therefore, do not release. A decent rule of thumb is if there is a * involved - ex: NSString *myString, UIImage *myImage - it is an object, and if you alloc/init'ed it, you need to release it. ints, floats, doubles, CGFloats, etc don't have the *, are not objects, so you don't.
forgot to put in that line at the end, i was trying to release documentsDirectory before. i guess i dont need to release that now.
Quote:
Originally Posted by BrianSlick
Those are primitives, not objects. Therefore, do not release. A decent rule of thumb is if there is a * involved - ex: NSString *myString, UIImage *myImage - it is an object, and if you alloc/init'ed it, you need to release it. ints, floats, doubles, CGFloats, etc don't have the *, are not objects, so you don't.
Ok that makes sense. So in the didReceiveMemoryWarning method, you should just do if(myObject!=nil) [myObject release];
That way it won't release something more than once but it will actually get released.
No. If you are in the memory warning method, I'm assuming we're dealing with properties here. In which case, do exactly what I said before:
Code:
[self setMyObject: nil];
The property will release the old value, so you're good there. The property is now nil, so by the time you get to dealloc, and the release message is sent again, it is sending to nil, which doesn't have any effect.
Besides, you shouldn't automatically clear out all of your properties in this method. If you have things you don't need, sure, clear them out. But if the program is still actively using them, then clearing out the properties could cause a whole different set of problems. For example, if you have retained any detail view controllers for repeated use, this would be a good place to clear them out. But don't clear out the array that is driving your table view. Do save your data and brace for impact, however.
Im trying to call a function inside the same class, for example:
Code:
// i want to call functionA to do stuff
[self functionA];
it gives me an warning saying "Warning, may not respond to functionA".
it doesnt stop me from building the app, but one of my other friend told me that i shouldnt have this kind of warning at all.
Im trying to call a function inside the same class, for example:
Code:
// i want to call functionA to do stuff
[self functionA];
it gives me an warning saying "Warning, may not respond to functionA".
it doesnt stop me from building the app, but one of my other friend told me that i shouldnt have this kind of warning at all.
is there a better way to code this?
You need to declare it in your header file. Ex:
Code:
- (void)functionA;
And your friend is correct. Pretend that warnings are actually errors, and fix them.
Looks ok to me, but may I suggest a little reorganization that might help to keeps things straight. Remove red, add blue.
Code:
int stringlength = [self.trackFileName length];
NSString *trimmedFileName = [trackFileName substringToIndex:stringlength-6];
// get the location of application sandbox
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *finalFileName = [[NSString alloc] initWithFormat:@"%@.plist", trimmedFileName];
NSString *pathToPlist = [documentsDirectory stringByAppendingPathComponent:finalFileName];
self.pathToCurrentTrackPlist = pathToPlist; // Avoid dot-syntax
[self setPathToCurrentTrackPlist: pathToPlist];
// You no longer have a need for pathToPlist. You have populated the property; use it.
// Also, you are now done with finalFileName, so release it here. Don't wait until later.
[finalFileName release], finalFileName = nil;
// Check for data in Documents directory. Copy default appData.plist to Documents if not found.
NSFileManager *fileManager = [NSFileManager defaultManager];
NSError *error;
if ([fileManager fileExistsAtPath:pathToPlist] == NO)
if ([fileManager fileExistsAtPath:[self pathToCurrentTrackPlist]] == NO)
{
NSString *pathToDefaultPlist = [[NSBundle mainBundle] pathForResource:trimmedFileName ofType:@"plist"];
if ([fileManager copyItemAtPath:pathToDefaultPlist toPath:pathToPlist error:&error] == NO)
if ([fileManager copyItemAtPath:pathToDefaultPlist toPath:[self pathToCurrentTrackPlist] error:&error] == NO)
{
NSAssert1(0, @"Failed to copy data with error message '%@'.", [error localizedDescription]);
}
}
// store the track dictionary into trackdictionary
NSMutableDictionary *trackDictionary = [[NSMutableDictionary alloc] initWithContentsOfFile:pathToPlist];
NSMutableDictionary *trackDictionary = [[NSMutableDictionary alloc] initWithContentsOfFile:[self pathToCurrentTrackPlist]];
[self setTrackDict:trackDictionary];
//[trackDictionary release];
[finalFileName release];
This shouldn't be a crash, but if it really and truly is crashing here with the release, then we probably need to take a look at your property declaration for trackDict. Or, I think that initWithContentsOfFile might be intended for an NSArray, not sure. If so, you might need to do something like setArray:.
This shouldn't be a crash, but if it really and truly is crashing here with the release, then we probably need to take a look at your property declaration for trackDict. Or, I think that initWithContentsOfFile might be intended for an NSArray, not sure. If so, you might need to do something like setArray:.
Thanks for the fixing up, now i have learned more about cleaning up.
Here is the property list of my trackDict and yes, it still cause crash, only if i dont release the trackDict, it will be fine. but i know thats wrong.
I'm going to say that's the problem. trackName is autoreleased.
By the way, comment "when i click "back button" on the navigationcontroller" would have been a useful piece of information before. That's most likely when the autorelease pool is getting drained. I thought you meant you were literally crashing at the aforementioned line of code.
Memory Management / Releasing Objects
Linear Mode
