Skip to content →

Category: User Interface

Text Field Advancing Protocol

In Keyboard Responsive View Controller, I discussed a demo project that presented a UIViewController extension for automatically moving the active text field into view when obscured by the keyboard. Not discussed there was functionality included in that project for advancing the cursor to the next text field when the user taps the Return key. I discuss it now.

By default, when the user taps the Return key on the iOS keyboard (in this project configured as a Next or Done button), nothing happens. By conforming your UIViewController to the TextFieldAdvancing protocol, your controller gains a text field auto-advance functionality. As a result, when the user taps Return, the focus automatically moves to the next field in the sequence. Optionally, if it’s the last field on the view, it will instead segue to a new scene.

This protocol does require your controller be registered as a delegate of each text field, which is easiest done via the storyboard. Just control-drag from the text field to the view controller button at the top of the scene, and select the “delegate” outlet. You can also do this programmatically with myTextField.delegate = self (this functionality is included in the Keyboard Responsive View Controller extension).

@objc protocol TextFieldAdvancing: UITextFieldDelegate {
  var textFieldSegueIdentifier: String? { get }
}

extension UIViewController {

  /// In response to the user tapping the Return key in a text field, calls upon `advanceFirstResponder(from:)`.
  func textFieldShouldReturn(_ textField: UITextField) -> Bool {
    advanceFirstResponder(from: textField)
    return true
  }

  /// Advances first responder to the next text field in the `tag` sequence. For the last text field in the sequence, advances to the next scene via the segue given by `textFieldSegueIdentifier`.
  func advanceFirstResponder(from textField: UITextField) {
    guard let vc = self as? TextFieldAdvancing else { return }
    if let nextTextField = view.viewWithTag(textField.tag + 1) {
      nextTextField.becomeFirstResponder()
    } else {
      if let textFieldSegueIdentifier = vc.textFieldSegueIdentifier {
        performSegue(withIdentifier: textFieldSegueIdentifier, sender: nil)
      }
    }
  }
}

The @objc designation on line 1 is required in order for the Swift protocol’s UITextFieldDelegate method textFieldShouldReturn(_:) to be seen and called by the Objective-C UITextField. Without that, tapping Return has no effect.

Turning to the extension, in a perfect Swift world, this would be a protocol extension, with line 5 reading:

extension TextFieldAdvancing where Self: UIViewController {

However, the UITextFieldDelegate calls are similarly never made.  While it runs, the compiler warns:

Non-@objc method textFieldShouldReturn does not satisfy optional requirement of @objc protocol UITextFieldDelegate.

Matthew Seaman provides a good discussion of this problem, summing up the issue so:

@objc functions may not currently be in protocol extensions. You could create a base class instead, though that’s not an ideal solution.

No, not ideal. Using a base class effectively eliminates the utility of using a protocol in the first place. And because we can’t designate that this extension is of TextFieldAdvancing, we must explicitly test for conformance on line 15.

Let that not detract from the fact, however, that this protocol and extension do work. If you want the user to be able to advance automatically through text fields managed by your view controller, simply conform to TextFieldAdvancing, like so:

class MyViewController: UIViewController, TextFieldAdvancing {
  var textFieldSegueIdentifier: String? = "mySegue"
}

And don’t forget to assign the controller as the delegate of each text field!

Leave a Comment

Keyboard Responsive View Controller

keyboardresponsivedemoHere’s a quick-n-easy UIViewController extension that will make any view with UITextFields on it responsive to the keyboard, moving text fields into view when they would otherwise be obscured by it…without requiring scroll views or other storyboard configurations.

I put this together after implementing the Apple approach using scroll views: Moving Content that is Located Under the Keyboard. I found the overhead associated with reconfiguring my existing project views with scroll views significant and the results inconsistent between views. This approach requires no changes to existing views, and needs but one line of code in your controller to enable the feature (plus a couple “optional” ones).

You will find the Swift 3 demo extension project on GitHub in the extension branch (there’s another branch we’ll get to momentarily).

Note, in the real world you’d do better to implement this particular layout in a UITableViewController; I use it here simply for demonstration purposes. This technique is intended more for content that doesn’t lend itself to a tabular or scrolling view. (Also, for simplicity, I forego the universal layout machinations; this one will look decent on an iPhone 6/7 or 6/7 Plus.)

Here’s the extension.

extension UIViewController {

