acb's technical journal

Posts matching tags 'ios'

2015/6/19

The case of the crashing Swift compiler

Recently, whilst preparing release 1.1 of the MPDluxe iOS app, I encountered an unwelcome surprise: the app itself had built and worked without problems in Debug mode, but as soon as I tried to Archive it (i.e., building it in Release mode, with compiler optimisations switched on), the Swift compiler would, at some stage, choke on something and die with a segmentation fault:

0  swift                    0x00000001029e82b8 llvm::sys::PrintStackTrace(__sFILE*) + 40
1  swift                    0x00000001029e8794 SignalHandler(int) + 452
2  libsystem_platform.dylib 0x00007fff88c53f1a _sigtramp + 26
3  libsystem_platform.dylib 0x0000000104b06000 _sigtramp + 2079006976
4  swift                    0x0000000102526d5a (anonymous namespace)::DCE::markControllingTerminatorsLive(swift::SILBasicBlock*) + 346
5  swift                    0x0000000102526ae9 (anonymous namespace)::DCE::markValueLive(swift::ValueBase*) + 201
6  swift                    0x00000001025262ff (anonymous namespace)::DCE::run() + 1983
7  swift                    0x00000001024cdf3e swift::SILPassManager::runFunctionPasses(llvm::ArrayRef) + 1310
8  swift                    0x00000001024ce9c9 swift::SILPassManager::runOneIteration() + 633
9  swift                    0x00000001024cd436 swift::runSILOptimizationPasses(swift::SILModule&) + 790
10 swift                    0x00000001022d18e7 frontend_main(llvm::ArrayRef, char const*, void*) + 4695
11 swift                    0x00000001022d04e6 main + 1814
12 libdyld.dylib            0x00007fff90c545c9 start + 1

A web search revealed that others had had similar problems with the compiler, also in the optimisation stage of a release build. Everybody seemed to have their own superstition on which ostensibly legal syntactic feature to avoid to appease the gremlins, mostly involving being more circumspect about optionals; their cases were sufficiently different that there was no one thing to search for and eliminate.

With that in mind, I turned to git bisect. In short, bisect is a subcommand of the git version control system which allows you to specify a last-known-good version of your code, and semi-automates a binary search between then and the current (presumably broken) version, narrowing down on exactly which change coincided with the code breaking. In bisect mode, git checks out a revision from the middle of the as yet unsearched range; you then test it (in my case, getting Xcode to do an Archive build). If it works, you enter the git bisect good command and it skips forward; if not, you enter git bisect bad and it skips backward. Do this for a few steps and soon you will have exactly which commit broke things. Anyway, I ran git bisect between the current HEAD and version 1.0, as below:

% git bisect start
% git bisect bad
% git bisect good v1.0
Bisecting: 51 revisions left to test after this (roughly 6 steps)
[79b5f750178d09e924da572a4d83fb66bc9bed61] Removed redundant output-related methods

It had checked out a version from the middle of the set of check-ins between then and now; I went back into Xcode, did a Clean and an Archive, and, sure enough, Segmentation Fault. So this one's bad, and it's time to skip back halfway to the beginning and try from there:

% git bisect bad
Bisecting: 25 revisions left to test after this (roughly 5 steps)
[b49c1128168bb844f3b944d6e502d98f27e64f14] Added title to Search view controller

I tried building this, and it worked; so this one's good. Now to skip forward, and so on for the next few steps:

% git bisect good                                
Bisecting: 12 revisions left to test after this (roughly 4 steps)
[b112971ad7a21cb6c47358d4e316380df42f006f] Removed dead code
% git bisect good
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[524b442c6c6c3d6ea02edc1d3a56abe82170d213] Hived navigateToContainingFolderOfFile off into MPDNavigationController
% git bisect bad
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[06f9a82e169617aeebeb85122bc5829d3c43b6af] DraggableTableViewCell now has hidden drawer for buttons
% git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[fce75660b3dd40a21abc996c4ed5fc7400d59d49] Navigate to path from playlist now works, modulo tidying up/refactoring/aesthetic grace notes
% git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[eb5ee15b0520e56177d69745f615d8f1afaed930] Implemented “navigate to” hidden button in PlaylistTableViewCell

