iOS Components and Frameworks: Understanding the Advanced Features of the iOS SDK (2014)

Chapter 20. Collection Views

Collection views were added in iOS 6 to provide a convenient new way to display scrollable cell-based information in a view with arbitrary layouts. Consider the iOS 6 version of Photos.app, which presents thumbnails of images in a scrollable grid. Before iOS 6, implementing a grid view would require setting up a table view with logic to calculate which thumbnail (or “cell”) should go in each position in each table row, or would require custom logic to place thumbnails in a scroll view and manage them all as scrolling occurs. Both approaches are challenging, time-consuming, and error prone to implement. Collection views address this situation by providing a cell management architecture that is very similar to row management in a table view, while abstracting the layout of cells.

There is a default collection view layout called flow layout, which can be used to quickly and easily implement many common grid-style layouts for both horizontal and vertical scrolling. Custom layouts can be created to implement specialized grids or any nongrid layout that can be visualized and calculated at runtime.

Collection views can be organized into sections, with section header and section footer views that depend on section data. In addition, decoration views not related to content data can be specified to enhance the look of the collection view.

Last but not least, collection views support lots of types of animation, including custom states while cells are scrolling, animations for inserting or removing cells, and transitioning between layouts.

The Sample App

The sample app for this chapter is called PhotoGallery. The app demonstrates presenting the user’s photo library in a few different implementations of a collection view:

The first implementation is a basic collection view of thumbnails, organized by album, that can be scrolled vertically. It has section headers displaying album names, and can be created with a minimum of custom code.

The second implementation uses a custom subclass of the flow layout so that it can display decoration views.

The third implementation uses a custom layout to present items in a nongrid layout, and includes the capability to change to another layout with a pinch gesture.

Introducing Collection Views

A collection view needs a few different classes in order to work. The base class is called UICollectionView and is a subclass of UIScrollView. It will manage the presentation of cells provided by the datasource (which can be any class implementing theUICollectionViewDataSource protocol), according to the layout referenced by the collection view, which will be an instance of UICollectionViewLayout. A delegate conforming to the UICollectionViewDelegate protocol can be specified to manage selection and highlighting of cells.

The class that conforms to the UICollectionViewDataSource protocol will return configured cells to the collection view, which will be instances of UICollectionViewCell. If the collection view is configured to use section headers and/or section footers, the data source will return configured instances of UICollectionReusableView.

In the sample app, refer to the Basic Flow Layout to see these classes all working together as shown in Figure 20.1.

Figure 20.1 Sample app: Basic Flow Layout.

Setting Up a Collection View

The Basic Flow Layout example in the sample app demonstrates setting up a collection view with a minimum of customization, to show how quickly and easily a collection view can be created. Instead of using a basic UIViewController subclass, the basic flow used aUICollectionViewController subclass called PHGBasicFlowViewController, which conforms to the UICollectionViewDataSource and UICollectionViewDelegate protocols. This approach is not required; it is convenient when the collection view is all that is being displayed for a view controller. A collection view can be used with a standard view controller with no issues:

1. In the MainStoryboard, examine the Basic Flow View Controller–Basic Scene.

2. Expand the scene to see the collection view controller, as shown in Figure 20.2.

Figure 20.2 Xcode storyboard: specify custom class for collection view controller.

3. With the collection view controller selected, note the custom class specified in the identity inspector.

This ensures that the collection view controller will use the custom subclass PHGBasicFlowViewController.

UICollectionViewController instances have a property called collectionView, which is represented in Interface Builder as the collection view object. With the collection view object selected, note that several settings can be configured: the type of layout, the scrolling direction, and whether a section header and/or section footer should be used, as shown in Figure 20.3.

Figure 20.3 Xcode storyboard: custom collection view settings.

Interface Builder will present objects for the section header, collection view cell, and section footer that can be customized as well. For each of these, a custom subclass has been set up to simplify managing the subviews that need to be configured at runtime. This is not required; theUICollectionViewCell and UICollectionReusableView classes can be used directly if preferred.

The collection view cell subclass is called PHGThumbCell, and has one property called thumbImageView, which will be used to display the thumbnail image. The collection view object in Interface Builder is configured to use the custom subclass in the identity inspector, and references a UIImageView object for the thumbImageView property. The key item to set up for the collection view cell is the identifier, as shown in Figure 20.4; this is how the data source method will identify the type of cell to be configured and displayed.

