viewDidAppear у iOS — шта је, када се позива и примери

Шта је viewDidAppear

viewDidAppear је метода UIViewController коју UIKit позива након што је View додата у хијерархију прозора и анимација преласка је потпуно завршена. У овом тренутку екран се налази у коначном стању: видљив је, може се интераговати с њим, све UIKit анимације су заустављене. Програмер прегаза ову методу за извршавање радњи које захтевају да је екран гарантовано пред очима корисника.

За разлику од viewWillAppear, где се екран тек припрема за приказ, viewDidAppear сигнализира да корисник већ види интерфејс. Ово је критична разлика: покретање анимације у viewWillAppear може довести до испуштених оквира, јер UIKit још увек обрађује прелазак. У viewDidAppear прелазак је завршен, и ресурси контролера могу бити искоришћени за рендеровање новог садржаја.

Метода прима параметар animated типа Bool, аналогно viewWillAppear. Ако је true — појава екрана је била праћена анимацијом. Овај параметар се може користити за прилагођавање понашања UI: на пример, за прескакање улазне анимације код неанимираног повратка.

Када се позива viewDidAppear

viewDidAppear се позива у свим сценаријима када је екран завршио процес појављивања. Размотримо главне случајеве из перспективе iOS програмера.

По завршетку навигационог преласка

Након што UINavigationController заврши анимацију push или pop, на циљном контролеру се позива viewDidAppear. За први екран у стекту, покреће се након почетне анимације отварања. Ово је главни сценарио и на њега се ослањамо при постављању логике у viewDidAppear.

Након dismiss-а модалног прозора

Када корисник затвори модално презентовани контролер и врати се на претходни, UIKit позива viewDidAppear код повраћеног контролера. Параметар animated ће одговарати томе да ли је dismiss извршен са анимацијом. Овај тренутак је важан за ажурирање UI након примања података са детећег екрана.

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

При пребацивању картица TabBar

UITabBarController позива viewDidAppear на контролеру изабране картице након завршетка пребацивања. Ово је разлика у односу на viewWillAppear, који се покреће при почетку пребацивања. Ако на картици постоји анимација добродошлице или је потребно пратити активно вријеме, viewDidAppear је право место.

При појављивању из позадине

Када апликација враћа из background-а у foreground, на видљивом контролеру могу бити позвани viewWillAppear и viewDidAppear, ако је животни циклус View био привремено обустављен. Међутим, за поуздано праћење повратка из позадине користите одвојено UIApplication.willEnterForegroundNotification.

Практични задаци у viewDidAppear

viewDidAppear решава задатке који захтевају видљив екран за исправно извршавање. Размотримо кључне сценарије коришћења у реалним пројектима.

Слање догађаја аналитике

Најчешћи задатак viewDidAppear — праћење прегледа екрана. Аналитички системи као што су Firebase Analytics, Amplitude или Mixpanel треба да приме догађаје тек након што је екран стварно приказан кориснику. Слање догађаја у viewWillAppear може да смањи време прегледа и створи лажна покретања.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    Analytics.logEvent(
        name: "screen_view",
        parameters: [
            "screen_name": "ProfileScreen",
            "screen_class": String(describing: self)
        ]
    )
}

Покретање улазних анимација

Анимације које треба да почну након појаве екрана — појављивање елемената са кашњењем, паралакса, туторијал — покрећу се у viewDidAppear. У овом тренутку графички контекст је потпуно спреман, и анимација ће бити глатка, без испуштања оквира на почетку. Ово је посебно важно за анимације које користе UIViewPropertyAnimator.

Покретање асинхроних учитавања

Тешке асинхроне операције — учитавање слика високе резолуције, парсирање великих JSON-ова, иницијализација видеа — боље је покренути у viewDidAppear него у viewDidLoad или viewWillAppear. У тренутку позива методе, корисник већ види интерфејс, па се може приказати скелетон или лоадер, без задржавања појаве екрана.

Покретање тајмера и интервала

Ако на екрану постоје елементи који захтевају периодично ажурирање — тајмер за одбројавање, индикатор учитавања, анимација напретка — покрећу се у viewDidAppear и заустављају у viewDidDisappear. Ово спречава рад тајмера када екран није видљив, штедећи батерију и CPU ресурсе.

Почетак репродукције садржаја