Surely enough, we had the offending commit soon enough:

% git bisect good
fce75660b3dd40a21abc996c4ed5fc7400d59d49 is the first bad commit
commit fce75660b3dd40a21abc996c4ed5fc7400d59d49
Author: acb 
Date:   Fri Jun 5 17:38:33 2015 +0100
  
    Navigate to path from playlist now works, modulo tidying up/refactoring/aesthetic grace notes

The commit itself was a fairly small one, and (after going back to the latest revision), commenting out parts of the code added in it and trying to build soon found what the Swift optimiser was having trouble with.

The code in question deals with the app's Playlist view, a UITableView which shows a playlist of songs queued up for playing; each of these is represented by a UITableViewCell subclass named PlaylistTableViewCell. One of the added features of the app is a hidden button on the playlist items, allowing the user to go to a view of the directory the song is in (i.e., to browse the rest of the album it's on). This was implemented by having an optional closure on the PlaylistTableViewCell, which would be called when the button was tapped. This closure captured various relevant data (such as the directory path to go to) and was set when the table view cell was filled in; a greatly simplified version looks a little like:

class PlaylistTableViewCell {
   ...
    var onNavTo:(()->())? = nil

    func navToPressed(sender: AnyObject) {
        onNavTo?()
    }
}

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell{
 ...

  cell.onNavTo = {
     // code for navigating to item['file']
      if let fpath = item["file"] as? String {
          navigateToContainingFolderOfFile(fpath)
      }
  }

Which is perfectly legal Swift, though, with the Swift 1.2 optimising compiler, that plus £2.80 gets one a cup of coffee. Anyway, to appease the gremlins, I inlined the code, replacing the closure with an optional string:

class PlaylistTableViewCell {
   ...
    var navToPath: String? = nil

    func navToPressed(sender: AnyObject) {
        if let fpath = navToPath {
            navigateToContainingFolderOfFile(fpath)
        }
    }
}

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell{
 ...
    cell.navToPath = item["file"] as? String
}

From there onward, the code built and worked without a problem.

The moral of this story is that, while the Swift toolchain is a lot more stable than before, it (as of 1.2, the current production release) still has a few bugs, some of which may appear at various times and, through no fault of one's own, derail an ostensibly perfectly valid project. Working around them is a combination of detective work and making the right offerings to the trickster gods of the toolchain; and that git bisect is your friend.

debugging git ios swift war stories 0

2015/5/29

A popover menu control for iOS 8

In iOS 8, it is possible to present any view controller in a popover. This blog post describes the construction of a UIControl which presents a popover menu of text options. The full code of the control, and an example program, may be found here.

Sometimes, it is useful to have a popup menu in an iOS app; for the user to be able to change a value by tapping or dragging on the value and selecting a new one from a menu. Traditionally, this has been done on the iPhone with UIActionSheet; the idiom was that the user tapping on the button/table cell would trigger a pane of options, which would display from the bottom of the screen. This made sense for small phone screens, as it allowed one-handed operation, but in the age of the phablet, there is no need to stick to it. Hence, as of iOS 8, it is possible to present arbitrary view controllers in a popover on any iOS device, which is quite powerful.

On the iPad, one could present arbitrary view controllers in a popover view for a while. This deliberately did not support the iPhone, and would cause the app to die with a runtime error if one tried using it. In iOS 8, Apple have changed the interface somewhat, and extended it to the iPhone.

Popover view controllers in iOS 8

In iOS, one presents a new view controller by instantiating it, setting it up and calling the current view controller's presentViewController:animated: method. Traditionally, this has been used to push view controllers onto a UINavigationController stack, or to present modal full-screen view controllers. In iOS 8, the same method can be used to present view controllers in a popover container, which appears on the screen with an arrow pointing to the control it launched from.

To do this, one first sets the view controller's modalPresentationStyle to UIModalPresentationStyle.Popover. One then obtains a UIPopoverPresentationController from the view controller's popoverPresentationController property, and uses this to configure the popover's appearance and behaviour; these include the view on which the popover is being displayed, the frame rectangle of the control it is being launched from (to which the arrow will point), and which arrow directions one wishes to use. One also needs to give it a delegate, and to make it work correctly, define the delegate's adaptivePresentationStyleForPresentationController to return .None. Then, once this is done, one presents the view controller using presentViewController:animated:. The controller may be dismissed in the same way modal view controllers are, by calling its dismissViewControllerAnimated: method. The controller will also be dismissed if the user taps outside of the popover; if this happens, the delegate's popoverPresentationControllerDidDismissPopover: method will be called.

Building a pop-up menu/selector control

This is all very well, but we want something more convenient than setting up a view controller every time we want a popover menu. The goal is to have a self-contained control that handles a few common cases of popover menus. We make the following assumptions:

  1. The popover menu will have one or more items, or options, each of which is a string.
  2. The popover menu will be launched when the user taps on a button.
    1. In some cases, the button will display the currently selected option, and the menu will allow the user to change this.
    2. In other cases, the menu will display a fixed prompt, and the menu will be used to trigger one of several actions.

From this, it's obvious that we want something that will be configured with a list of options and construct the popover and its embedded view controller; also, as the set of options is a list of strings which are tappable items, the view controller looks very much like it would be a UITableViewController. Given that we want the mechanism to be triggered by the button, and (in some cases) to change the button's text, why not make the button part of it, with the popover handling wired into it? So, we'd want:

  1. The entire control will be a UIView subclass, which contains a UIButton, and handles displaying and responding to the popover control when the button is tapped.
  2. The control keeps a list of options, and the index of the currently selected option (if present). It also has various configuration options, such as whether the button is to display the selected item title, and text to display if no item is selected, or if the selected item title is not to be shown.
  3. We want the control to send a notification when its value changes; to do this, we make it a subclass of UIControl, and allow the application to set targets to be notified on the ValueChanged control event.

Going from there, a skeleton of the control starts to look something like this:

class KFPopupSelector: UIControl {
    enum Option {
        case Text(text:String)
    }

    /** The options the user has to choose from */
    var options: [Option] = [] 
    
    /** The currently selected value */
    var selectedIndex: Int? = nil

    /** The text to display on the button if no option is selected */
    var unselectedLabelText:String = "--"

    /** if true, replace the button's text with the currently selected item */
    var displaySelectedValueInLabel: Bool = true

    // -------- The TableViewController used internally in the popover
    
    class PopupViewController: UITableViewController {
       //  ...
    }
    
    var currentlyPresentedPopup: PopupViewController? = nil

    // User interface components
    private let button = UIButton.buttonWithType(.System) as! UIButton

    override func intrinsicContentSize() -> CGSize {
        return button.intrinsicContentSize()
    }

    // Handle a button tap
    func buttonPressed(sender: AnyObject?) { ... }
}

There are a few things to note there; rather than storing options as Strings, we have defined an enum named Option (within KFPopupSelector's namespace). Currently it has only one option, which wraps a String, but it will, in future, allow for the addition of options which consist of something other than a string. I have also chosen to define the view controller class, PopupViewController, in the control's internal namespace, rather than in a separate file; this is something possible in Swift, and as the view controller is both intimately tied to the control which launches it and fairly uncomplicated in its functionality, separating it out made little sense. Finally, we define the intrinsicContentSize method, making it return the button's content size; we want the control to hug the button, and if the button dimensions change (due to changes in its label), we want to push that out to any autolayout constraints the button is connected to.

As this control is fairly compact, all of its code is inside the KFPopupSelector class; as such, all other code fragments in this article will be implicitly inside this class.

Setting up the control

When the control is loaded from a storyboard, we need to set up its components and wire up event handlers; the code which does this is the below:

    override func awakeFromNib() {
        button.setTitle(labelDecoration.apply(unselectedLabelText), forState: .Normal)
        self.addSubview(button)
        button.frame = self.bounds
        button.autoresizingMask = .FlexibleHeight | .FlexibleWidth
        
        button.addTarget(self, action: Selector("buttonPressed:"), forControlEvents:.TouchDown)
    }

Note that we call the buttonPressed: method on TouchDown, not TouchUpInside; we want to show the popover when the user touches the button, rather than when they lift their finger from it (as the normal button behaviour is).

(Also, for the purposes of this example, we will assume that the control will always be constructed from a NIB or storyboard; to manually construct one, we would call the same functionality from init(frame:).)

Handling button taps

When the user taps the button, we need to create and display our popover; which happens like so:

    func buttonPressed(sender: AnyObject?) {
        if options.count > 0 {
            let pvc = PopupViewController(style: UITableViewStyle.Plain)
            pvc.options = options
            pvc.itemSelected = { (index:Int) -> () in 
                pvc.dismissViewControllerAnimated(true) { 
                    self.currentlyPresentedPopup = nil 
                    self.selectedIndex = index
                }
            }
            pvc.modalPresentationStyle = .Popover
            currentlyPresentedPopup = pvc
            
            if let pc = pvc.popoverPresentationController {
                pc.sourceView = self
                pc.sourceRect = button.frame
                pc.permittedArrowDirections = .Any
                pc.delegate = self
            
                viewController!.presentViewController(pvc, animated: true) {}
            }
        }
    }

PopupViewController is the UITableViewController subclass we hinted at earlier; here, we allude to it having two instance variables: a copy of the options, and itemSelected, which is a callback function called with the index of whichever item the user has tapped. We fill these, threading through the control's options, and passing a closure which will handle the user having tapped a menu item (i.e., set the selected index and close the popover). We also add a didSet handler to the control's selectedIndex variable, to send out the appropriate notification, and update the button label if necessary:

    var selectedIndex: Int? = nil {
        didSet {
            updateLabel()
            sendActionsForControlEvents(.ValueChanged)
        }
    }

 . . .

    func updateLabel() {
        if selectedIndex != nil && displaySelectedValueInLabel {
            switch (options[selectedIndex!]) {
            case .Text(let text): buttonText = text
            }
        } else {
            buttonText = unselectedLabelText
        }
    }

(buttonText is another variable getter/setter, which, for convenience, wraps UIButton's setTitle:forState:, and also handles different title decoration options; for more information, see the source code.)

Finding the view controller

One thing you may have noticed in the buttonPressed method is the last line, reading:

    viewController!.presentViewController(pvc, animated: true) {}

We have not defined what viewController is. However, we know that, to present a view controller, we need to do so by calling a method on the current view controller. Which is easy to do if we're doing so from within the view controller, but a tad trickier when the code is encapsulated into a UIView subclass. View controllers are a higher level of abstraction than views; while views deal with concrete interface elements, view controllers deal with the aggregation of those into specific screens or tasks; and normally, there is no reason for views to know about view controllers. However, this is one of those exceptions, in which a view needs to reach up to the higher level to present a temporary view controller. So how do we obtain this?

A naïve solution may be to make it an instance variable, and require the application to fill it in, either by linking it in the storyboard or providing it at view controller setup time. However, this is messy and cumbersome. There is a better way; it is possible to find the current view controller by walking up the responder chain. As such, we can define a magic viewController variable which gives us the view controller, like so:

    private var viewController: UIViewController? {
        for var next:UIView? = self.superview; next != nil; next = next?.superview {
            let responder = next?.nextResponder()
            if let vc = responder as? UIViewController {
                return vc
            }
        }
        return nil
    }

More on PopupViewController

Until now, we have mostly glossed over PopupViewController, the view controller that sits in the popover. And, for the most part, it is fairly straightforward; if you've ever worked with table views in iOS, you'll find it familiar. There are a few details worthy of remark, and below is an abridged version of PopupViewController highlighting them. (I have omitted the usual UITableViewDataSource methods, as those are fairly straightforward.)

    class PopupViewController: UITableViewController {
        let minWidth: CGFloat = 40.0
        var optionsWidth: CGFloat = 40.0
        
        private let tableViewFont = UIFont.systemFontOfSize(15.0)

        var options: [Option] = [] {
            didSet {
                optionsWidth = options.map { 
                    $0.intrinsicWidthWithFont(self.tableViewFont) 
                }.reduce(minWidth) { max($0, $1) }
            }
        }

        var itemSelected: ((Int)->())? = nil
        
        override var preferredContentSize: CGSize { 
            get {
                tableView.layoutIfNeeded()
                return CGSize(width:optionsWidth+32, height:tableView.contentSize.height)
            }
            set {
                println("Cannot set preferredContentSize of this view controller!")
            }
        }
        
        override func viewWillAppear(animated: Bool) {
            super.viewWillAppear(animated)
            tableView.scrollEnabled = (tableView.contentSize.height > tableView.frame.size.height)
        }
        
        override func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
            itemSelected?(indexPath.row)
        }
    }

The main things to note have to do with dealing with the view controller's size. As it is presented in a variable-sized popover, iOS queries our view controller's preferredContentSize for an ideal size. We obtain this size by a two-step process: the height is calculated by making the table view lay itself out and getting the height of its internal scrollable area. We calculate the width is calculated when the list of options is set, by finding the widest option (using map and reduce); we then add 32 to this (as there are 16 points on each side of the label in a standard UITableViewCell). To assist in calculating the width, we add an intrinsicWidthWithFont method to the Option enum, like so:

    enum Option {
        case Text(text:String)
        
        func intrinsicWidthWithFont(font: UIFont) -> CGFloat {
            switch(self) {
            case Text(let t): return NSString(string:t).boundingRectWithSize(
                    CGSize(width:1000, height:1000), 
                    options:.allZeros, 
                    attributes:[NSFontAttributeName: font], 
                    context:nil
                ).width
            }
        }
    }

In the viewWillAppear method, we check if the table view's contents fit within its screen space, and if so, disable scrolling (having the menu move as the user touches it would look a tad disconcerting). If the menu is too big for the popover, scrolling is enabled.

Finally, when the user selects a cell, we just call the callback which was passed.

Making it draggable

So now we have the basics of the popup selector control working; when the user taps the button, it shows a menu in the popover. They can then tap an item, which will close it, set the control's selectedItem, and send out a valueChanged control event. Which is almost what we want. One more thing we'd like to have would be to allow the user to select an item with one gesture; rather than tapping the button and then tapping the item, the user should be able to put their finger on the button, drag to the item in the newly opened popover and release their finger, selecting it. As UITableView doesn't handle drags originating from outside its bounds (not to mention before it was created), we will need to do this manually; and the way we will do so is by attaching a UIPanGestureRecognizer to the control.

We add one line to awakeFromNib:

    override func awakeFromNib() {
.....
        self.addGestureRecognizer(UIPanGestureRecognizer(target: self, action: Selector("dragged:")))
    }

And define the drag handler as follows:

    func dragged(sender: UIPanGestureRecognizer!) {
        if let tableView = currentlyPresentedPopup?.tableView {
            switch(sender.state) {
            case .Changed:
                if let popupContainer = tableView.superview {
                    let pos = sender.locationInView(tableView)
                    if let ip = tableView.indexPathForRowAtPoint(pos) {
                        tableView.selectRowAtIndexPath(ip, animated: false, scrollPosition:.None)
                    }
                }
            case .Ended:
                if let ip = tableView.indexPathForSelectedRow() {
                    currentlyPresentedPopup!.dismissViewControllerAnimated(true) { 
                        self.currentlyPresentedPopup = nil
                        selectedIndex = ip.row
                    }
                }
            default: break
            }
        }
    }

When the drag position moves, it checks if it hits a table row, and if so, selects it; when it ends, if a row has been selected, it stores its value in the control, and closes the popover.

Further steps

The KFPopupSelector control, as described here, performs a simple case of wrapping a popover menu into a control; however, there is plenty of room for expansion.

One obvious place to expand would be to allow options for values other than strings; images would be one possibility, or colours from a palette. This would involve adding cases to the Option enum, like so:

    enum Option {
        case Text(text:String)
        case Image(img: UIImage)
    }

...and, of course, making the appropriate changes in table view cell creation, width estimation and such.

Another possibility would be to replace UITableView with UIContainerView, allowing non-vertical layouts. This would be handy if the options are images or colours, which may be laid out on a grid, or for doing horizontal menus of short pieces of text, as seen in the iOS cut/paste popover.

cocoa touch ios swift uipopoverpresentationcontroller uitableview 0

2015/5/25

When self-sizing UITableView cells don't

One of the advances in iOS 8 was self-sizing UITableView cells. In earlier versions of iOS, if one wanted a table view whose cells' height varied, one had to explicitly calculate the height for each cell, providing a method which returned it; a process involving considerable string-measuring. Since iOS 8, this is no longer necessary; it is now possible to set a UITableView's rowHeight to a new magic value, UITableViewAutomaticDimension; this causes the table view to evaluate each cell's auto-layout constraints, determining its size. Of course, this means that one has to design one's custom cells in such a way that the constraints “push outwards” on the top and bottom edges of the content view, expanding it as the intrinsic sizes of the contained subviews increase. Still, that makes auto-sizing table view cells a lot simpler, especially for complex cells; in theory, at least.

This mechanism is not without its problems. There is an intermittent bug which, in some instances, causes cells to not be sized until the second time they are shown. In other words, when the cell first appears, it is in the default size it is on the storyboard, and any text that does not fit on labels is truncated. If the user scrolls the cell off the screen and then scrolls back to it, it reappears properly sized. Or, taking an example (taken from my MPDluxe MPD controller app):

The above view is a UITableView showing the contents of a directory on a music server. The left image is what appears when the user first enters the directory; while the second cell is sized correctly, the third cell is not, and the title is cut off. The right image is what appears if the user scrolls down (moving the top cells off the screen) and then scrolls back up; here, the third cell is sized properly.

Given that a second displaying operation causes the cell's size to be calculated properly, one workaround may be to force the cells to be reloaded when the view appears; i.e., adding to the view controller:

    override func viewDidAppear(animated: Bool) {
        super.viewDidAppear(animated)
        self.tableView.reloadData()
    }
It turns out that this doesn't work; reloadData is called too early, and is coalesced into the initial load, having no effect. So let's add a delay:
    override func viewDidAppear(animated: Bool) {
        super.viewDidAppear(animated)
        dispatch_after(
            dispatch_time(DISPATCH_TIME_NOW, Int64(0.1 * Double(NSEC_PER_SEC))),
            dispatch_get_main_queue()) {
                self.tableView.reloadData()
        }
    }
That's better; the cells that appear at the start are now sized correctly. However, if there are any mis-sized cells below the first screenful, they will still appear incorrectly sized the first time the user scrolls to them. Which means that we need something subtler than reloading the whole table view at start time.

Fortunately for us, the UITableViewDelegate protocol has an optional method titled tableView:willDisplayCell:forRowAtIndexPath:. As the name suggests, if defined, this is called just before a cell is displayed. Which would allow us to force a reload of the cell.

override func tableView(tableView: UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath indexPath: NSIndexPath) {
    dispatch_after(
        dispatch_time(DISPATCH_TIME_NOW, Int64(0.1 * Double(NSEC_PER_SEC))),
        dispatch_get_main_queue()) {
             tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)
        }
}
Which does the trick; the cells appear with the correct size now. However, scrolling is also noticeably slower. The problem is, each cell is reloaded every time it appears, whether it has been resized or not. So the next step is to add a memory of which cells have been reloaded, and not reload any cell more than once:
var alreadyReloaded: Set = Set()

override func viewWillAppear(animated: Bool) {
    super.viewWillAppear(animated)
    alreadyReloaded = Set()
}

...

override func tableView(tableView: UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath indexPath: NSIndexPath) {
    // we assume that there will never be more than 2^16 sections or rows in a section
    let index = indexPath.row | (indexPath.section << 16)
    if(!alreadyReloaded.contains(index)) {
        alreadyReloaded.insert(index)
        dispatch_after(
            dispatch_time(DISPATCH_TIME_NOW, Int64(0.1 * Double(NSEC_PER_SEC))),
            dispatch_get_main_queue()) {
                tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)
            }
    }
}
This will cause each cell to be reloaded only once.

