iOS ARC - How many of you?

[larswik]

Just wondering how may of you are using ARC as opposed to releasing your own objects? I only ask because I downloaded the new Xcode and started a new project the other night and got an error when I tried to release an object, ARC defaults to on.

It is so hard not to want to release my objects, it feels so wrong. So do most of the coding vets here still release objevts and shut off ARC?

 

[admanimal]

There is no reason to not use ARC.

 

[larswik]

Ok, this may end up more of a question then a survey. I was copying some code from another project and found that I relied on the fact that I released objects. Here is some old code, If I had another client to add to the property list I would check to see if the object existed. If so, I would then add it to the array and then release it at the end, if not I would just write out the array to the property list. But since ARC controls the release of objects I cant use that trick anymore, unless there is a way I can force ARC to release the object?

- (void)writePlist{   

    NSString *aNumber = [NSString stringWithFormat:@"%d", clientContentArray.count];
    if (clientInformation) {
        [clientContentArray addObject:clientInformation]; //add dict to array
    }
    [clientContentArray replaceObjectAtIndex:0 withObject: aNumber];

    [clientContentArray writeToFile:[self dataFilePath] atomically:YES]; //save to plist
    [COLOR="Red"][clientInformation release];[/COLOR]
    
}

 

[admanimal]

Releasing clientInformation has absolutely no bearing on whether or not the contents of your if statement is executed.

Do you know the answer to these questions:

1. What value(s) of clientInformation make your if statement NOT execute?

2. What is the value of clientInformation after you release it?

 

[chown33]

Assuming clientInformation is an instance variable or a static variable, you have a memory bug. ARC has nothing to do with this. You have a bug regardless of ARC.

If you were to set clientInformation to nil after the release, you would fix this bug. You might cause another bug somewhere else, depending on what else wants to use the value of clientInformation. Again, nil'ing clientInformation after release is unrelated to ARC.

The memory bug is very simple: you are keeping a reference to an object after releasing that object. The reference is being kept in the variable clientInformation.

If clientInformation has a corresponding property, then you have another bug: you're referencing a property as an ivar. Assuming the property is retain or copy, you could fix this bug simply by always referring to the property. Then you don't release anything, you simply set the property to nil.

If the above is confusing, or you don't see why the bugs occur, you might be better off using ARC. For one thing, it will identify errors like this and point them out to you. You will still need to understand ARC, but if object ownership is an ongoing problem, then that might be a better alternative.

By the way, there's no such thing as "check to see if the object exists". You can't. All you can do is check if a variable is nil or not. That's not at all the same thing, and is the cause of the bug. You have an invalid (released) object reference still being stored in your variable.

 

[ArtOfWarfare]

I was reluctant to use ARC initially, but with my latest project I'm diving into ARC and storyboards. I have to say, both features are cake to learn (if you can find a tutorial that actually explains it; I like the ones on this website: http://www.raywenderlich.com/tutorials )

I wasn't any good at the old memory management system after 4 years of on again-off again programming, so I think making the transaction was for the better.

 

[firewood]

Until iOS 5 grows to be around 80% of the customer base (less or more for some devs), being able to develop and continue supporting Obj C code with manual memory management is still important to many developers.

That's still at least a few more months away.

Also, for existing code that has no memory bugs, the rule for a lot of devs is: "If it ain't broke, don't fix it!"

 

[lloyddean]

No offense but …, many developers don't know when their code is broken so it never gets fixed.

 

[admanimal]

Also, for existing code that has no memory bugs, the rule for a lot of devs is: "If it ain't broke, don't fix it!"

If you can do something that leaves you with less code that is virtually guaranteed to have no memory bugs, then why not?

 

[1458279]

Until iOS 5 grows to be around 80% of the customer base (less or more for some devs), being able to develop and continue supporting Obj C code with manual memory management is still important to many developers.

That's still at least a few more months away.

Also, for existing code that has no memory bugs, the rule for a lot of devs is: "If it ain't broke, don't fix it!"

So using ARC makes your app iOS 5 only?

 

[larswik]

Huh, I guess I am off from what I was thinking. So after releasing an object I need to set the pointer to nil if I am going to call it again? I thought once I release the object everything associated with it goes, like the pointer too. But I guess since the pointer is a variable I need to release (nil) it as well.

