ViewController — esensya, tagakontrol ng screen sa iOS at ang lifecycle nito

Ano ang ViewController?

UIViewController — isang klase mula sa UIKit framework na namamahala sa UIView hierarchy at nagko-coordinate ng display ng data sa screen. Bawat iOS application ay naglalaman ng kahit isang ViewController — root controller ng window. Ang controller ay humahawak ng screen rotations, transitions sa pagitan ng mga screen, at lifecycle na mga kaganapan.

Ang arkitekturang MVC (Model-View-Controller) sa iOS ay ipinapatupad mismo sa pamamagitan ng UIViewController: ang controller ay tumatanggap ng data mula sa modelo at ina-update ang view. Ang ViewController ay hindi visual na elemento — pinamamahalaan nito ang property na view na naglalaman ng hierarchy ng subview. Ayon sa data ng Apple (2026), ang UIKit ay naglalaman ng higit sa 40 built-in na subclass ng UIViewController.

Ang unang iPhone SDK (2008) ay may kasamang UIViewController na may tatlong lifecycle na pamamaraan. Sa loob ng 18 taon, nagdagdag ang Apple ng suporta para sa Container View Controller, adaptive presentations, UIViewControllerTransitioningDelegate para sa custom na animation, at split screen mode sa iPad. Ang UIViewController ay nananatiling mandatoryong bahagi para sa mga UIKit application.

Lifecycle ng UIViewController

Ang lifecycle ng UIViewController — isang pagkakasunod-sunod ng mga pamamaraan na tinatawag ng system kapag gumagawa, nagpapakita, at nagtatago ng screen. Ang pag-unawa sa lifecycle ay kritikal: ang maling paglalagay ng code ay humahantong sa memory leaks, hindi kinakailangang network requests, at pagkutitap ng interface.

Pagkakasunod-sunod ng pagtawag kapag lumitaw ang screen

Sa unang pagpapakita ng screen: init → loadView → viewDidLoad → viewWillAppear → viewDidAppear. Sa muling paglitaw (pagbabalik mula sa ibang screen): viewWillAppear → viewDidAppear. Ang viewDidLoad ay tinatawag nang isang beses lamang sa buong buhay ng controller.

viewDidLoad, init at configuration ng UI

Ang pamamaraang viewDidLoad — pangunahing punto ng configuration ng user interface. Tinatawag pagkatapos ma-load ang view sa memorya, kapag lahat ng IBOutlet ay konektado na. Dito ginagawa ang mga UI element nang programmatically, ni-configure ang mga constraint, nilo-load ang paunang data.

final class ProfileViewController: UIViewController {

    private let tableView = UITableView()
    private let viewModel = ProfileViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()
        setupUI()
        bindViewModel()
    }

    private func setupUI() {
        view.addSubview(tableView)
        tableView.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            tableView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            tableView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
            tableView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
            tableView.bottomAnchor.constraint(equalTo: view.bottomAnchor)
        ])
        tableView.register(ProfileCell.self,
                         forCellReuseIdentifier: ProfileCell.reuseId)
    }

    private func bindViewModel() {
        viewModel.$user
            .receive(on: DispatchQueue.main)
            .sink { [weak self] user in
                self?.title = user.name
            }
            .store(in: &cancellables)
    }
}

Sa SwiftUI, ang code na ito ay katumbas ng body ng View. Ngunit ang UIViewController ay nagbibigay ng ganap na kontrol sa lifecycle at optimization. Ang bindViewModel ay gumagamit ng Combine para sa reactive subscription — awtomatikong nag-a-update ang data kapag nagbago ang modelo.

viewWillAppear at pag-update ng data

viewWillAppear ay tinatawag tuwing bago lumitaw ang screen, kahit na nasa memorya na ito. Ito ang lugar para sa pag-update ng data na maaaring nagbago sa ibang screen: muling pagkarga ng listahan, pag-update ng notification counter, configuration ng navigation bar para sa partikular na screen.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)

    // Itago ang navigation bar sa screen na ito
    navigationController?.setNavigationBarHidden(true, animated: animated)

    // I-update ang data kapag bumalik mula sa ibang screen
    tableView.reloadData()
    badgeLabel.text = "\(CartManager.shared.itemCount)"
}

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)

    // Analytics: pagkatapos lamang makita ng user ang screen
    AnalyticsService.shared.logScreenView("Profile")
}

Ang pagkakaiba sa pagitan ng viewDidLoad at viewWillAppear ay kritikal: ang viewDidLoad ay isinasagawa nang isang beses at angkop para sa static na configuration, ang viewWillAppear — tuwing magpapakita, angkop para sa dynamic na pag-update. Ang paglalagay ng network requests sa viewDidLoad ay magdudulot ng pagpapakita ng lumang data kapag bumalik sa screen.

Container View Controller: UINavigationController at UITabBarController

Container View Controller — isang ViewController na namamahala sa isa o higit pang child ViewController. Nagbibigay ang Apple ng tatlong built-in na container: UINavigationController (stack ng mga screen), UITabBarController (mga tab), at UISplitViewController (master-detail para sa iPad).

Ang UINavigationController ay nag-oorganisa ng mga transition sa isang stack — push ay nagdaragdag ng screen, pop ay nag-aalis. Ang UITabBarController ay lumilipat sa pagitan ng mga independiyenteng seksyon ng application. Ang UISplitViewController ay nagpapakita ng dalawang controller na magkatabi sa iPad at isa sa iPhone. Ang developer ay maaaring gumawa ng sariling container sa pamamagitan ng addChild.

// Custom na Container View Controller
final class ContainerViewController: UIViewController {

    private let sidebarVC = SidebarViewController()
    private let contentVC = ContentViewController()

    override func viewDidLoad() {
        super.viewDidLoad()

        // Pagdaragdag ng child controller
        addChild(sidebarVC)
        view.addSubview(sidebarVC.view)
        sidebarVC.didMove(toParent: self)

        addChild(contentVC)
        view.addSubview(contentVC.view)
        contentVC.didMove(toParent: self)
    }
}

Ang tamang pagtatrabaho sa Container View Controller ay nangangailangan ng pagtawag ng addChild, pagdaragdag ng view at didMove(toParent:) sa ganitong pagkakasunod-sunod. Kapag tinatanggal — willMove(toParent: nil), removeFromSuperview, removeFromParent. Ang paglabag sa pagkakasunod-sunod ay humahantong sa memory leaks.

Paglutas ng Massive View Controller sa pamamagitan ng MVVM at Coordinator

Ang problema ng Massive View Controller — kapag ang UIViewController ay naglalaman ng daan-daang linya ng code na may business logic, network requests, navigation, at UI code. Alam ng Apple ang problema at inirerekomenda ang MVVM (Model-View-ViewModel) kasama ng Coordinator para sa paghihiwalay ng navigation.

Inilipat ng MVVM ang business logic mula sa controller patungo sa ViewModel. Ang Controller ay nag-uugnay lamang ng ViewModel sa View sa pamamagitan ng Combine o delegate. Ang Coordinator ay naghihiwalay ng navigation logic — paggawa at paglipat sa pagitan ng mga controller — sa isang hiwalay na klase. Ang diskarteng ito ay isinama sa pinakamahuhusay na kagawian ng Apple mula noong 2024.

// Coordinator — pamamahala ng navigation
protocol Coordinator {
    var childCoordinators: [Coordinator] { get set }
    func start()
}

final class MainCoordinator: Coordinator {

    var childCoordinators = [Coordinator]()
    private let navigationController: UINavigationController

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func start() {
        let vc = ListViewController()
        vc.didSelectItem = { [weak self] item in
            self?.showDetail(item)
        }
        navigationController.pushViewController(vc, animated: false)
    }

    private func showDetail(_ item: Item) {
        let vc = DetailViewController(item: item)
        navigationController.pushViewController(vc, animated: true)
    }
}

UIViewController vs SwiftUI: kailan ano ang pipiliin

Ang pagpili sa pagitan ng UIViewController at SwiftUI View ay depende sa taon ng pagsisimula ng proyekto, mga kinakailangan sa pag-customize, at minimum na sinusuportahang bersyon ng iOS. Ang UIKit na may UIViewController ay nananatiling batayan para sa mga proyektong sinimulan bago ang 2020 at para sa mga application na may malalim na pag-customize ng interface.

Ang SwiftUI ay angkop para sa mga bagong proyekto na may iOS 17+, mga karaniwang interface, at prototype. Gayunpaman, para sa custom na transition, pagtatrabaho sa camera, MapKit, kumplikadong CALayer animation, kailangan ang UIViewController. Inirerekomenda ng Apple na pagsamahin ang mga diskarte sa pamamagitan ng UIHostingController (SwiftUI sa loob ng UIKit) at UIViewRepresentable (UIKit sa loob ng SwiftUI).