  /// Returns the text field currently identified as the view's first responder, or `nil` if there is no such first responder.
  func activeTextField(within view: UIView?) -> UITextField? {
    guard let view = view else { return nil }
    if view.isFirstResponder {
      return view as? UITextField
    }
    for view in view.subviews {
      if let activeTextField = activeTextField(within: view) {
        return activeTextField
      }
    }
    return nil
  }


  /// In response to keyboard presentation, animates the active text field into view if obscured by the keyboard.
  func keyboardWillShow(_ notification: NSNotification) {

    // The distance between the bottom of the text field and the top of the keyboard
    let gap: CGFloat = 20

    if let activeTextField = activeTextField(within: view),
      let keyboardFrame = (notification.userInfo?[UIKeyboardFrameEndUserInfoKey] as? NSValue)?.cgRectValue {

      // Calculate delta between upper boundary of keyboard and lower boundary of text field
      let textFieldFrame = activeTextField.superview!.convert(activeTextField.frame, to: view)
      let textFieldBound = textFieldFrame.origin.y + textFieldFrame.size.height + gap
      let keyboardBound = keyboardFrame.origin.y
      let viewShift = min(keyboardBound - textFieldBound, 0) // Don't shift if keyboard doesn't cross text field boundary

      // Shift the view
      var viewFrame = view.frame
      viewFrame.origin.y += viewShift - viewFrame.origin.y // Account for previous shift
      UIView.animate(withDuration: 0.5) {
        self.view.frame = viewFrame
      }
    }
  }

  /// In response to keyboard dismissal, animates the view back to its original position.
  func keyboardWillHide(_ notification: NSNotification) {
    var vwFrame = view.frame
    vwFrame.origin.y = 0
    UIView.animate(withDuration: 0.5) {
      self.view.frame = vwFrame
    }
  }

  /// Enables keyboard responsiveness to text fields, animating the view such that the currently active text field is not obscured by the keyboard. Call this method from `viewDidAppear(_:)`.
  func activateKeyboardResponsiveTextFields() {
    NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow(_:)), name: NSNotification.Name.UIKeyboardWillShow, object: nil)
    NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillHide(_:)), name: NSNotification.Name.UIKeyboardWillHide, object: nil)
  }

  /// Disables keyboard responsiveness to text fields. Call this method from `viewWillDisappear()`.
  func deactivateKeyboardResponsiveTextFields() {
    NotificationCenter.default.removeObserver(self, name: NSNotification.Name.UIKeyboardWillShow, object: nil)
    NotificationCenter.default.removeObserver(self, name: NSNotification.Name.UIKeyboardWillHide, object: nil)
  }
}

The view controllers you wish to take advantage of this behavior need to call upon those last two methods, as follows:

override func viewDidAppear(_ animated: Bool) {
  activateKeyboardResponsiveTextFields()
}

override func viewWillDisappear(_ animated: Bool) {
  view.endEditing(true)
  deactivateKeyboardResponsiveTextFields()
}

The call to endEditing() on line 6 is not strictly necessary, but I found overcame some less-than-premium keyboard presentation behavior when unwinding to a controller that had previously segued with the keyboard visible.

Note that in the extension itself, beginning on line 4, we cannot obtain the activeTextField the same way Apple does in their example code, that is, by using the UITextFieldDelegate methods textFieldDidBeginEditing(_:) and textFieldDidEndEditing(_:). This is because they use a stored property to capture the active field. Thus the extension must find it programmatically by recursively traversing the view’s subviews, looking for the one that isFirstResponder.

This activeTextField(within:) method is called once each time the keyboard shows, which actually happens each time a field becomes the first responder, such as when the focus moves from one text field to the next, even if the keyboard is already present. This process happens so quickly within the run loop, however (even with this activeTextField(within:) traversal), that the keyboard doesn’t actually dismiss and reappear.

Where could you go from here?

