In the first instance, let’s not use autolayout. Our project is based on the Single View Application template, with a single view controller class, ViewController. In the ViewController’s viewDidLoad, I’ll create the scroll view to fill the main view, and populate it with 30 UILabels whose text contains a sequential number so that we can see where we are when we scroll:

let sv = UIScrollView(frame: self.view.bounds)
sv.autoresizingMask = [.FlexibleWidth, .FlexibleHeight]
self.view.addSubview(sv)
sv.backgroundColor = UIColor.whiteColor()
var y : CGFloat = 10
for i in 0 ..< 30 {
    let lab = UILabel()
    lab.text = "This is label (i+1)"
    lab.sizeToFit()
    lab.frame.origin = CGPointMake(10,y)
    sv.addSubview(lab)
    y += lab.bounds.size.height + 10
}
var sz = sv.bounds.size
sz.height = y
sv.contentSize = sz // *

The crucial move is the last line, where we tell the scroll view how large its content is to be. If we omit this step, the scroll view won’t be scrollable; the window will appear to consist of a static column of labels.

There is no rule about the order in which you perform the two operations of setting the contentSize and populating the scroll view with subviews. In that example, we set the contentSize afterward because it is more convenient to track the heights of the subviews as we add them than to calculate their total height in advance. Similarly, you can alter a scroll view’s content (subviews) or contentSize, or both, dynamically as the app runs.

Any direct subviews of the scroll view may need to have their autoresizing set appropriately in case the scroll view is resized, as would happen, for instance, if our app performs compensatory rotation. To see this, add these lines to the preceding example, inside the for loop:

lab.frame.width = self.view.bounds.width - 20
lab.backgroundColor = UIColor.redColor()
lab.autoresizingMask = .FlexibleWidth

Run the app, and rotate the device or the Simulator. The labels are wider in portrait orientation because the scroll view itself is wider.

This, however, has nothing to do with the contentSize! The contentSize does not change just because the scroll view’s bounds change; if you want the contentSize to change in response to rotation, you will need to change it manually, in code. Conversely, resizing the contentSize has no effect on the size of the scroll view’s subviews; it merely determines the scrolling limit.

With autolayout, things are different. The difficult thing to understand — and it is certainly counterintuitive — is that a constraint between a scroll view and its direct subview is not a way of positioning the subview relative to the scroll view (as it would be if the superview were an ordinary UIView). Instead, it’s a way of describing the scroll view’s contentSize.

To see this, let’s rewrite the preceding example to use autolayout. The scroll view and its subviews have their translatesAutoresizingMaskIntoConstraints set to false, and we’re giving them explicit constraints:

let sv = UIScrollView()
sv.backgroundColor = UIColor.whiteColor()
sv.translatesAutoresizingMaskIntoConstraints = false
self.view.addSubview(sv)
var con = [NSLayoutConstraint]()
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat(
        "H:|[sv]|",
        options:[], metrics:nil,
        views:["sv":sv]))
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat(
        "V:|[sv]|",
        options:[], metrics:nil,
        views:["sv":sv]))
var previousLab : UILabel? = nil
for i in 0 ..< 30 {
    let lab = UILabel()
    // lab.backgroundColor = UIColor.redColor()
    lab.translatesAutoresizingMaskIntoConstraints = false
    lab.text = "This is label (i+1)"
    sv.addSubview(lab)
    con.appendContentsOf(
        NSLayoutConstraint.constraintsWithVisualFormat(
            "H:|-(10)-[lab]",
            options:[], metrics:nil,
            views:["lab":lab]))
    if previousLab == nil { // first one, pin to top
        con.appendContentsOf(
            NSLayoutConstraint.constraintsWithVisualFormat(
                "V:|-(10)-[lab]",
                options:[], metrics:nil,
                views:["lab":lab]))
    } else { // all others, pin to previous
        con.appendContentsOf(
            NSLayoutConstraint.constraintsWithVisualFormat(
                "V:[prev]-(10)-[lab]",
                options:[], metrics:nil,
                views:["lab":lab, "prev":previousLab!]))
    }
    previousLab = lab
}
NSLayoutConstraint.activateConstraints(con)

