Tables views are a very powerful and ubiquitous in iPhone and iPad, and in order to make them perfect, it is important to know a little bit about the structure of the cell.
The cell is the very basic element of a table view, and it is composed by a number of elements. Let’s take a look:
Cell The cell itself, it is a subclass of
UIView, and is draw at the very bottom of the view stack. Remember when before the introduction of OS 3.0 whenever you tried to change the background color of a grouped cell, the round corners disappeared? Well, technically, that’s was the right way to change the background color, because the actual cell was not the rounded rectangle, but the rectangle that contains it.
Background View if it exist, ie, if you need to customize the looks of the cell, a background view is drawn above the cell.
Content View This is the place where you place all your content for the cell. It is just a container, it will no contribute visually to the display of the cell
Cell Paylod These can be any UIView descendant, from
Editing Mode Controls and Accessory When the table enters into Edit Mode, the OS draws above the Background View the appropriate controllers, and resize accordingly the Content View
Selecting a Cell
When the cell is selected, the OS insert an
UIView with a selected background, right above the Background View (if present). If no custom view provided, the OS insert the classic blue gradient.
All of these views should be opaque, views that are not opaque are much more expensive to render. Then, what’s happen to the payload views when the row is selected?
When the system needs to mark a cell as selected, it will call
-setHighlighted:animated: method of the cell with the
highlighted parameter set to
YES. The default implementation of the method will iterate all the
UIImageView of the payload, saving the
backgroundColor properties and checking if each of them has either the
highlightedTextColor (in the case of
UILabel) or the
highlightedImage (in the case of the
UIImageView). The system will also set the
opaque property of each element of the payload to
NO and the
backgroundColor property to
On deselection, the system will, again, calls
-setHighlighted:animated:, this time with the parameter
highlighted set to
selectedBackgroundView will start to fade out. Right in the midpoint of that animation, the system will iterate all the views on the payload resetting the highlighted properties. The text color of the
UILabel is set to the normal textColor, and the normal
UIImage of the
UIImageView is repositioned. At the end of the animation, the system will iterate once again the payload views, and set the
opaque property to
YES and the
backgroundColor to the normal color.
The way the cell is designed may impact in the performance to the table view. For instance, a cell that is composed with many subviews is expensive, so let’s review the available options.
Cell Composition with subviews This is the easiest way to build a Cell. You can use Interface Builder to compose the cell, and if you set the appropriate mask for each of the subviews, the cell will automatically adapt to changes in size (for instance, when device orientation is changed).
Cell Composition with a unique
For very complex cells, you can build a
UIView, and draw all the content inside the
-drawRect: method. This is much more cheaper and will enhance greatly the scrolling performance. Actually, regardless of the complexity of the cell, it is almost constant speed scrolling. Most of the cost of scrolling is re-compositing as things moves up and down the screen, not the cost of doing the first draw as the cell enters the screen.
On the other hand, it is not easy to maintain, you will have to tweak you
-drawRect: for even the smallest changes on the view. You have to be aware of the device orientation, and change in code the size and position of the different elements when the device is rotated.