Of course, this is just a beginning; if the user scrolls down rapidly, it will still trigger a flurry of reloads. The next step would involve application-specific logic, checking whether a cell can be eliminated as a candidate for reloading based on model information (for example, is it a type of cell which suffers from the problem, or is the information in the model particularly long).

autolayout ios uitableview workaround 0

2015/3/15

Swift snippets: flatMap and layout constraints

Since version 6, iOS has had a constraint-based layout engine for laying out views The constraint-based layout engine in iOS is considerably more powerful than the old system of auto-layout hints, allowing reasonably sophisticated flexible layouts to be specified purely as systems of constraints. However, it can be cumbersome to set up if creating all constraints individually; any reasonably complicated layout will soon have dozens of NSLayoutConstraint(item:attribute:relatedBy:toItem:attribute:multiplier:constant:) lines padding out its construction code, making one wonder why not just cut the Gordian knot and write code to manually lay out the view, as in the old days?

Fortunately, Apple provide a shortcut: the NSLayoutConstraint.withVisualFormat method; which takes a string describing the relationships between elements in an ASCII-art-style syntax known as the Visual Format Language, a few options and a dictionary of elements and emits a list of NSLayoutConstraints, as so:

let viewsDict:[NSObject:AnyObject] = [
    "lBtn" : leftButton,
    "rBtn" : rightBtn,
    "title" : titleLabel
]
let constraints = NSLayoutConstraint.constraintsWithVisualFormat("H:|-12-[lBtn(30)]-6-[title]-6-[rBtn(30)]-12-|", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict)
myView.addConstraints(constraints)

