viewDidAppear v iOS — co to je, kdy se volá a příklady

Co je viewDidAppear

viewDidAppear je metoda UIViewController, kterou UIKit volá poté, co je View přidána do hierarchie oken a přechodová animace je plně dokončena. V tomto okamžiku je obrazovka v konečném stavu: je viditelná, lze s ní interagovat, všechny UIKit animace jsou zastaveny. Vývojář tuto metodu přepisuje, aby provedl akce, které vyžadují, aby byla obrazovka zaručeně před očima uživatele.

Na rozdíl od viewWillAppear, kde se obrazovka teprve připravuje k zobrazení, viewDidAppear signalizuje, že uživatel již vidí rozhraní. To je kritický rozdíl: spuštění animace ve viewWillAppear může vést k vynechaným snímkům, protože UIKit stále zpracovává přechod. Ve viewDidAppear je přechod dokončen a zdroje controlleru mohou být použity pro vykreslení nového obsahu.

Metoda přijímá parametr animated typu Bool, podobně jako viewWillAppear. Pokud je true — objevení obrazovky bylo doprovázeno animací. Tento parametr lze použít k přizpůsobení chování UI: například k přeskočení vstupní animace při neanimovaném návratu.

Kdy se volá viewDidAppear

viewDidAppear se volá ve všech scénářích, kdy obrazovka dokončila proces objevení. Podívejme se na hlavní případy z pohledu iOS vývojáře.

Po dokončení navigačního přechodu

Poté, co UINavigationController dokončí push nebo pop animaci, je na cílovém controlleru volán viewDidAppear. Pro první obrazovku v zásobníku se aktivuje po počáteční otevírací animaci. Toto je hlavní scénář a na něj se odkazujeme při umísťování logiky do viewDidAppear.

Po dismiss modálního okna

Když uživatel zavře modálně prezentovaný controller a vrátí se na předchozí obrazovku, UIKit volá viewDidAppear u vracejícího se controlleru. Parametr animated bude odpovídat tomu, zda byl dismiss proveden s animací. Tento okamžik je důležitý pro aktualizaci UI po obdržení dat z podřízené obrazovky.

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

Při přepínání karet TabBar

UITabBarController volá viewDidAppear na controlleru vybrané karty po dokončení přepnutí. To je rozdíl oproti viewWillAppear, který se aktivuje na začátku přepnutí. Pokud je na kartě uvítací animace nebo je třeba sledovat aktivní čas, viewDidAppear je správné místo.

Při objevení z pozadí

Když se aplikace vrací z background do foreground, mohou být na viditelném controlleru volány viewWillAppear a viewDidAppear, pokud byl životní cyklus View dočasně pozastaven. Pro spolehlivé sledování návratu z pozadí však použijte samostatně UIApplication.willEnterForegroundNotification.

Praktické úkoly ve viewDidAppear

viewDidAppear řeší úkoly, které vyžadují viditelnou obrazovku pro správné provedení. Podívejme se na klíčové scénáře použití v reálných projektech.

Odesílání událostí analytiky

Nejčastější úkol viewDidAppear — sledování zobrazení obrazovky. Analytické systémy jako Firebase Analytics, Amplitude nebo Mixpanel by měly dostávat události až poté, co byla obrazovka skutečně zobrazena uživateli. Odeslání události ve viewWillAppear může snížit dobu zobrazení a vytvářet falešná spuštění.

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

Spouštění vstupních animací

Animace, které mají začít po objevení obrazovky — objevení prvků se zpožděním, paralaxa, tutoriál — se spouštějí ve viewDidAppear. V tomto okamžiku je grafický kontext plně připraven a animace bude plynulá, bez ztráty snímků na začátku. To je zvláště důležité pro animace používající UIViewPropertyAnimator.

Zahájení asynchronního načítání

Těžké asynchronní operace — načítání obrázků ve vysokém rozlišení, parsování velkých JSONů, inicializace videa — je lepší spouštět ve viewDidAppear než ve viewDidLoad nebo viewWillAppear. V okamžiku volání metody uživatel již vidí rozhraní, takže lze zobrazit skeleton nebo loader, aniž by se zdržovalo objevení obrazovky.

Spouštění časovačů a intervalů

Pokud jsou na obrazovce prvky vyžadující periodickou aktualizaci — odpočítávací časovač, indikátor načítání, animace průběhu — spouštějí se ve viewDidAppear a zastavují ve viewDidDisappear. To zabraňuje činnosti časovačů, když obrazovka není viditelná, šetří baterii a CPU zdroje.

Zahájení přehrávání obsahu

