On UI composition, embedded view controllers, weak vars, multi-cast delegates.

Interface Builder is great for composing plain interfaces, where each view controller is represented by a single instance of view in a view hierarchy.

Embedded view controllers are different.

Even though you can create multiple Embed segues connecting different places in a storyboard to the same embedded view controller - during app initialization the framework will create as many instances of that controller as there are segues.

This is counter-intuitive at first. A collection of views is an ordered tree, where each node has a reference to its single parent. But in a storyboard the view controllers can be connected by Embed segues arbitrarily and can form cycles.

It appears Apple gets away with this by forcing each Embed segue to create a new instance of a destination view controller.

For example, the following storyboard with embedded view controllers (part of a project in a coursera.org course) has many parent-child Embed relations:




Note the three parent Container views, and two of them share a view controller.

A parent view controller will have outlets to instances of child view controllers. Those outlets are declared weak and fished out of the storyboard in an override of prepareForSegue() method. If there are multiple instances of the same embedded view controller (as in the screenshot) - you’d want them stored in an array of weak references. But the challenge with Swift 2 is that it does not support collections of weak references.

In a simple case - having separate weak refs is ok. The prepareForSegue() implementation might look like this:

    // MARK: - Navigation

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {

        // !!! Embed segues are processed before viewDidLoad().
        switch segue.destinationViewController {
        case let vc as MyHobbiesCollectionViewController:
            // Note that this embedded VC has multiple instances,
            // need additional id check (i.e. by segue.identifier).
            switch segue.identifier {
                case .Some("My1stHobbiesEmbedSegue"):
                    my1stHobbiesCVC = vc;
            default:
                my2ndHobbiesCVC = vc;
            }
           
            // Also prepare non-embed segues.
        case let vc as EditHobbiesViewController:
            break;
        default: break;
        }

    }

In other more advanced cases, a recommended solution is to declare a weak ref in a structure and then have an array of those structures. Hopefully Apple is working to fix this minor annoyance.

A few words about how a hierarchy of view controllers should communicate with the rest of the tree.

KVO and NSNotificationCenter are ok in general case, but they lack type-safety of messages, and require not very nice symmetry of subscrbe/unsubscribe calls. Instead, I prefer declaring protocols for each child view controller, then a parent would implement those protocols, and assign itself to weak ref delegates of its children.

Events of the child controllers will first travel up a hierarchy, where a parent will route them to peers.

This messaging system could make use of a collection of weak ref delegates, which would be referred to as multi-cast delegates. But this will have to wait till a version of Swift that implements weak ref collections natively.

Quick Auto Layout rig for a responsive tab bar control

Let’s say I need to create a tab bar with 3 tabs, each having a button and an indicator. It needs to be responsive (autoresizeable) and each tab equally sized with the others.





Using Auto Layout here is how I do it.

1. Select a view that renders a tab (here called “TabView”). Copy-paste as many as needed. Customize each copy.





2. Add missing constraints manually. Select each tab view, uncheck “Constrain to margins”, and add space constraints. The first tab needs 4 constraints, the rest - only 3.







3. Add size constraints (width or height) by selecting all tab views, then Equal Widths.







4. Finally, update all frames in a parent view.





Embed in a parent controller, declare protocols to handle taps, etc.

Slide-out menu (with hamburger).

This short piece is about interactive slide-out menu in iOS. The demo is using an embedded container view for a menu view controller, and that controller handles animations and interaction.

The following implementation will be used for interaction-animation control where view hierarchy remains mostly static.

1. Menu view consists of two container views - a full screen dim view and an overlapping menu view. Interaction is registered by a pan gesture recognizer and is converted to a normalized “progress” property value. Setting this property on a menu view controller updates both the alpha property of the dim view and an origin of a menu view (via a horizontal leading constraint). 

import UIKit


class RootViewController: UIViewController, UIGestureRecognizerDelegate{

    @IBOutlet weak var menuContainerView: UIView!
    @IBOutlet weak var mainContainerView: UIView!
    
    weak var menuVC: MenuViewController!;

    override func viewDidLoad() {
        super.viewDidLoad()

        // Do any additional setup after loading the view.
        
        // Instead of fishing for an embedded controller in a prepareForSegue.
        for vc in childViewControllers {
            if let mvc = vc as? MenuViewController {
                menuVC = mvc;
            }
        }
    }

    
    // MARK: - Gesture Recognizer
    
    var initialProgress: Float = 0.0;
    var ignoreGesture = false;

    @IBAction func handlePanGesture(recognizer: UIPanGestureRecognizer) {
        let vel = recognizer.velocityInView(view);
        let velThreshold = menuVC.velocityThreshold;

        switch(recognizer.state) {
        case .Began:
            ignoreGesture = abs(vel.y) > abs(vel.x);
            if (ignoreGesture) {
                return;
            }
            initialProgress = menuVC.progress;
            recognizer.setTranslation(CGPointZero, inView: view)
            
        case .Changed:
            if (ignoreGesture) {
                return;
            }
            let translation = recognizer.translationInView(view);
            let tX = Float(translation.x);
            let progress = initialProgress + tX / velThreshold;
            // The following can be used to prevent menu progress overshot (not a good "responsive UI").
            // progress = min(1.0, max(0.0, progress));
            menuVC.progress = progress;
            
        case .Ended:
            if (ignoreGesture) {
                return;
            }
            let velX = Float(vel.x);
            let expand = ((menuVC.progress > 0.5 && velX > -velThreshold) || (menuVC.progress < 0.5 && velX > velThreshold));
            menuVC.animateMenu(expand);
            
        default:
            break
        }
    }
    
}

2. Progress property setter does a few things differently if the value is to be animated. Because menu works in conjunction with the embedding superview, the progress will enable/disable the superview as needed so that collapsed menu stays out of way when user interacts with the main content. To animate this property from its current value - there is a function animateMenu:.

import UIKit

class MenuViewController: UIViewController {
    @IBOutlet weak var dimView: UIView!
    @IBOutlet weak var menuView: UIView!
    @IBOutlet weak var menuLeadingConstraint: NSLayoutConstraint!

    var _useAnimation = false;
    var _progress: Float = 0.0;
    
    // To animate to a value set the _useAnimation true.
    var progress: Float {
        get { return _progress; }
        set {
            if (abs(newValue) > 1.0) {
                _progress = min(1.5, pow(abs(newValue), 0.2) * (newValue >= 0.0 ? 1.0 : -1.0));
            }
            else {
                _progress = newValue;
            }
            if (newValue > 1e-5 && !menuEnabled) {
                // Don't just set to condition via assignment, "false" will break animation (0.0 will collapse the menu before animation begins).
                menuEnabled = true;
            }
            
            let animations = {
                self.dimView.alpha = CGFloat(min(1.0, self._progress) / 2);
                let menuOriginX = CGFloat(self.velocityThreshold * self._progress) - self.menuView.frame.width;
                self.menuLeadingConstraint.constant = menuOriginX;
                self.view.layoutIfNeeded();
            };
            let completion: (Bool -> Void) = { finished in
                if (newValue <= 1e-5) {
                    self.menuEnabled = false;
                }
                self._useAnimation = false;
            };

            if (_useAnimation) {
                UIView.animateWithDuration(0.25, delay: 0.0, options: .CurveEaseOut, animations: animations, completion: completion);
            } else {
                animations();
                completion(true);
            }
        }
    }
    
    private(set) var velocityThreshold: Float = 100.0;
    
    // Enables/disables container view.
    var menuEnabled: Bool {
        get {
            return !view.superview!.hidden;
        }
        set {
            view.superview!.hidden = !newValue;
        }
    }

    func animateMenu(expand: Bool) {
        _useAnimation = true;
        
        if (expand) {
            progress = 1;
        } else {
            progress = 0;
        }
    }
    
    
    override func viewDidLoad() {
        super.viewDidLoad()

        // Do any additional setup after loading the view.
        
        // Initial menu view offset is a design-time position for an "expanded" state.
        velocityThreshold = Float(menuView.frame.width + menuView.frame.origin.x);
    }
    
    override func viewDidAppear(animated: Bool) {
        menuEnabled = true;
        progress = 1.0;
        animateMenu(false);
    }

    @IBAction func tapDimView(sender: AnyObject) {
        animateMenu(false);
    }
}

Other ways to implement this, such as using UIScrollView or custom transition animators, are more appropriate if standard transitions (on navigation controller) are desired. I find them either lacking in brevity of code or having tight dependence on standard view controllers.