As implied, each constraintsWithVisualFormat call takes a line of visual format language and produces an array of zero or more constraints; the line above, for example, would produce six; four distance constraints and two size constraints. However, one such line is rarely enough to unambiguously specify the constraints for a view and its contents; most layouts would require more than one line of visual format language to specify their constraints. The above, for example, covers only horizontal constraints; adding vertical ones to the mix would involve a second line, like so:

let constraints = NSLayoutConstraint.constraintsWithVisualFormat("H:|-12-[lBtn(30)]-6-[title]-6-[rBtn(30)]-|", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict) + 
    NSLayoutConstraint.constraintsWithVisualFormat("V:|-10-[title(20)]", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict)
myView.addConstraints(constraints)
Which gives two more constraints on the title label view: a distance from the top edge of the superview and a height. But what about the buttons?
let constraints = NSLayoutConstraint.constraintsWithVisualFormat("H:|-12-[lBtn(30)]-6-[title]-6-[rBtn(30)]-|", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict) + 
    NSLayoutConstraint.constraintsWithVisualFormat("V:|-10-[title(20)]", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict) +
    NSLayoutConstraint.constraintsWithVisualFormat("V:|-5-[lBtn(30)]", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict) +
    NSLayoutConstraint.constraintsWithVisualFormat("V:|-5-[rBtn(30)]", 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict)