Multimediální obsah — video, audio, Lottie animace — se spouští právě ve viewDidAppear, ne dříve. Pokud začnete přehrávání ve viewWillAppear, uživatel zmešká první sekundy, zatímco se obrazovka ještě objevuje. Ve viewDidAppear můžete spustit AVPlayer nebo Lottie animaci s jistotou, že uživatel vidí obsah od prvního snímku. To je zvláště důležité pro onboardingové obrazovky a splash screeny, kde záleží na přesném načasování.

Animace a výkon

Správný okamžik spuštění animace přímo ovlivňuje vnímání plynulosti rozhraní. Rozdíl mezi spuštěním ve viewWillAppear a viewDidAppear může být u jednoduchých animací nepostřehnutelný, ale kritický pro složité scény.

Když UIKit provádí push přechod mezi obrazovkami, vytváří snímky obrazovky, animuje je a současně volá viewWillAppear na novém controlleru. Pokud v tomto okamžiku spustíte těžkou animaci — paralaxu, rozostření, transformaci — UIKit může přeskočit snímky přechodové animace a vytvořit efekt škubání. viewDidAppear zaručuje, že přechodová animace je dokončena a máte plnou kontrolu nad vykreslováním.

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
    }
}

Používejte zpoždění a tlumení pro vytvoření přirozeného kaskádového objevování prvků. Tento přístup zlepšuje vnímání rozhraní a zvyšuje dwell time — uživatel studuje obsah déle, což pozitivně ovlivňuje behaviorální metriky.

Typické chyby ve viewDidAppear

Nesprávné použití viewDidAppear může vést k problémům s výkonem, neočekávanému chování animací a nadměrnému sledování. Podívejme se na časté chyby.

První chyba — vícenásobná volání. viewDidAppear může být volán několikrát v určitých scénářích: přepínání karet, návrat z pozadí, modální přechody. Pokud je v metodě prováděna těžká operace bez kontroly příznaku, bude se duplikovat. Pro jednorázové akce použijte příznak hasAppeared nebo dispatchOnce.

Druhá chyba — spouštění síťových požadavků bez zrušení při skrytí. Pokud uživatel opustí obrazovku před dokončením požadavku, výsledek může být aplikován na již skryté View. Používejte zrušitelné URLSessionTask a ukončete je ve viewDidDisappear.

Třetí chyba — sledování ve viewWillAppear místo viewDidAppear. Někteří vývojáři posílají události analytics ve viewWillAppear, ale to vytváří falešná spuštění, pokud se obrazovka neobjevila (například při zrušeném pop gestu). viewDidAppear je jediný spolehlivý indikátor, že uživatel skutečně viděl obrazovku.

Čtvrtá chyba — zapomenuté super. Volání super.viewDidAppear je nezbytné pro správnou funkci UINavigationController, UITabBarController a UISplitViewController. Bez něj se mohou standardní mechanismy navigace a aktualizace rozhraní rozbít.

Pátá chyba — změna orientace nebo velikosti obrazovky bez zohlednění viewDidLayoutSubviews. Pokud vaše animace ve viewDidAppear závisí na konečných rozměrech View, pamatujte, že viewDidLayoutSubviews může být voláno několikrát před viewDidAppear. Při prvním objevení obrazovky se layout dokončí před voláním viewDidAppear, ale při následných změnách velikosti — například při otočení zařízení — viewDidAppear nemusí být volán a vaše animace se nespustí. V takových případech použijte viewDidLayoutSubviews s kontrolou příznaku firstLayout.

Správná implementace zahrnuje uchování reference na objekt animace a její explicitní zrušení při opuštění obrazovky. Šestá chyba — spouštění nekonečných animací bez příznaku zastavení. Pokud ve viewDidAppear spouštíte opakující se animaci (například pulzující indikátor nebo rotující loader), ale nezastavíte ji ve viewDidDisappear, animace bude spotřebovávat GPU zdroje, i když je obrazovka skrytá. Vždy uchovávejte referenci na aktivní animaci a volejte removeAllAnimations nebo setCompletion v odpovídající metodě ukončení životního cyklu.

Sedmá chyba — ignorování viewDidDisappear pro zastavení aktivit. Pokud jste zahájili poslech GPS, akcelerometru nebo gyroskopu ve viewDidAppear, nezapomeňte jej zastavit ve viewDidDisappear. Jinak budou senzory pokračovat v práci na pozadí, spotřebovávat baterii, i když uživatel dávno přešel na jinou obrazovku. Používejte párová volání start a stop v odpovídajících metodách životního cyklu — to zaručuje správné řízení zdrojů zařízení.