Медијски садржај — видео, аудио, Lottie анимације — покрећу се управо у viewDidAppear, а не раније. Ако започнете репродукцију у viewWillAppear, корисник ће пропустити прве секунде док се екран још појављује. У viewDidAppear можете покренути AVPlayer или Lottie анимацију са сигурношћу да корисник види садржај од првог оквира. Ово је посебно важно за onboarding екране и splash screen-ове, где је прецизан тајминг кључан.

Анимације и перформансе

Прави тренутак покретања анимације директно утиче на перцепцију глаткости интерфејса. Разлика између покретања у viewWillAppear и viewDidAppear може бити неприметна код једноставних анимација, али критична за сложене сцене.

Када UIKit извршава push прелазак између екрана, прави скриншотове, анимира их и истовремено позива viewWillAppear на новом контролеру. Ако у овом тренутку покренете тешку анимацију — паралаксу, blur, трансформацију — UIKit може прескочити оквире прелазне анимације, стварајући ефекат трзања. viewDidAppear гарантује да је прелазна анимација завршена и имате потпуну контролу над рендеровањем.

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

    UIView.animate(
        withDuration: 0.6,
        delay: 0.3,
        usingSpringWithDamping: 0.8,
        initialSpringVelocity: 0.5
    ) {
        self.cardView.alpha = 1.0
        self.cardView.transform = .identity
    }
}

Користите кашњења и пригушење за стварање природног каскадног појављивања елемената. Овакав приступ побољшава перцепцију интерфејса и повећава dwell time — корисник дуже проучава садржај, што позитивно утиче на бихевноралне метрике.

Типичне грешке у viewDidAppear

Неправилно коришћење viewDidAppear може довести до проблема са перформансама, неочекиваног понашања анимација и прекомерног праћења. Размотримо честе грешке.

Прва грешка — вишеструки позиви. viewDidAppear се може позвати више пута у одређеним сценаријима: пребацивање картица, повратак из позадине, модални преласци. Ако се у методи извршава тешка операција без провере заставице, она ће се дуплирати. За једнократне радње користите заставицу hasAppeared или dispatchOnce.

Друга грешка — покретање мрежних захтева без поништавања при сакривању. Ако корисник напусти екран пре завршетка захтева, резултат може бити примењен на већ сакривен View. Користите поништивe URLSessionTask и завршите их у viewDidDisappear.

Трећа грешка — праћење у viewWillAppear уместо viewDidAppear. Неки програмери шаљу догађаје analytics у viewWillAppear, али то ствара лажна покретања ако се екран није појавио (на пример, код отказаног pop геста). viewDidAppear је једини поуздан показатељ да је корисник стварно видео екран.

Четврта грешка — заборав super. Позив super.viewDidAppear је неопходан за исправан рад UINavigationController, UITabBarController и UISplitViewController. Без њега могу се покварити стандардни механизми навигације и ажурирања интерфејса.

Пета грешка — промена оријентације или величине екрана без узимања у обзир viewDidLayoutSubviews. Ако ваша анимација у viewDidAppear зависи од коначних величина View, запамтите да се viewDidLayoutSubviews може позвати више пута пре viewDidAppear. При првом појављивању екрана, layout се завршава пре позива viewDidAppear, али при каснијим променама величине — на пример, при ротацији уређаја — viewDidAppear се може не позвати, и ваша анимација се неће покренути. У таквим случајевима користите viewDidLayoutSubviews са провером заставице firstLayout.

Исправна имплементација подразумева чување референце на објекат анимације и њено експлицитно поништавање при напуштању екрана. Шеста грешка — покретање бесконачних анимација без заставице за заустављање. Ако у viewDidAppear покрећете понављајућу анимацију (на пример, пулсирајући индикатор или ротирајући лоадер), али је не зауставите у viewDidDisappear, анимација ће трошити GPU ресурсе чак и када је екран сакривен. Увек чувајте референцу на активну анимацију и позивајте removeAllAnimations или setCompletion у одговарајућој методи завршетка животног циклуса.

Седма грешка — игнорисање viewDidDisappear за заустављање активности. Ако сте започели ослушкивање GPS, акцелерометра или жироскопа у viewDidAppear, обавезно га зауставите у viewDidDisappear. У супротном, сензори ће наставити рад у позадини, трошећи батерију, чак и ако је корисник одавно прешао на други екран. Користите упарене позиве start и stop у одговарајућим методама животног циклуса — ово гарантује исправно управљање ресурсима уређаја.