The labels are correctly positioned relative to one another, but the scroll view isn’t scrollable. Moreover, setting the contentSize manually doesn’t help. The reason is that we are missing a constraint. We have to add one more constraint, showing the scroll view what the height of its contentSize should be. Replace the last line of that code with this:

// ... everything else as before ...
// last one, pin to bottom, this dictates content size height!
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat(
        "V:[lab]-(10)-|",
        options:[], metrics:nil,
        views:["lab":previousLab!]))
NSLayoutConstraint.activateConstraints(con)

The constraints of the scroll view’s subviews now describe the contentSize height: the top label is pinned to the top of the scroll view, the next one is pinned to the one above it, and so on — and the bottom one is pinned to the bottom of the scroll view. Consequently, the runtime calculates the contentSize height from the inside out, as it were, as the sum of all the vertical constraints (including the intrinsic heights of the labels), and the scroll view is vertically scrollable to show all the labels.

Instead of putting all of our scroll view’s content directly inside the scroll view as its immediate subviews, we can provide a generic UIView as the sole immediate subview of the scroll view; everything else inside the scroll view is to be a subview of this generic UIView, which we may term the content view. This is a commonly used arrangement.

Under autolayout, we then have two choices for setting the scroll view’s contentSize:

A convenient consequence of this arrangement is that it works independently of whether the content view’s own subviews are positioned explicitly by their frames or using constraints. There are thus four possible combinations:

I’ll illustrate by rewriting the previous example to use a content view. All four possible combinations start the same way:

let sv = UIScrollView()
sv.backgroundColor = UIColor.whiteColor()
sv.translatesAutoresizingMaskIntoConstraints = false
self.view.addSubview(sv)
var con = [NSLayoutConstraint]()
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat(
        "H:|[sv]|",
        options:[], metrics:nil,
        views:["sv":sv]))
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat(
        "V:|[sv]|",
        options:[], metrics:nil,
        views:["sv":sv]))
let v = UIView() // content view
sv.addSubview(v)

The differences lie in what happens next. The first combination is that no constraints are used (apart from the constraints that frame the scroll view), and the scroll view’s content size is set explicitly. It’s just like the first example in the chapter, except that the labels are added to the content view, not to the scroll view:

var y : CGFloat = 10
for i in 0 ..< 30 {
    let lab = UILabel()
    lab.text = "This is label (i+1)"
    lab.sizeToFit()
    lab.frame.origin = CGPointMake(10,y)
    v.addSubview(lab) // *
    y += lab.bounds.size.height + 10
}
// set content view frame and content size explicitly
v.frame = CGRectMake(0,0,0,y)
sv.contentSize = v.frame.size
NSLayoutConstraint.activateConstraints(con)

The second combination is that the content view uses explicit constraints, but its subviews don’t. It’s just like the preceding code, except that we set the content view’s constraints rather than the scroll view’s content size:

var y : CGFloat = 10
for i in 0 ..< 30 {
    let lab = UILabel()
    lab.text = "This is label (i+1)"
    lab.sizeToFit()
    lab.frame.origin = CGPointMake(10,y)
    v.addSubview(lab)
    y += lab.bounds.size.height + 10
}
// set content view width, height, and frame-to-superview constraints
// content size is calculated for us
v.translatesAutoresizingMaskIntoConstraints = false
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat("V:|[v(y)]|",
        options:[], metrics:["y":y], views:["v":v]))
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat("H:|[v(0)]|",
        options:[], metrics:nil, views:["v":v]))
NSLayoutConstraint.activateConstraints(con)

The third combination is that explicit constraints are used throughout. This is just like the second example in the chapter, except that the labels are added to the content view:

var previousLab : UILabel? = nil
for i in 0 ..< 30 {
    let lab = UILabel()
    // lab.backgroundColor = UIColor.redColor()
    lab.translatesAutoresizingMaskIntoConstraints = false
    lab.text = "This is label (i+1)"
    v.addSubview(lab) // *
    con.appendContentsOf( // *
        NSLayoutConstraint.constraintsWithVisualFormat(
            "H:|-(10)-[lab]",
            options:[], metrics:nil,
            views:["lab":lab]))
    if previousLab == nil { // first one, pin to top
        con.appendContentsOf( // *
            NSLayoutConstraint.constraintsWithVisualFormat(
                "V:|-(10)-[lab]",
                options:[], metrics:nil,
                views:["lab":lab]))
    } else { // all others, pin to previous
        con.appendContentsOf( // *
            NSLayoutConstraint.constraintsWithVisualFormat(
                "V:[prev]-(10)-[lab]",
                options:[], metrics:nil,
                views:["lab":lab, "prev":previousLab!]))
    }
    previousLab = lab
}
// last one, pin to bottom, this dictates content size height!
con.appendContentsOf( // *
    NSLayoutConstraint.constraintsWithVisualFormat(
        "V:[lab]-(10)-|",
        options:[], metrics:nil,
        views:["lab":previousLab!]))
// pin content view to scroll view, sized by its subview constraints
// content size is calculated for us
v.translatesAutoresizingMaskIntoConstraints = false
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat("V:|[v]|",
        options:[], metrics:nil, views:["v":v])) // *
con.appendContentsOf(
    NSLayoutConstraint.constraintsWithVisualFormat("H:|[v]|",
        options:[], metrics:nil, views:["v":v])) // *
NSLayoutConstraint.activateConstraints(con)

The fourth combination is that the content view’s subviews are positioned using constraints, but we set the content view’s frame and the scroll view’s content size explicitly. There is no y to track as we position the subviews, so how can we find out the final content size height? Fortunately, systemLayoutSizeFittingSize: tells us:

// ... same as previous ...
// last one, pin to bottom, this dictates content size height!
con.appendContentsOf( // *
    NSLayoutConstraint.constraintsWithVisualFormat(
        "V:[lab]-(10)-|",
        options:[], metrics:nil,
        views:["lab":previousLab!]))
NSLayoutConstraint.activateConstraints(con)
// autolayout helps us learn the consequences of those constraints
let minsz = v.systemLayoutSizeFittingSize(UILayoutFittingCompressedSize)
// set content view frame and content size explicitly
v.frame = CGRectMake(0,0,0,minsz.height)
sv.contentSize = v.frame.size

If its pagingEnabled property is true, the scroll view doesn’t let the user scroll freely; instead, the content is considered to consist of equal-sized sections. The user can scroll only in such a way as to move to a different section. The size of a section is set automatically to the size of the scroll view’s bounds. The sections are the scroll view’s pages.

When the user stops dragging, a paging scroll view gently snaps automatically to the nearest whole page. For example, let’s say that the scroll view scrolls only horizontally, and that its subviews are image views showing photos, sized to match the scroll view’s bounds. If the user drags horizontally to the left to a point where less than half of the next photo to the right is visible, and raises the dragging finger, the paging scroll view snaps its content back to the right until the entire first photo is visible again. If the user drags horizontally to the left to a point where more than half of the next photo to the right is visible, and raises the dragging finger, the paging scroll view snaps its content further to the left until the entire second photo is visible.

The usual arrangement is that a paging scroll view is at least as large, or nearly as large, in its scrollable dimension, as the screen. A moment’s thought will reveal that, under this arrangement, it is impossible for the user to move the content more than a single page in any direction with a single gesture. The reason is that the size of the page is the size of the scroll view’s bounds. Thus the user will run out of surface area to drag on before being able to move the content the distance of a page and a half, which is what would be needed to make the scroll view snap to a page not adjacent to the page we started on.

Sometimes, indeed, the paging scroll view will be slightly larger than the window in its scrollable dimension. This allows each page’s content to fill the scroll view while also providing gaps between the pages, visible when the user starts to scroll. The user is still able to move from page to page, because it is still readily possible to drag more than half a new page into view (and the scroll view will then snap the rest of the way when the user raises the dragging finger).

When the user raises the dragging finger, the scroll view’s action in adjusting its content is considered to be decelerating, and the scroll view’s delegate (discussed in more detail later in this chapter) will receive scrollViewWillBeginDecelerating:, followed by scrollViewDidEndDecelerating: when the scroll view’s content has stopped moving and a full page is showing. Thus, these messages can be used to detect efficiently that the page may have changed.

You can take advantage of this, for example, to coordinate a paging scroll view with a UIPageControl (Chapter 12). In this example, a page control (self.pager) is updated whenever the user causes a horizontally scrollable scroll view (self.sv) to display a different page:

func scrollViewDidEndDecelerating(scrollView: UIScrollView) {
    let x = self.sv.contentOffset.x
    let w = self.sv.bounds.size.width
    self.pager.currentPage = Int(x/w)
}

Conversely, we can scroll the scroll view to a new page manually when the user taps the page control; in this case we have to calculate the page boundaries ourselves:

@IBAction func userDidPage(sender:AnyObject?) {
    let p = self.pager.currentPage
    let w = self.sv.bounds.size.width
    self.sv.setContentOffset(CGPointMake(CGFloat(p)*w,0), animated:true)
}

A useful interface is a paging scroll view where you supply pages dynamically as the user scrolls. In this way, you can display a huge number of pages without having to put them all into the scroll view at once. A scrolling UIPageViewController (Chapter 6) provides exactly that interface. Its UIPageViewControllerOptionInterPageSpacingKey even provides the gap between pages that I mentioned earlier.

A compromise between a UIPageViewController and a completely preconfigured paging scroll view is a scroll view whose contentSize can accommodate all pages, but whose actual page content is supplied lazily. The only pages that have to be present at all times are the page visible to the user and the two pages adjacent to it on either side (so that there is no delay in displaying a new page’s content when the user starts to scroll). This approach is exemplified by Apple’s PageControl sample code. Unfortunately, that example does not also remove page content that is no longer needed, so there is ultimately no conservation of memory.

There are times when a scroll view, even one requiring a good deal of dynamic configuration, is better than a scrolling UIPageViewController, because the scroll view provides full information to its delegate about the user’s scrolling activity (as described later in this chapter). For example, if you wanted to respond to the user’s dragging one area of the interface by programmatically scrolling another area of the interface in a coordinated fashion, you might want what the user is dragging to be a scroll view, because it tells you what the user is up to at every moment.

Suppose we have some finite but really big content that we want to display in a scroll view, such as a very large image that the user can inspect, piecemeal, by scrolling. To hold the entire image in memory may be onerous or impossible.

Tiling is one solution to this kind of problem. It takes advantage of the insight that there’s really no need to hold the entire image in memory; all we need at any given moment is the part of the image visible to the user right now. Mentally, divide the content rectangle into a matrix of rectangles; these rectangles are the tiles. In reality, divide the huge image into corresponding rectangles. Then whenever the user scrolls, we look to see whether part of any empty tile has become visible, and if so, we supply its content. At the same time, we can release the content of all tiles that are completely offscreen. Thus, at any given moment, only the tiles that are showing have content. There is some latency associated with this approach (the user scrolls, then any empty newly visible tiles are filled in), but we will have to live with that.

There is actually a built-in CALayer subclass for helping us implement tiling — CATiledLayer. Its tileSize property sets the dimensions of a tile. Its drawLayer:inContext: is called when content for an empty tile is needed; calling CGContextGetClipBoundingBox on the context reveals the location of the desired tile, and now we can supply that tile’s content.

The usual approach is to implement drawRect: in a UIView that hosts the CATiledLayer. Here, the CATiledLayer is the view’s underlying layer; therefore the view is the CATiledLayer’s delegate (see Chapter 3). This means that when the CATiledLayer’s drawLayer:inContext: is called, the host view’s drawRect: is called, and the drawRect: parameter is the same as the result of calling CGContextGetClipBoundingBox — namely, it’s the rect of the tile we are to draw.

The tileSize may need to be adjusted for the screen resolution. On a double-resolution device, for example, the CATiledLayer’s contentsScale will be doubled, and the tiles will be half the size that we ask for. If that isn’t acceptable, we can double the tileSize dimensions.

To illustrate, we’ll use some tiles already created for us as part of Apple’s own PhotoScroller sample code. In particular, I’ll use a few of the “CuriousFrog_500” images. These all have names of the form CuriousFrog_500_x_y.png, where x and y are integers corresponding to the picture’s position within the matrix. The images are 256×256 pixels, except for the ones on the extreme right and bottom edges of the matrix, which are shorter in one dimension, but I won’t be using those in this example; I’ve selected a square matrix of 9 square images.

We will give our scroll view (self.sv) one subview, a TiledView, a UIView subclass that exists purely to give our CATiledLayer a place to live. TILESIZE is defined as 256, to match the image dimensions:

override func viewDidLoad() {
    let f = CGRectMake(0,0,3*TILESIZE,3*TILESIZE)
    let content = TiledView(frame:f)
    let tsz = TILESIZE * content.layer.contentsScale
    (content.layer as! CATiledLayer).tileSize = CGSizeMake(tsz, tsz)
    self.sv.addSubview(content)
    self.sv.contentSize = f.size
    self.content = content
}

Here’s the code for TiledView. As Apple’s sample code points out, we must fetch images with init(contentsOfFile:) in order to avoid the automatic caching behavior of init(named:) — after all, we’re going to all this trouble exactly to avoid using more memory than we have to:

override class func layerClass() -> AnyClass {
    return CATiledLayer.self
}
override func drawRect(r: CGRect) {
    let tile = r
    let x = Int(tile.origin.x/TILESIZE)
    let y = Int(tile.origin.y/TILESIZE)
    let tileName = String(format:"CuriousFrog_500_(x+3)_(y)")
    let path = NSBundle.mainBundle().pathForResource(tileName, ofType:"png")!
    let image = UIImage(contentsOfFile:path)!
    image.drawAtPoint(CGPointMake(CGFloat(x)*TILESIZE,CGFloat(y)*TILESIZE))
}

In this configuration, our TiledView’s drawRect is called on a background thread. This is unusual, but it shouldn’t cause any trouble as long as you confine yourself to standard thread-safe activities. Fortunately, fetching the image and drawing it are thread-safe.

There is no special call for invalidating an offscreen tile. You can call setNeedsDisplay or setNeedsDisplayInRect: on the TiledView, but this doesn’t erase offscreen tiles. You’re just supposed to trust that the CATiledLayer will eventually clear offscreen tiles if needed to conserve memory.

CATiledLayer has a class method fadeDuration that dictates the duration of the animation that fades a new tile into view. You can create a CATiledLayer subclass and override this method to return a value different from the default (0.25), but this is probably not worth doing, as the default value is a good one. Returning a smaller value won’t make tiles appear faster; it just replaces the nice fade-in with an annoying flash.

To zoom programmatically, you have two choices:

In this example, I implement double tapping as a zoom gesture. In my action handler for the double-tap UITapGestureRecognizer attached to the scalable view, a double tap means to zoom to maximum scale, minimum scale, or actual size, depending on the current scale value:

@IBAction func tapped(tap : UIGestureRecognizer) {
    let v = tap.view!
    let sv = v.superview as! UIScrollView
    if sv.zoomScale < 1 {
        sv.setZoomScale(1, animated:true)
    }
    else if sv.zoomScale < sv.maximumZoomScale {
        sv.setZoomScale(sv.maximumZoomScale, animated:true)
    }
    else {
        sv.setZoomScale(sv.minimumZoomScale, animated:true)
    }
}

By default, when a scroll view zooms, it merely applies a scale transform to the scaled view. The scaled view’s drawing is cached beforehand into its layer, so when we zoom in, the bits of the resulting bitmap are drawn larger. This means that a zoomed-in scroll view’s content may be fuzzy (pixellated). In some cases this might be acceptable, but in others you might like the content to be redrawn more sharply at its new size.

(On a high-resolution device, this might not be such an issue. For example, if the user is allowed to zoom only up to double scale, you can draw at double scale right from the start; the results will look good at single scale, because the screen has high resolution, as well as at double scale, because that’s the scale you drew at.)

One solution is to take advantage of a CATiledLayer feature that I didn’t mention earlier. It turns out that CATiledLayer is aware not only of scrolling but also of scaling: you can configure it to ask for tiles to be drawn when the layer is scaled to a new order of magnitude. When your drawing routine is called, the graphics context itself has already been scaled appropriately by a transform.