While this extension is arguably Swifty and lightweight, there is some overhead we carry into each view controller taking advantage of it. We can eliminate that overhead by converting the extension into a subclass of UIViewController. While perhaps non-Swifty (classes are so heavyyy), it does have these benefits:

  • Replaces what amounts to a computed activeTextField property with a stored property (however negligible that processing requirement may be).
  • Eliminates the explicit calls to (de) activateKeyboardResponsiveTextFields(). Instead, one must only subclass KeyboardResponsiveViewController.

Take a look at the subclass branch of the repo for this implementation.

Leave a Comment

Page View Controller in a Container View

Late one evening this week I decided to turn Netflix off and see what I could cobble together with regard to a feature a teammate of mine was working on, namely, using UIPageViewController to provide paginated content.

PageViewControllerDemoAs seen in the animation, for us there are some key characteristics of the targeted implementation. These include:

Swift 3 language and UIKit features illustrated but not specifically discussed include:

  • Protocols
  • Switch case value bindings akin to if let value = value as? SomeType
  • String splitting using map(); substrings
  • UITableViewController and UITableViewControllerDataSource
  • Storyboard and programmatic instantiation of view controllers
  • UIView.animate(withDuration:animations:)

If any of these topics interest you and you want a quick fix, take a look at the project on GitHub, written in Swift 3 (updated for Swift 4). Have specific questions? Keep reading.

FAQ

  • How do I provide paginated content? There’s a storyboard piece and a programmatic piece. In summary, on the storyboard you drop in and hook up a Page View Controller object into your scene flow and add a content object of your choosing. Programmatically, you need only implement a couple UIPageViewControllerDataSource methods … and provide the initial view controller. See PageViewController.swift for that implementation. Details below.
  • How do I use a page scroll rather than curl transition? In the Attributes Inspector for the Page View Controller storyboard scene, set “Transition Style” to “Scroll”.
  • How do I add a page indicator? Implement UIPageViewControllerDataSource methods presentationCount(for:) and presentationIndex(for:); see PageViewController.swift. If you don’t want a page indicator, don’t implement these methods.
  • How do I set the color of the page indicator dots? See PageViewController viewDidLoad():
    let pageControl = UIPageControl.appearance(whenContainedInInstancesOf: [PageViewController.self])
    pageControl.pageIndicatorTintColor = .lightGray
    pageControl.currentPageIndicatorTintColor = .black
    
  • How do I embed a paginated subview? The storyboard is all you need. The process I follow:
    1. Drop a Container View onto the containing view. If you’re good with the tag-along view controller, stop here.
    2. Otherwise, delete the tag-along view controller.
    3. Add the desired controller to the storyboard.
    4. Control-drag from the container to the controller.
    5. Select the “Embed” segue.
  • How do I use a segmented control to switch between subviews? My approach is through manipulation of each subview’s hidden property, accessed by @IBOutlet connection. See MainViewController.swift.
  • How do I reuse a view controller in a storyboard? I recommend embedded Container Views (they’re awesome!). In this project, I have one container view with an Embed segue directly to the content table view controller; then I have a second container view with an Embed segue to the Page View Controller that is programmatically connected to the same table view controller.
  • How do I access a container-embedded view controller? Rather simply…when you know how. The trick is to override prepare(for:sender:) in your container view controller. By doing so, you get access to the destination (embedded) view controller via the provided UIStoryboardSegue. See MainViewController.swift.

Details

Okay, let’s dive into some details. Keep in mind the context of this discussion is the specific implementation as given on GitHub.

Storyboard

Assuming you know the basics of Interface Builder storyboarding, here are some things to be aware of:

  • There are two container views on the project storyboard; although, because they’re stacked, you only see one. The first, named “Paged Container View”, has an embed segue to the Page View Controller scene. The second, “Unpaged Container View”, has an embed segue to Table View Controller.
  • Table View Controller has a Storyboard ID of “TableViewController”, which PageViewController makes use of when serving up paged view controllers.
  • There is no direct connection between Page View Controller and Table View Controller on the storyboard. As just alluded to, that is done programmatically in PageViewController.
  • The Table View Controller has one basic prototype cell matched with a class defined in TableViewController.swift named BasicCell.

Page View Controller

The back end of the Page View Controller storyboard scene is a UIPageViewController-subclassed PageViewController that conforms to the UIPageViewControllerDataSource protocol, much the way UITableViewController now does inherently for its data source and delegate.