clientInformation is an NSMutableArray. WHen the user presses a button it calls a [self itemsToSave]; which collects the data from UITextFields and assigns NSString. After this it calls the method to write it to the property list and then push a new viewController.

- (void)itemsToSave{
     clientInformation = [[NSMutableDictionary alloc]init];
    
    NSString *backgroundNumber = [[NSString alloc] initWithFormat: @"%d", backDropNumber];
    
    [clientInformation setValue:theClientName forKey:@"client"]; //Bellow gathers the info and adds it to the MutableDict
    [clientInformation setValue:theJobName forKey:@"job"];
    [clientInformation setValue:nameCombind forKey:@"tableViewID"];
    [clientInformation setValue:backgroundNumber forKey:@"backDropNumber"];
    [clientInformation setValue:@"-" forKey:@"amount"];
    [clientInformation setValue:@"-" forKey:@"note"];
    [clientInformation setValue:@"-" forKey:@"phone"];
    [clientInformation setValue:@"-" forKey:@"contact"];
    [clientInformation setValue:@"-" forKey:@"invoice"];
    
    [backgroundNumber release];

}

So using the

if (clientInformation){
}

checks to see if the pointer is valid or not. If the pointer no longer exists it returns a FALSE. So even if I release my Object but I do not set my pointer to nil, it will return a TRUE and execute the if statement?

I don't see a reason for a pointer to hang around once you release an object? It seems smarter to have a pointer variable automatically be set to nil upon the release of the Object.

So if I do not set the pointer variable to nil and I create a new object with the same pointer variable name, that's bad. So now I have 2 pointer variables with the same name and only one points to a valid object. From my Pascal class 2 variables can not have the same name.

Hope I got that right now?

Thanks!

 

[silverhand31]

I just start to learn Xcode only with ARC, I thought after the method, it auto release it self, so we do not need to [sdfksfjs release] anymore?

 

[ArtOfWarfare]

So using ARC makes your app iOS 5 only?

I believe this is incorrect. Some versions of iOS 4 support ARC mostly... The one part of it iOS does not support is weak-links or whatever it's called.

 

[admanimal]

If the pointer no longer exists it returns a FALSE. So even if I release my Object but I do not set my pointer to nil, it will return a TRUE and execute the if statement?

If the pointer is nil, the conditional will be false. The second part of your statement is correct.

So if I do not set the pointer variable to nil and I create a new object with the same pointer variable name, that's bad. So now I have 2 pointer variables with the same name and only one points to a valid object. From my Pascal class 2 variables can not have the same name.

As long as you released the original object that the pointer variable pointed to, there is nothing wrong with reusing the same variable again.

So this is perfectly fine:

NSSomething *myVar = [[NSSomething alloc] init];
// do something with myVar
[myVar release];
myVar = [[NSSomething alloc] init];
// do something with the new object referred to by myVar
[myVar release];

 

[larswik]

I'm responding from my iPhone so response is short. I can see how I could alloc/init and release and then aloc/init release again. But for arguments sake let's say I alloc/init the same object in the same method. Under ARC will it release the first object before it create the second one? Before you could release it yourself, but now it takes care of it?

 

[firewood]

If you can do something that leaves you with less code that is virtually guaranteed to have no memory bugs, then why not?

If you've been programming long enough, you've heard that before. And software still has bugs.

The worst is "improving" a few lines of code with a typo so obvious that no one sees it.

 

[admanimal]

If you've been programming long enough, you've heard that before. And software still has bugs.

The worst is "improving" a few lines of code with a typo so obvious that no one sees it.

Sure, practically speaking there is a certain risk/reward element to any sort of refactoring when the code otherwise appears to work.

I'm responding from my iPhone so response is short. I can see how I could alloc/init and release and then aloc/init release again. But for arguments sake let's say I alloc/init the same object in the same method. Under ARC will it release the first object before it create the second one? Before you could release it yourself, but now it takes care of it?

Using ARC, there are no leaks in this code:

NSSomething *myVar = [[NSSomething alloc] init];
myVar = [[NSSomething alloc] init];
myVar = [[NSSomething alloc] init];
myVar = [[NSSomething alloc] init];

 

[1458279]

I believe this is incorrect. Some versions of iOS 4 support ARC mostly... The one part of it iOS does not support is weak-links or whatever it's called.