In the case of an image into which the user is to be permitted to zoom deeply, you would be forearmed with multiple tile sets constituting the image, each set having double the tile size of the previous set (as in Apple’s PhotoScroller example). In other cases, you may not need tiles at all; you’ll just draw again, at the new resolution.

Besides its tileSize, you’ll need to set two additional CATiledLayer properties:

The CATiledLayer will ask for a redraw at a higher resolution as soon as the view’s size becomes larger than the previous resolution. In other words, if there are two levels of detail with a bias of 1, the layer will be redrawn at 2x as soon as it is zoomed even a little bit larger than 1x. This is an excellent approach, because although a level of detail would look blurry if scaled up, it looks pretty good scaled down.

For example, let’s say I have a TiledView that hosts a CATiledLayer, in which I intend to draw an image. I haven’t broken the image into tiles, because the maximum size at which the user can view it isn’t prohibitively large; the original image is 838×958, and can be held in memory easily. Rather, I’m using a CATiledLayer in order to take advantage of its ability to change resolutions automatically. The image will be displayed initially at 208×238, and if the user never zooms in to view it larger, we can save memory by drawing a quarter-size version of the image.

The CATiledLayer is configured as follows:

let scale = lay.contentsScale
lay.tileSize = CGSizeMake(208*scale,238*scale)
lay.levelsOfDetail = 3
lay.levelsOfDetailBias = 2

The tileSize has been adjusted for screen resolution, so the result is as follows:

We do not, however, need to draw each tile individually. Each time we’re called upon to draw a tile, we’ll draw the entire image into the TiledView’s bounds; whatever falls outside the requested tile will be clipped out and won’t be drawn.

Here’s my TiledView’s drawRect: implementation. I have a UIImage property currentImage, initialized to nil, and a CGRect property currentSize initialized to CGSizeZero. Each time drawRect: is called, I compare the tile size (the incoming rect parameter’s size) to currentSize. If it’s different, I know that we’ve changed by one level of detail and we need a new version of currentImage, so I create the new version of currentImage at a scale appropriate to this level of detail. Finally, I draw currentImage into the TiledView’s bounds:

override func drawRect(rect: CGRect) {
    let oldSize = self.currentSize
    if !CGSizeEqualToSize(oldSize, rect.size) {
        // make a new size
        self.currentSize = rect.size
        // make a new image
        let lay = self.layer as! CATiledLayer
        let tr = CGContextGetCTM(UIGraphicsGetCurrentContext()!)
        let sc = tr.a/lay.contentsScale
        let scale = sc/4.0
        let path = NSBundle.mainBundle().pathForResource(
            "earthFromSaturn", ofType:"png")!
        let im = UIImage(contentsOfFile:path)!
        let sz = CGSizeMake(im.size.width * scale, im.size.height * scale)
        UIGraphicsBeginImageContextWithOptions(sz, true, 1)
        im.drawInRect(CGRectMake(0,0,sz.width,sz.height))
        self.currentImage = UIGraphicsGetImageFromCurrentImageContext()
        UIGraphicsEndImageContext()
    }
    self.currentImage.drawInRect(self.bounds)
}

An alternative and much simpler approach (from a WWDC 2011 video) is to make yourself the scroll view’s delegate so that you get an event when the zoom ends, and then change the scalable view’s contentScaleFactor to match the current zoom scale, compensating for the high-resolution screen at the same time:

func scrollViewDidEndZooming(scrollView: UIScrollView,
    withView view: UIView?,
    atScale scale: CGFloat) {
        if let view = view {
            view.contentScaleFactor = scale * UIScreen.mainScreen().scale
        }
}

In response, the scalable view’s drawRect: will be called, and its rect parameter will be the CGRect to draw into. Thus, the view may appear fuzzy for a while as the user zooms in, but when the user stops zooming, the view is redrawn sharply. That approach comes with a caveat, however: you mustn’t overdo it. If the zoom scale, screen resolution, and scalable view size are high, you will be asking for a very large graphics context to be maintained in memory, which could cause your app to run low on memory or even to be abruptly terminated by the system.

For more about displaying a large image in a zoomable scroll view, see Apple’s Large Image Downsizing example.