At a minimum, a UIPageViewController needs only two things to get paging working:

  1. The plugged-in viewControllerAfter and viewControllerBefore data source methods.
  2. The initial view controller (or view controllers if you’re presenting two pages at at time).

Our page content is presented by a TableViewController. Rather than pre-populating a collection of controllers for all pages, I serve them up on-demand one at a time.

PageViewController maintains no state of its own as concerns which page we’re currently viewing. We leave that to each TableViewController via its section property. In viewDidLoad() we initialize the first Table View Controller’s section to zero, and the page view controller’s data source methods take it from there.

When UIPageViewController asks its data source for the previous or next page, we query the current view controller’s section value to do some bounds checking and initialize the new controller. If within bounds, we return the new controller; otherwise, we return nil.

Table View Controller

The reusability of this controller in two contexts hinges entirely on the optional section property:

  • When non-nil, as set only by the PageViewController, we can know the data is paginated and should only serve up one section, which one being determined by this section value.
  • When nil (i.e., left in its initial state), we know the controller is being used by the directly embedded container view, and needs to serve up data for all sections.

Functionally, this TableViewController is entirely a UITableViewDataSource, providing the bare minimum number of sections, rows per section, section title (not necessary, but useful), and cells. It calls upon an abstracted BasicTableDataModel for those values. This model is assigned by the PageViewController, which it receives from the MainViewController.

Anytime these methods reference the section, they use the sweet nil-coalescing operator to give priority to the optional section property, and failing that, the parameterized section or indexPath value.

Page Indicator

Actually managed within the PageViewController, the page indicator is made possible by implementing two additional UIPageViewControllerDataSource methods: presentationCount(for:) and presentationIndex(for:).

They’re straightforward enough. The only oddity is presentationIndex(for:) is called after viewControllers is initialized to an empty array, but before it is populated. Thus the reason for the nil and count > 0 checks.

Customization of the indicator, that is, its color, is another peculiarity. UIPageControl utilizes an “appearance proxy”, which implements the UIAppearance protocol.

For this project, it comes down to the three lines of code from viewDidLoad(), as given earlier and repeated here:

let pageControl = UIPageControl.appearance(whenContainedInInstancesOf: [PageViewController.self])
pageControl.pageIndicatorTintColor = .lightGray
pageControl.currentPageIndicatorTintColor = .black

If you were only to have one page indicator across your app or want them all to have the same colors, you can replace the first line with:

let pageControl = UIPageControl.appearance()

And, if follows, you can do that anywhere, such as in the AppDelegate.

Basic Table Data Model Protocol

An update to my original implementation addresses my glossing over how model data might work its way into the table view in the real world.

In this update, I add a BasicTableDataModel protocol and two conforming types (LatinTableDataModel and NumericTableDataModel) that present distinct data for use in the paged and non-paged views.

The MainViewController is now the keeper of the models, passing them down to the container view controllers via the segue method prepare(for:sender:). The PageViewController then passes its assigned model down to the individual TableViewControllers it instantiates.

Wrap Up

Adding a page view controller to your project is as simple as:

  1. Dropping a Page View Controller into your storyboard
  2. Connecting to a UIPageViewController-derived class that implements its data source protocol
  3. Employing an approach for serving up paged view controllers that fits with your use case, which really just comes down to providing a view controller with the page-specific model data it needs to display
  4. Optionally, configuring the page indicator by implementing a couple more data source methods and customizing it to a color suitable for your view.

By way of bonus material, you also got to see how to:

  • Reuse and tailor model data for a single view controller in multiple contexts
  • Use a segmented control to switch view contexts within a single controller.

Good stuff. Now, back to Netflix…

10 Comments

Portrait Orientation: Single Scene

Here’s a slight modification to my prior post, Portrait Orientation: Multiple Scenes. Instead of presenting a set of storyboard scenes in portrait mode for compact-width layouts (iPhone, iPod), you want to present just one of them in portrait.

Override the supportedInterfaceOrientations() in the scene’s root navigation controller (named here as PortraitNavigationController) as so:

class PortraitNavigationController: UINavigationController {
  override func supportedInterfaceOrientations() -> UIInterfaceOrientationMask {
    return visibleViewController?.supportedInterfaceOrientations() ?? .All
  }
}

Then in a custom UIViewController subclass for the individual scenes you wish to keep in portrait orientation, override the following method in the view controller:

class PortraitViewController: UIViewController {
  override func supportedInterfaceOrientations() -> UIInterfaceOrientationMask {
    return .Portrait
  }
}

By default, it’s only the navigation controller that gets asked, “What orientations do you support?” Our subclass forwards that question to the visible scene within the same storyboard. Because the controller for that visible view may not override the supportedInterfaceOrientations() method, nil is a valid response. In that case, we assume .All orientations are supported.

Activate your custom view controller via the “Custom Class” attribute in the desired Interface Builder scenes as you did previously for the navigation controller. This will trigger calls to those scene’s supportedInterfaceOrientations() method. Run it, and you’ll see the respective views will not animate to landscape orientation.

Assigning a Custom View Controller
Assigning a Custom View Controller

But you may see your scene isn’t always in portrait mode. For instance, if you navigate to the view from any preceding or subsequent view controller that is not similarly constrained and is itself in a landscape orientation, you will then see this controller also remains in a landscape orientation. It’s not until you rotate the device back to portrait that it again locks to a portrait orientation. This is likely to be undesirable.

To fix this, automatically force the view to return to portrait by adding this UIDevice call to the viewDidAppear(animated:) method of your view controller:

override func viewDidAppear(animated: Bool) {
  UIDevice.currentDevice().setValue(UIInterfaceOrientation.Portrait.rawValue, forKey: "orientation")
}

Now that’s it.

Note. As noted in the prior post, this is technically a solution for iOS 6 and 7, but not iOS 8 and beyond. Also, you may notice that on the iPad the navigation bar animation is a bit unlike the others when transitioning back to the portrait-only view. These two factors leave me searching for a superior solution. Can you help?

Leave a Comment

Portrait Orientation: Multiple Scenes

Here’s a simple scenario. You need to present a set of storyboard scenes in portrait mode for compact-width layouts (iPhone, iPod). These scenes share a root navigation controller.

Create a custom subclass of UINavigationController and override the supportedInterfaceOrientations() method, like so:

class PortraitNavigationController: UINavigationController {
  override func supportedInterfaceOrientations() -> UIInterfaceOrientationMask {
    return .Portrait
  }
}

Then in the storyboard’s navigation controller, set the “Custom Class” in Interface Builder to your subclassed UINavigationController.

PortraitNavigationController
Assigning a Custom Navigation Controller

That’s it.

On the compact-width devices (the iPhone and iPod), this will prevent a landscape orientation on all scenes presented with that navigation controller’s stack. For the iPad, either orientation will still be supported.

Note. This is technically a solution for iOS 6 and iOS 7, for Apple tells us that “as of iOS 8, all rotation-related methods are deprecated,” although this approach continues to work in iOS 8 and iOS 9 and the documentation for supportedInterfaceOrientations() makes no mention of deprecation. See “Handling View Rotations” in the UIViewController Class Reference for more information. Do you have a pure iOS 9 solution?

Leave a Comment

Container Views

I recently developed a passcode view with core functionality that allows a user to tap in a 6-digit passcode. I then added functionality to support two different modes of operation: new passcode entry and existing passcode entry. I had a single view controller that managed these two modes of operation. The mode was ultimately determined by two different calling view controllers that segued to it.

And it was just too complicated for my tastes.

So I set out this weekend to break it up. I ended up with three controllers: one for the basic passcode-entry functionality, a second for the new-passcode additions, and a third for the existing-passcode additions.

But how to handle this in Interface Builder? Thanks to Xcode 7 and the help of Mike Woelmer, container views was the answer.

Screen Shot 2016-03-05 at 10.29.51 PM
Define Once, Use Twice

As illustrated above, I simply added two additional view controllers to the storyboard, one for each mode of operation, set their Custom Class to one of the new UIViewController subclasses I’d just created, and filled their view with a Container View. Then I embedded the single passcode view controller into each by control-dragging from the container to the passcode controller.

Leave a Comment