how does "[self.selectedPhotos removeObject:photo];" work?

Discussion in 'iOS Programming' started by 1458279, Mar 9, 2016.

  1. 1458279, Mar 9, 2016
    Last edited by a moderator: Mar 9, 2016

    1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #1
    Just working on a Flickr tutorial project that uses a NSmutableArray and was thinking about one of the methods and how it worked.

    The array has photos that are loaded from Flickr and the method is removeObject:photo

    Does it go thru and compare some kind of meta data on the photo?
    Does it attach something to the photo?

    What's strange is the the code before that is:

    Code:
    NSString *searchTerm = self.searches[indexPath.section];
    FlickrPhoto *photo = self.searchResults[searchTerm][indexPath.row];
    I'm wondering if they know which photo to grab, why not just delete it based on position.

    But I'm just curious how they find a photo in an array using a photo as the search key.
     
  2. Mascots, Mar 9, 2016
    Last edited: Mar 9, 2016

    Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #2
    Because the object, FlickerPhoto, has its own unique identifier in the form of a memory address.
    Every initialized object does and an array is a more-or-less a collection of those identifiers, regardless of the data each one represents. Set a breakpoint on the last piece of code you posted, and when it breaks, the debugger will give you it's representation.

    Edit: Perhaps instead of memory address, pointer would be more appropriate (given the context).
     
  3. 1458279 thread starter Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #3
    Ok, so if the array element was removed, the memory the pointer pointed at wouldn't be release and you'd have a memory leak. So it does more than just remove the pointer, it has to go out and release the memory the photo had.

    I didn't think about the memory the photo had.
     
  4. Mascots, Mar 9, 2016
    Last edited: Mar 9, 2016

    Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #4
    Well no, the array doesn't release the memory itself. The underlying system, ARC, is managing that memory based on retain and release histories and the various other objects pointing to it.

    When you create an object, for simplicities sake, it has a retain count of +0 (really it's +1, but bear with me here). When you add it to an array, ARC increases the count by one, making it +1 to prevent the object from being overwritten.
    Whether you target the index in the array (removeObjectAtIndex: indexPath.row) or the key (removeObject: Photo), the items retain count is reduced back to +0 since the array no longer has knowledge (strong reference) of it in both cases. Note though, I'm simplifying the flow so you can see how arrays function to maintain their consistency.

    Arrays, to put it very very simply, are just key-value collections of pointers with the key being the memory footprint, pointer, or object identity... whichever you prefer to think of it as.
     
  5. PhoneyDeveloper, Mar 9, 2016
    Last edited: Mar 9, 2016

    PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #5
    This has nothing to do with Flikr.

    NSMutableArray removeObject:
    is a method that is part of Foundation. All it does is iterate over the contents of the array and if it finds the object it removes it from the array. It's just a convenience method. It has the same effect as removeObjectAtIndex: NSMutableArray retains objects when they are added and releases objects when they are removed. That's how it has to work.

    @Mascots. Arrays are not key-value collections. Arrays are ordered lists of objects. I'm also pretty sure your description of how ARC and NSMutableArrays interact is not correct. Almost certainly the array does explicitly retain and release the objects that are added and removed from it.

    If you care see:

    http://www.opensource.apple.com/source/CF/CF-476.14/CFArray.c
     
  6. Mascots, Mar 9, 2016
    Last edited: Mar 9, 2016

    Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #6
    That are indexed by their identities, though. Sorry, that wasn't meant be interpreted literally, more visually.
    --- Post Merged, Mar 9, 2016 ---
    The Array will retain and release objects, therefore changing their reference count (above), but the Array itself is not responsible for anything more than telling ARC if the object is locally being pointed to or not. The actual deconstruction of the object is out of the array's hands, which I believe he was implying was in the hands of the array by calling removeObject versus removeObjectAtIndex. It was my goal to show him, albeit roundabout, how it wasn't.
     
  7. 1458279 thread starter Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #7
    That's what I was thinking. If that's true, they could have just deleted the element and not have it go thru the process of searching.

    In fact, it seems wasteful to store one value in a string, then use the string to search for an object to delete.

    Why store it in a string instead of just passing it directly, then delete the object as soon as you know which one it is.

    Seems like a waste of time to store a string, find the object and then call for a search for something you've already found.
     
  8. Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #8
    I assume they did it like that to break it logically out, or it's the style the author coheres to out of habit.

    You just have a better eye for how to handle that situation. Have you tried to vary the procedure yourself?
     

Share This Page