myView.addConstraints(constraints)
All of which soon starts to get somewhat unwieldy; there's a lot of repeated boilerplate there, which suggests that one could refactor it.

We could minimise the boilerplate by putting the visual format strings in an array of strings and mapping over them with constraintsWithVisualFormat. That would give us an array of arrays of constraints, which we could then flatten using reduce, like so:

let visualConstraints = [
  "H:|-12-[lBtn(30)]-6-[title]-6-[rBtn(30)]-|",
  "V:|-10-[title(20)]", ...
]
let constraints = visualConstraints.map { 
  NSLayoutConstraint.constraintsWithVisualFormat($0, 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict)
}.reduce([], { $0 + $1 })
myView.addConstraints(constraints)
Which is somewhat better, though it can be improved. As of Xcode 6.3, arrays (and optionals) in Swift will have a new operation named flatMap, which combines the map and flatten steps. In short, where a map takes a container of some values of type A and a function that converts an A to a B and returns a container of the same number of values of type B, flatMap takes the same array and a function that converts an A to a container of zero or more Bs, and returns a container of some number of Bs. In any case, with flatMap, the above code reduces to:
let visualConstraints = [
  "H:|-12-[lBtn(30)]-6-[title]-6-[rBtn(30)]-|",
  "V:|-10-[title(20)]", ...
]
let constraints = visualConstraints.flatMap { 
  NSLayoutConstraint.constraintsWithVisualFormat($0, 
        options:NSLayoutFormatOptions(0), metrics:nil, views:viewsDict)
}
myView.addConstraints(constraints)
flatMap is a useful operation, and one whose uses one can see in many places. In general, whenever a process produces zero or more items of output for each input, one wants to use a flatMap to handle them. Swift is also introducing flatMap on Optionals (which, of course, may be seen as a container holding zero or one items of a type), where it can be used for chaining a number of functions which may or may not yield a value:
func getCurrentUserIcon(session: Session?) -> UIImage? {
  return getUser(session).flatMap { getIconForUser($0) }
}
This is a little like Swift's optional chaining, with the key difference that, while optional chaining is limited to calling the underlying objects' methods, flatMap can apply any expression yielding an Optional; a move away from the object-oriented paradigm of objects and methods towards more functional techniques.