Figure 20.4 Xcode storyboard: collection view cell identifier.

The collection view section header subclass is called PHGSectionHeader, and the section footer subclass is called PHGSectionFooter. Each subclass has a property for a label that will be used to display the header or footer title for the section. Both objects in Interface Builder are configured to use their respective custom subclasses in the identity inspector, and reference UILabel objects for their title properties. Just as the collection view cell “identifier” was specified for the collection view cell, separate identifiers are specified for the section header and section footer.

Implementing the Collection View Data Source Methods

After all the objects are configured in Interface Builder, the data source methods need to be implemented for the collection view to work. Confirm that the collection view object in the storyboard has the data source set to the basic flow view controller, as shown in Figure 20.5.

Figure 20.5 Xcode storyboard: collection view data source setting.

The sample app is a gallery app that displays photos from the user’s photo library, so there is logic implemented in the viewDidLoad method that builds an array of image assets (organized as an array containing asset arrays, in which each asset array holds the assets for a group/album) and an array of photo album titles. Refer to Chapter 23, “Accessing Photo Libraries,” for more details on that process.

The collection view needs to know how many sections to present, which is returned in the numberOfSectionsInCollectionView: method. The method is set up to return the count of albums (or groups) from the array of asset groups built in viewDidLoad.

- (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView
{
return [self.assetGroupArray count];
}

Next the collection view needs to know how many cells to present in each section. This method is called collectionView:numberOfItemsInSection:. The method has been built to find the correct asset array for the section index, and then return the count of assets in that array.

- (NSInteger)collectionView:(UICollectionView *)view
numberOfItemsInSection:(NSInteger)section;
{
NSArray *sectionAssets = self.assetArray[section];
return [sectionAssets count];
}

After the collection view has the counts of sections and items, it can determine how to lay out the view. Depending on where in the scrollable bounds the current view is, the collection view will request section headers, footers, and cells for the visible area of the view. Section headers and footers are requested from the collectionView:viewForSupplementaryElementOfKind:atIndexPath: method. Section headers and footers both need to be instances (or subclasses) of UICollectionReusableView. The method declares a nil instance ofUICollectionReusableView, which will be populated with either a configured section header or a section footer.

UICollectionReusableView *supplementaryView = nil;

The logic in the method must check the value of the kind parameter (which will be either UICollectionElementKindSectionHeader or UICollectionElementKindSectionFooter) to determine whether to return a section header or section footer.

if ([kind isEqualToString:UICollectionElementKindSectionHeader]) {

PHGSectionHeader *sectionHeader =
[collectionView dequeueReusableSupplementaryViewOfKind:kind
withReuseIdentifier:kSectionHeader forIndexPath:indexPath];

[sectionHeader.headerLabel
setText:self.assetGroupArray[indexPath.section]];

supplementaryView = sectionHeader;
}

To get an instance of the custom PHGSectionHeader, the collection view is asked to provide a supplementary view for the specified index path, using the dequeue with reuse identifier method. Note that the reuse identifier must be the same as specified in Interface Builder previously for the section header. This method will either instantiate a new view or reuse an existing view that is no longer being displayed. Then the title of the section is looked up in the group array, and put in the header’s title label.

For cells, the collectionView:cellForItematIndexPath: method is called. In this method, a cell is dequeued for the reuse identifier specified (this must match the reuse identifier specified for the cell in Interface Builder).

PHGThumbCell *cell =
[cv dequeueReusableCellWithReuseIdentifier:kThumbCell
forIndexPath:indexPath];

The cell is then configured to display the thumbnail image for the asset at the indexPath and returned for display.

ALAsset *assetForPath =
self.assetArray[indexPath.section][indexPath.row];

UIImage *assetThumb =
[UIImage imageWithCGImage:[assetForPath thumbnail]];

[cell.thumbImageView setImage:assetThumb];

return cell;

If setting up the cells and section header/footer object in a storyboard is not the preferred approach, they can be set up in nibs or in code. In that case, it is necessary to register the class or nib for the reuse identifier for cells using either theregisterClass:forCellWithReuseIdentifier: method or the registerNib:forCellWithReuseIdentifier: method. For section headers and footers the methods registerClass:forSupplementaryViewOfKind:withReuseIdentifier: orregisterNib:forSupplementaryViewOfKind:withReuseIdentifier: can be used.

Implementing the Collection View Delegate Methods

The collection view delegate can manage selection and highlighting of cells, can track removal of cells or sections, and can be used to display the Edit menu for items and perform actions from the Edit menu. The basic flow in the sample app demonstrates cell selection and highlighting. Confirm that the delegate for the collection view object is set to the basic flow view controller, as shown in Figure 20.5.

Collection view cells are designed to be able to change visually when they are selected or highlighted. A collection view cell has a subview called contentView where any content to be displayed for the cell should go. It has a backgroundView, which can be customized and which is always displayed behind the contentView. In addition, it has a selectedBackgroundView, which will be placed behind the contentView and in front of the backgroundView when the cell is highlighted or selected.

For the custom PHGThumbCell class, the selectedBackgroundView is instantiated and customized in the cell’s initWithCoder: method, since the cell is instantiated from the storyboard. Be sure to use the appropriate init method to customize the backgroundView andselectedBackgroundView depending on how your cells will be initialized.

- (id)initWithCoder:(NSCoder *)aDecoder
{
self = [super initWithCoder:aDecoder];
if (self) {

self.selectedBackgroundView =
[[UIView alloc] initWithFrame:CGRectZero];

[self.selectedBackgroundView
setBackgroundColor:[UIColor redColor]];
}
return self;
}

By default, collection views support single selection. To enable a collection view to support multiple selection, use the following:

[self.collectionView setAllowsMultipleSelection:YES];

For cell selection, there are four delegate methods that can be implemented. Two methods indicate whether a cell should be selected or deselected, and two methods indicate whether a cell was selected or deselected. For this example only the methods indicating whether a cell was selected or deselected are implemented.

- (void)collectionView:(UICollectionView *)collectionView
didSelectItemAtIndexPath:(NSIndexPath *)indexPath
{
NSLog(@"Item selected at indexPath: %@",indexPath);
}

- (void)collectionView:(UICollectionView *)collectionView
didDeselectItemAtIndexPath:(NSIndexPath *)indexPath
{
NSLog(@"Item deselected at indexPath: %@",indexPath);
}

Note that there is no logic in either method to actually manage the list of items selected—this is handled by the collection view. The selection delegate methods are then needed only for any customizations to manage when cells are selected, or to respond to a selection or deselection. The collection view maintains an array of index paths for selected cells, which can be used for any custom logic. The sample demonstrates tapping an action button in the navigation bar to display how many cells are selected, as shown in Figure 20.6; this could easily be enhanced to display an activity view for the selected cells.

Figure 20.6 Sample app: basic flow demonstrating cell selection.

Customizing Collection View and Flow Layout

Various customizations are possible for a flow layout collection view. The size of each cell can be customized individually, as well as the size of each section header and section footer. Guidelines can be provided to ensure that a minimum amount of spacing is respected between cells, as well as between cells, section headers and footers, and section boundaries. In addition, decoration views, which are views that enhance the collection view aesthetically but are not directly related to the collection view’s data, can be placed anywhere in the collection view.

Basic Customizations

The flow layout provided in the SDK can be customized to provide a wide variety of grid-based layouts. The flow layout has logic built in to calculate, based on scrolling direction and all the parameters set for cell size, spacing and sections, how many cells should be presented per row, and then how big the scroll view should be. When these parameters are manipulated, collection views can be created that display one cell per row (or even per screen), multiple cells packed tightly together in a row (as in iOS7’s Photos.app), or anything in between. These parameters are illustrated in Figure 20.7.

Figure 20.7 Collection view customizable parameters.

There are a few approaches to performing basic customizations on a flow layout collection view. The simplest approach is to set the defaults for the collection view in Interface Builder, by selecting the collection view object (or collection view flow layout object) and using the Size Inspector, as shown in Figure 20.8. Note that adjustments to these values affect the flow layout object associated with the collection view.

Figure 20.8 Xcode Interface Builder: Size Inspector for the collection view object.

Another approach is to update the items in code, in an instance or a subclass of UICollectionViewFlowLayout. In PHGCustomFlowLayout, the attributes for the custom flow layout are set in the init method.

self.scrollDirection = UICollectionViewScrollDirectionVertical;

self.itemSize = CGSizeMake(60, 60);
self.sectionInset = UIEdgeInsetsMake(10, 26, 10, 26);
self.headerReferenceSize = CGSizeMake(300, 50);
self.minimumLineSpacing = 20;
self.minimumInteritemSpacing = 40;

Finally, the collection view’s delegate can implement methods from the UICollectionViewDelegateFlowLayout protocol. These methods can be used to customize dimensions for individual cells based on data, or individual section headers or footers based on data. For example, photos with a higher user rating could be made bigger, or a section header or footer could be expanded as needed to accommodate an extra row of text for a long title.

Decoration Views

Decoration views can be used to enhance the visual look of the collection view, independently of cells and section headers and footers. They are intended to be independent of collection view data, and as such are not handled by the collection view’s data source or delegate. Since decoration views can be placed anywhere in a collection view, logic must be provided to tell the collection view where the decoration views should go. This necessitates creating a subclass of UICollectionViewFlowLayout to calculate locations for decoration views and to place them in the collection view when they should be visible in the currently displayed area.

In the sample app, tap the Custom Flow Layout option from the top menu to view an example that uses decoration views. The tilted shelf with a shadow below each row of photos is a decoration view, as shown in Figure 20.9.

Figure 20.9 Sample App: Custom Flow Layout example.

The first step in using a decoration view is to register a class or nib that can be used for decoration view. In PHGCCustomFlowLayout, a subclass of UICollectionReusableView called PHGRowDecorationView is registered in the init method.

[self registerClass:[PHGRowDecorationView class]
forDecorationViewOfKind:[PHGRowDecorationView kind]];

The PHGCCustomFlowLayout class has custom drawing logic to draw the shelf and shadow. Note that multiple types of decoration views can be registered for a collection view if desired; they can be distinguished using the kind parameter. After a decoration view class or nib is registered, the layout needs to calculate where the decoration views should be placed. To do this, the custom layout overrides the prepareLayout method, which gets called every time the layout needs to be updated. The method will calculate frame rects for each needed decoration view and store them in a property so that they can be pulled as needed.

In the prepareLayout method, [super prepareLayout] is called first to get the base layout. Then some calculations are performed to determine how many cells can fit in each row, presuming that they are uniform in size.

[super prepareLayout];

NSInteger sections = [self.collectionView numberOfSections];

CGFloat availableWidth = self.collectionViewContentSize.width -
(self.sectionInset.left + self.sectionInset.right);

NSInteger cellsPerRow =
floorf((availableWidth + self.minimumInteritemSpacing) /
(self.itemSize.width + self.minimumInteritemSpacing));

A mutable dictionary to store the calculated frames for each decoration is created, and a float to track the current y position in the layout while performing calculations is created.

NSMutableDictionary *rowDecorationWork =
[[NSMutableDictionary alloc] init];

CGFloat yPosition = 0;

With that established, the method will iterate over the sections to find rows needing decoration views.

for (NSInteger sectionIndex = 0; sectionIndex < sections; sectionIndex++)
{
...
}

Within each section, the method will calculate how much space the section header takes up, and how much space is needed between the section and the top of the cells in the first row. Then the method will calculate how many rows there will be in the section based on the number of cells.

yPosition += self.headerReferenceSize.height;
yPosition += self.sectionInset.top;

NSInteger cellCount =
[self.collectionView numberOfItemsInSection:sectionIndex];

NSInteger rows = ceilf(cellCount/(CGFloat)cellsPerRow);

Then the method will iterate over each row, calculate the frame for the decoration view for that row, create an index path for the row and section, store the frame rectangle in the work dictionary using the index path as the key, and adjust the current y position to account for minimum line spacing unless it is the final row of the section.

for (int row = 0; row < rows; row++)
{
yPosition += self.itemSize.height;

CGRect decorationFrame = CGRectMake(0,
yPosition-kDecorationYAdjustment,
self.collectionViewContentSize.width,
kDecorationHeight);

NSIndexPath *decIndexPath = [NSIndexPath
indexPathForRow:row inSection:sectionIndex];

rowDecorationWork[decIndexPath] =
[NSValue valueWithCGRect:decorationFrame];

if (row < rows - 1)
yPosition += self.minimumLineSpacing;
}