Cells in addition to images

[lightandshadow68]

One thing I'd love to see is the ability to return cells in data source methods, in addition to UIImages, which are immutable and cannot update themselves. This would allow us to abstract logic about the content of each item out of the sidebar view and into the cell.

For example, a common idiom is to set a model property on a cell, which then sets up observers on the model's properties and updates the cell's subviews as appropriate when they change. The model object can asynchronously perform network or image processing operations, change it's image property to reflect these changes, then the cell can update the image independent of the sidebar view.

This is in contrast to putting all of this logic inside the sidebar view, then reloading the entire sidebar when the contents of an image changes.

To make this as simple as possible out of the box (and retain compatibility with existing code), you could check to see if the image variant of the data source method is implemented, create an image-only cell subclass behind the scenes and use it to populate the sidebar. Only users that needed cell functionality would implement the cell specific datasource method.

[bjhomer]

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.

[lightandshadow68]

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.