Unsurprisingly, flatMap is much more common in functional programming. The presence of a flatMap operation is one of the defining criteria of a pattern known as the monad, which, in a functional paradigm, can be used to define everything from container types to asynchronous operations to ways of compartmentalising state in functions without side-effects, in a way that follows consistent laws. Languages like Haskell and Scala use monads extensively, defining the relevant types in a consistently monadic fashion. And while Swift is not a functional language per se, it has been speculated for a while that it may be moving in an increasingly functional direction (albeit perhaps sufficiently gradually as not to alienate old Objective C hands); the arrival of flatMap could be more grist to this mill.

autolayout functional programming ios monads swift 0

2013/9/17

D2UI, or data-driven interfaces in iOS

The D3 JavaScript library allows one to create and manipulate arbitrary elements on a web page from data in an elegantly declarative fashion, making it easier to implement quite sophisticated dynamic data visualisations. Recently, I was thinking about whether the ideas behind D3 could translate to iOS and Objective C, and ended up writing a small library and example application to explore the idea.

 [...]

cocoa touch coreanimation d3 data visualisation ios objective c 0

2013/8/2

Automatically sizing CATextLayer to fit

When developing on iOS, I am a big fan of CoreAnimation, and particularly the CALayer and its subclasses; they're lighter in weight than UIView, carrying less baggage, and are a quick way to display all sorts of elements in a user interface.

CALayer has a number of useful subclasses, among them CATextLayer, which displays text in an arbitrary font and size* within its bounds. One shortcoming of CATextLayer, however, is that it does not provide any means of measuring the dimensions of its contents, requiring you to guesstimate them and size the layer to fit, or else pre-measure the string before sizing your layer. This is complicated somewhat by the fact that CATextLayer can accept font settings in several forms (string font name, CoreText CTFont or CoreGraphics CGFont), none of which are the convenient UIFont object.

Having had reason to create a precisely-sized CATextLayer recently, I looked into the issue and have written a small category extending CATextLayer, adding a method for setting its bounds to neatly encompass its text.

 [...]

calayer catextlayer cocoa coreanimation coretext ios objective c 0

This will be the comment popup.
Post a reply
Display name:

Your comment:


Please enter the text in the image above here: