26
votes

In my mind, these situations are all parallel:

  • My view controller presented another view controller fullscreen, which has now been dismissed

  • My view controller presented another view controller not fullscreen, which has now been dismissed

  • My view controller presented a popover, which has now been dismissed

  • My view controller pushed another view controller, which has now been popped

In every case, my view controller ceased to be the "frontmost" view controller, and then became "frontmost" again. I find it curious that iOS has no single blanket "became frontmost" event sent to my view controller that covers all these situations.

I think I can cover each of those cases individually, and I think those are all the cases I need to cover, but the resulting code is confusing and scattered:

  • viewDidAppear detects popping of a pushed view controller and dismissal of a fullscreen presented view controller

  • popover delegate message detect dismissal of a popover

  • not sure what detects dismissal of a nonfullscreen presented view controller

How do people handle this coherently and elegantly?

2
became frontmost – I have very consistent results with UIViewController's becomeFirstResponder and resignFirstResponder. See here. It's not working for child view controllers, though. - bteapot
@bteapot I sure never thought of that, I'll look into it, thanks! - matt
Good question. I've been struggling with this for a while (keep punting on it), hoping to figure out a way to inject a proxy responder object between controllers (swizzling?), to then detect these transitions without spilling code into the "otherwise context-free" controllers. - Chris Conover

2 Answers

12
votes

What the cases have in common is not the appearance of the original view controller but the disappearance of the presented/pushed view controller. Therefore, one simple and clear solution seems to be a protocol-and-delegate architecture. Declare a pair of protocols, as follows:

protocol Home : class {
    func comingHome()
}
protocol Away : class {
    var home : Home? {get set}
}
extension Away where Self : UIViewController {
    func notifyComingHome() {
        if self.isBeingDismissed || self.isMovingFromParent {
            self.home?.comingHome()
        }
    }
}
  • The home view controller must adopt Home, and must set each view controller's home to self when it presents or pushes it.

  • The presented or pushed view controllers must adopt Away, and must implement viewWillDisappear as follows:

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        self.notifyComingHome()
    }
    

This works for the four cases listed in the question. It's a pity, though, that Cocoa Touch doesn't do this for you automatically.


EDIT This approach has become even more important in my apps now that iOS 13 has forced nonfullscreen presented view controllers upon us. Also, I have subclassed UIAlertController so that it conforms to Away.

1
votes

One solution could be to take the Coordinator approach like in a MVVM-C style architecture. You never directly change view hierarchy in a VC but always call into the Coordinator to do it for you. coordinator.showDetails(...)

Additionally you define a viewDidBecomeForemost method in your VCs that the coordinator can invoke when returning to a VC.