0

I am doing a Apple Developer Tutorial and I have a couple basic questions about the lines of code at the bottom:

  1. Neither one of these lines of code alloc and init the objects that they create? Is this because the objects are assigned values at their creation?

  2. The dequeueReusableCellWithIdentifier method - Is the only way that this method returns nil is if there is no cell object with the same name as the cell identifier parameter? What if there was no cell in the pool that it could reuse, does it then create one or return nil? The documentation states that the method returns - A UITableViewCell object with the associated identifier or nil if no such object exists in the reusable-cell queue.

Thanks ahead of time for the help

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

BirdSighting *sightingAtIndex = [self.dataController objectInListAtIndex:indexPath.row];
David Hall
  • 99
  • 7
  • Search around a little. http://stackoverflow.com/questions/3552343/uitableview-dequeuereusablecellwithidentifier-theory http://stackoverflow.com/questions/10759153/why-does-tableview-dequeuereusablecellwithidentifiercellidentifier-return-null – Anil Dec 13 '12 at 09:27
  • @Anil neither of these articles answered my questions. – David Hall Dec 13 '12 at 18:29
  • 1
    The lines of code you posted don't actually **create** anything; they get references to things that have been created elsewhere. – Phillip Mills Dec 13 '12 at 19:00
  • @Phillip Mills - I understand that they are just pointers to objects/instances. However I did not need to alloc init them. Why? – David Hall Dec 13 '12 at 19:09
  • Because something else already did that and is just providing you with access. – Phillip Mills Dec 13 '12 at 19:22
  • @PhillipMills Even though they are never referenced/used nowhere else before this in my code? Is this code that is happening below the surface that I did not have to expilictly state? Why these pointers? What made them different? – David Hall Dec 13 '12 at 19:28
  • If you registered a class/nib with your table view then it creates the cell for you. If not, then you create it when `dequeueReusableCellWithIdentifier:` returns `nil`. Either way, when it returns non-nil, that's an object that was created at some point other than the one where your program is at that moment. (The `self.dataController` one isn't something I recognize but the same logic must apply...either its list is being pre-populated by something you do earlier or it's generating things and giving them to you as you ask.) – Phillip Mills Dec 13 '12 at 19:41
  • @PhillipMills That is pretty much the answer I was looking for because the dataController was created earlier in the code. Can you copy/paste your comment for the answer so I can give you credit. Thanks for sticking with me. – David Hall Dec 13 '12 at 19:56

1 Answers1

1

From the comments....

The lines of code you posted don't actually create anything; they get references to things that have been created elsewhere. Something else -- either your code or framework code -- already instantiated them with alloc/init and is now giving you access.

In the table view example, if you registered a class/nib with your table view then it creates the cell for you. If not, then you create it when dequeueReusableCellWithIdentifier: returns nil. Either way, when it returns non-nil, that's an object that was created at some point other than the one where your program is at that moment.

(The self.dataController one isn't something I recognize but the same logic must apply...either its list is being pre-populated by something you do earlier or it's generating things and giving them to you as you ask.)

Phillip Mills
  • 30,888
  • 4
  • 42
  • 57