A quick tip on managing your child ViewControllers Tabbed Navigations is pretty convenient and fun in iOS. Thanks to the native UITabBarController, a subclass of UIViewController, it doesn’t really need not much setting up other than its child ViewControllers. But after that, admittedly, we do still find ourselves in between some dilemmas managing the child ViewControllers especially when we need access to them from the TabBarController. There are several different ways of accomplishing it depending on several more factors like weight or intention of the tasks, some of them being: Child View Controller positions should be easily changed/switched without much issues but subjective design. Parent TabBarControllers should not have to know much about the child ViewControllers other than the cases they need to communicate. Parent TabBarControllers should be able to easily access and accurately distinguish child ViewControllers from each other. One simple way of tracking the child ViewControllers is through their property. If name comparison is all you need, maybe that will be do? String tabBarItem.title But be careful still. Strings are easy to implement and modify, but also very loose if you don’t pay strict attention to them. Using as a point of comparison can easily result in a lot of false flags without you knowing, so I would stay away from it for now. Strings Another way can be done through . Similar to the title comparisons, you will probably end up with a lot of ‘s and because of this, it is only mostly applicable given no two child ViewControllers share the same type. data types if else Unlike String comparisons, this may save you from accidentally misinterpreting rogue values. But if you go this route, testing the parent UITabBarController will be extra tricky since since relying on strict data types for identifying objects will limit your mocking capabilities. Describing our Tab Items through Protocols and Enums Another way of managing child View Controllers that I’d like to share with you, is through a mix of Swift Enum and Protocol Implementation. By creating a finite set of TabBar identity values for your child ViewControllers to hold, you also improve their testability by giving them a good base for mock or test classes. First, We’ll implement our finite set of identities named through a set of Enum values representing our expected TabBar Items. TabBarType enum TabBarType: String { case featured = "Featured" case accounts = "Accounts" case cart = "Cart" case search = "Search" case none = "None" } This way we can lock down our possible values to make sure we can catch any rogues as early as compile time. Second, we’ll create a short Protocol named to describe an object that holds a value representing them. TabBarChild TabBarType protocol TabBarChild { var tabBarType: TabBarType? { get set } } Third, we’ll make our designated child ViewController classes conform to the new protocol so their parents know how to communicate to them as TabBar children. This can be accomplished in many different ways depending on your team’s preferred , but in this article I can show you a couple. design Solution 1: Extending UIViewController The simpler one is through extending the UIViewController class to conform to the protocol. You basically just assume every UIViewController to be -capable with the drawback of having to design ViewControllers to store/compute the value of a little less conventionally. TabBarChild TabBarChild TabBarType extension UIViewController: TabBarChild { var tabBarType: TabBarType { get { return TabBarType(rawValue: tabBarItem.title ?? "" ) ?? .none } set { tabBarItem.title = newValue.rawValue } } } In this example, I chose to store its value to the ViewController’s . With this, you can easily modify how the ViewController is displayed by simply changing the ‘s value. It is a convenient approach as it also lets you assign/remove properties. Here’s a sample of what it would look like in implementation: tabBarItem.title TabBarType TabBarType //somewhere in you codelet viewController = SearchViewController()viewController.tabBarType = .searchtabBarController.viewControllers.append(viewController) func tabBarController(_ tabBarController: UITabBarController, shouldSelect viewController: UIViewController) -> Bool { if viewController.tabBarType == .search { //do something with the search tab here? } return true } Solution 2: Custom UIViewController Extensions Not a fan of the solution above? Another way is going further and removing ‘s access, the conforming object with an immutable property so their implementation with sort of look like this: TabBarChild set leaving TabBarType protocol TabBarChild { var tabBarType: TabBarType { get } } extension AccountsViewController: TabBarChild { var tabBarType: TabBarType { return .accounts } } This lets you assign properties to your child ViewControllers more securely. On your TabBar management layer, accessing them may look like this: TabBarType //sample UITabBarDelegate callsextension HomeFlowController: UITabBarControllerDelegate { func tabBarController(\_ tabBarController: UITabBarController, shouldSelect viewController: UIViewController) -> Bool { if let tabBarChild = viewController as? TabBarChild, tabBarChild.tabBarType == .accounts { //do something with accounts tab here? } return true } } Since it is agnostic about your child ViewController type, you can easily keep the changes in your ViewController implementation from directly affecting your Tab Management logic. What’s Next? The solutions I presented here can definitely be further expanded so try and work around other possibilities. See which one may work best for you and your team. Would adding more properties/functions to protocol help you better? Or would a more simplified version do the job just right? TabBarChild And if you got your own solutions, please feel free to share them here and I’m very interested to hear about them! You made it all the way here! I hope that you got what you’re looking for when you opened this article. If so, I would very much appreciate it if you would recommend this to your friends ^^ if you have any more questions/feedbacks, please feel free to drop a ! message