So in order to properly test and support 3.x and above, we now need test devices for iOS 5 and less than iOS 5. Not to mention 2 code sets. And _IF_ we create a seperate product for iPad so that it'll be different enough to be considered a seperate product so that we can have a different price vs iPhone/iPod... we now have even more code to maintain.

Then factor in that Apple doesn't let you backgrade your device OS, so we can't easily upgrade for testing then backgrade for testing on older OS's

This seems like a bit of an expensive hassle.

 

[admanimal]

This seems like a bit of an expensive hassle.

A couple thousand dollar investment over the course of a few years as devices get updated is a small price to pay for a serious developer. I'd rather spend $150 on an older model iPod Touch than have to upgrade and downgrade devices constantly.

 

[ArtOfWarfare]

Personally, I try to support the current version and the version from a year ago. I only use the simulator to test old versions; it's really easy to up and downgrade the simulator.

 

[dejo]

So in order to properly test and support 3.x and above, we now need test devices for iOS 5 and less than iOS 5. Not to mention 2 code sets. And _IF_ we create a seperate product for iPad so that it'll be different enough to be considered a seperate product so that we can have a different price vs iPhone/iPod... we now have even more code to maintain.

Then factor in that Apple doesn't let you backgrade your device OS, so we can't easily upgrade for testing then backgrade for testing on older OS's

This seems like a bit of an expensive hassle.

Welcome to the world of software development. These issues are hardly unique to iOS programming. Rather than getting irritated by them, you need to come up with strategies to effectively deal with them.

And I'm curious. What do you mean when you say you need "2 code sets"?

 

[1458279]

Welcome to the world of software development. These issues are hardly unique to iOS programming. Rather than getting irritated by them, you need to come up with strategies to effectively deal with them.

And I'm curious. What do you mean when you say you need "2 code sets"?

First off, I was thinking (without doing research) that the ARC would be built into the compiler. I was thinking that we do ref counting manually, now the compiler would take care of that for us. I wouldn't have guessed that it requires iOS5 to do ARC. I'm still haven't upgraded or done the research on this.

The issue of 2 code sets is about iPad vs iPhone. The markets tend to be different, iPad seems to command a higher price. Some app devs might want to take advantage of that. Apple doesn't seem to allow you to simple convert an iPhone app to iPad and call it a seperate app. They are rejecting apps like this and wanting you to make the app universial.

There's discussion about the good/bad about this. The sale on iPad don't count toward iPhone stats if it's a seperate app. Universial apps have one code set, but don't allow you to have a different price for iPad apps.

So in order to cover all the bases, you might have a:
<iOS5 version
iOS5 version
for both iPhone and iPad.

Note that there are some advantages to making an app universial, but that's up to the dev.

I like the idea of using the simulators to test different versions, that might be the answer. My test device can handle iOS4 or 5 so I might keep my eye out for a used one to test older versions.

 

[Sydde]

I'm responding from my iPhone so response is short. I can see how I could alloc/init and release and then aloc/init release again. But for arguments sake let's say I alloc/init the same object in the same method. Under ARC will it release the first object before it create the second one? Before you could release it yourself, but now it takes care of it?

Under ARC, any object pointers on the stack ("automatic" temporary variables that only exist within the scope of a method) are set to nil (for you) at the beginning of the method. Then, the compiler sends -release to a pointer immediately before each assignment statement. This is aided by the fact that nil can receive messages (unlike, say, with Java).

What I am not clear on is how ivars with no @property declaration would be handled. From what I read, it appears that the default is __strong (retained).

 

[dejo]

First off, I was thinking (without doing research) that the ARC would be built into the compiler.

It is. It's part of Xcode.

I wouldn't have guessed that it requires iOS5 to do ARC.

It doesn't. It just requires Xcode 4.2. You can create an iOS 4.x app and still use ARC. You can't however use it with iOS 3.x. Make sure you've read the Transitioning to ARC Release Notes guide.

 

[iRCL]

I haven't switched to ARC, I need to invest the (probably small) amount of time to do that. I definitely have the hang of memory management so it's actually difficult to break the habits, but it's the way to do things going forward and it is as good or better than manually handling the management.

I have switched to Storyboards and I really really like it.