ARC - How many of you?

Discussion in 'iOS Programming' started by larswik, Dec 17, 2011.

  1. larswik macrumors 68000

    Joined:
    Sep 8, 2006
    #1
    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?
     
  2. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
  3. larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #3
    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?

    Code:
    - (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]
        
    }
     
  4. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #4
    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?
     
  5. chown33, Dec 17, 2011
    Last edited: Dec 17, 2011

    chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #5
    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.
     
  6. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #6
    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.
     
  7. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #7
    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!"
     
  8. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #8
    No offense but …, many developers don't know when their code is broken so it never gets fixed.
     
  9. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #9
    If you can do something that leaves you with less code that is virtually guaranteed to have no memory bugs, then why not?
     
  10. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #10
    So using ARC makes your app iOS 5 only?
     
  11. larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #11
    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.
    Code:
    - (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
    Code:
    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!
     
  12. silverhand31 macrumors member

    Joined:
    Oct 29, 2011
    #12
    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?
     
  13. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #13
    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.
     
  14. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #14
    If the pointer is nil, the conditional will be false. The second part of your statement is correct.

    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:

    Code:
    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];
    
     
  15. larswik thread starter macrumors 68000

    Joined:
    Sep 8, 2006
    #15
    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?
     
  16. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #16
    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.
     
  17. admanimal, Dec 18, 2011
    Last edited: Dec 18, 2011

    admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #17
    Sure, practically speaking there is a certain risk/reward element to any sort of refactoring when the code otherwise appears to work.

    Using ARC, there are no leaks in this code:

    Code:
    NSSomething *myVar = [[NSSomething alloc] init];
    myVar = [[NSSomething alloc] init];
    myVar = [[NSSomething alloc] init];
    myVar = [[NSSomething alloc] init];
    
     
  18. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #18
    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.:(
     
  19. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #19
    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.
     
  20. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #20
    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.
     
  21. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #21
    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"?
     
  22. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #22
    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.
     
  23. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #23
    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).
     
  24. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #24
    It is. It's part of Xcode.

    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.
     
  25. iRCL macrumors 6502

    Joined:
    Nov 2, 2011
    #25
    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.
     

Share This Page