- Basics of the Application Lifecycle
- How to Use MVC
- MVC and UICollectionView
This chapter is from the book
This chapter is from the book
This chapter is from the book
MVC and UICollectionView
Now that you’ve read about the MVC paradigm, look at its application in the context of writing UICollectionView code.
The view component of MVC with UICollectionView is unsurprisingly the UICollectionView itself; the controller is either a subclass of UICollectionViewController or a subclass of UIViewController that conforms to the UICollectionViewDataSource and UICollectionViewDelegate protocols; the model can be anything.
Like with UITableView, your controller can either subclass UIViewController and conform to the two protocols for the collection view data source and delegate, or it can subclass UICollectionViewController itself. If you look in the header file of UICollectionViewController, you see that it’s very sparse. The controller inherits from UIViewController—conforming to UICollectionViewDataSource and UICollectionViewDelegate—and has a convenience initializer to programmatically create an instance of it using a collection view with a specific layout. It contains a property to access the collection view and another property to specify whether the selection in a collection view becomes cleared when it (re)appears.
When using a UICollectionViewController subclass, the view property of UIViewController points to the same object as the collectionView property of UICollectionViewController. The view is the collection view. If you plan to use only UICollectionView to display data to your user, I strongly recommend subclassing this prebuilt controller. In my experience, you run into fewer “gotchas” using these special controllers from Apple.
In some circumstances, subclassing UIViewController is preferable. For example, if your view contains a collection view, but also contains other views, it’s easier to have the collection view as a subview of the controller’s view. The distinction is minor, but important.
Figures 1.2 and 1.3 demonstrate the differences in the two approaches to using collection views. UICollectionViewController is far simpler; it should be the approach you take first. If you find you can’t solve your problem with it, switch to using the second approach. It’s usually easy to switch from using the first method to the second.
)
Figure 1.2. Example of MVC using UICollectionViewController
)
Figure 1.3. Example of MVC using UICollectionView’s protocols
This book uses the first approach unless there is a good reason not to. Even though the view property of UICollectionViewController is the same as its collectionView property, the code used in this book carefully distinguishes between the two.
Now that you’ve seen how collection views fit within the MVC paradigm of iOS apps, look at the following simple example. Don’t worry; you experiment a lot with collection views in Chapter 2, “Displaying Content Using UICollectionView.”
In the following example, you create a simple iPhone app that displays a bunch of cells with random colors. To get started, create a new application with the Single View template. Make sure that Use Storyboards is unchecked—this book focuses on collection views, and I don’t want to have to diverge to discuss the peculiarities of storyboards. Delete everything in the view controller header file and replace it with the code in Listing 1.1.
Listing 1.1. Basic UICollectionViewController Header File
@interface AFViewController : UICollectionViewController @end
Replace AFViewController with the name of your view controller. My initials are “AF,” so I prefix my class names with them to avoid namespace collisions.
Next, head over to your .xib file and delete the view. Drag a collection view onto the blank canvas and connect the collection view’s delegate and dataSource outlets to the File’s Owner, the view controller. It should look like Figure 1.4 when you’re done.
){kind=link}
)
Figure 1.4. Basic UICollectionView setup using a .xib
){kind=link}
Now comes the fun part: the code! UICollectionViewDataSource has two required methods. One returns the number of items in a section, and another configures a cell for a given index path.
If you’re not familiar with these terms, don’t worry. Chapter 2 explains everything in great detail. This quick example just gets your feet wet.
Following MVC, you need a model. Use a basic array that you’ll populate with a bunch of randomly generated colors. The top of your implementation file should look something like Listing 1.2.
Listing 1.2. Setting Up the Model
static NSString *kCellIdentifier = @"Cell Identifier";
@implementation AFViewController
{
NSArray *colorArray;
}
- (void)viewDidLoad
{
[super viewDidLoad];
[self.collectionView registerClass:[UICollectionViewCell class] forCellWithReuseIdentifier:kCellIdentifier];
const NSInteger numberOfColors = 100;
NSMutableArray *tempArray = [NSMutableArray arrayWithCapacity:numberOfColors];
for (NSInteger i = 0; i < numberOfColors; i++)
{
CGFloat redValue = (arc4random() % 255) / 255.0f;
CGFloat blueValue = (arc4random() % 255) / 255.0f;
CGFloat greenValue = (arc4random() % 255) / 255.0f;
[tempArray addObject:[UIColor colorWithRed:redValue green:greenValue blue:blueValue alpha:1.0f]];
}
colorArray = [NSArray arrayWithArray:tempArray];
}
The kCellIdentifier string is used to register a plain UICollectionViewCell as the cell for the collection view to use, so don’t pay much attention to it. The part that involves the model is the instance variable called colorArray. In viewDidLoad, you use a for loop to populate this array with random colors.
Now that you have the model set up, you need to configure your view to represent it. For this, use the two UICollectionViewDataSource methods mentioned earlier (see Listing 1.3).
Listing 1.3. Configuring the View
-(NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
return colorArray.count;
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:kCellIdentifier forIndexPath:indexPath]; //Discussed in Chapter 2 - pay no attention
cell.backgroundColor = colorArray[indexPath.item];
return cell;
}
The first method—collectionView:numberOfItemsInSection:—lets the collection view know how many cells it’s going to display. You rely on the model to let the controller know what number to return. Next, you have collectionView:cellForItemAtIndexPath:, which returns a cell that you are responsible for configuring in a way that represents your model. To do this, you grab the model at the given index and use that color as the background color for the cell. If you run the app, you get something like what you see in Figure 1.5. Because the colors are randomly generated, of course, your app will look different.
)
Figure 1.5. First run of the basic app
So, this simple example demonstrates how a model can represent a view and how you can configure a view to represent that model without either being aware of the other. This example demonstrates the platonic ideal of what you should strive for: clear separation between model, view, and controller.