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

[1458279]

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:

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.

 

[Mascots]

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).

 

[1458279]

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.

 

[Mascots]

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.

 

[PhoneyDeveloper]

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

 

[Mascots]

Arrays are not key-value collections. Arrays are an ordered list of objects.

That are indexed by their identities, though. Sorry, that wasn't meant be interpreted literally, more visually.
[doublepost=1457549157][/doublepost]

Almost certainly the array does explicitly retain and release the objects that are added and removed from it.

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.

 

[1458279]

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

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.

 

[Mascots]

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?