Cells in addition to images about hsimagesidebarview HOT 2 OPEN

One concern with this idea is that HSImageSidebarView reuses cells, much like UITableView does. As such, if you were to scroll a cell off the screen, its model would now be referencing a cell being used in an entirely different location. I don't think making cells retain model objects directly is a good idea for that reason. Can you think of a way this would work when the cells are being reused?

I considered allowing users to provide a UIView instead of a UIImage, but it was precisely these kinds of concerns that led me to take the image route.

I agree, though, that it's annoying to have to reload the whole sidebar just to update one image. It would make a lot of sense to add a -reloadRowAtIndex: API.

from hsimagesidebarview.

I use this idiom often with table views. The cell is reassigned a new model object when it is reused in the data source method.

For example...

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath 
{    
    CellSubclass *cell = [tableView dequeueReusableCellWithIdentifier:kCellSubclassIdentifier];

    if (cell == nil)
        cell = [[[CellSubclass alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier] autorelease]

    cell.model = (ModelClass*) [self.fetchedResultsController objectAtIndexPath:indexPath];

    return cell;
}

Since the cell observes it's model object property, in addition to the individual properties on the model itself, it is notified when both the cell is assigned a new model object and when observed properties of it's current model changes as well. The same notification handler can be used to update the cell's subview as appropriate in either case.

This way, much of the cell specific logic is moved to the cell subclass. Regardless of how many properties the cell and model have or how the cell's image is generated, the cellForRowAtIndexPath method remains a single property assignment.

from hsimagesidebarview.