viewWillAppear in iOS: Das Wesen der Methode und wie man sie verwendet

Was ist viewWillAppear

viewWillAppear ist eine UIViewController-Methode, die UIKit unmittelbar vor dem Hinzufügen der View zur Fensterhierarchie aufruft. Zu diesem Zeitpunkt hat die View bereits ihre endgültigen Abmessungen nach den Auto-Layout-Durchläufen, ist aber für den Benutzer noch nicht sichtbar — die Übergangsanimation hat entweder noch nicht begonnen oder läuft gerade. Der Entwickler überschreibt diese Methode, um Operationen auszuführen, die vor jeder Bildschirmanzeige stattfinden sollen.

Im Gegensatz zu viewDidLoad, das nur einmal ausgelöst wird, wird viewWillAppear jedes Mal aufgerufen, wenn der Bildschirm erscheinen soll: beim ersten Öffnen, bei der Rückkehr von einem Child-Controller, nach dem Schließen eines modalen Fensters und beim Umschalten von TabBar-Tabs. Dies macht es zu einer Schlüsselmethode zur Aufrechterhaltung eines aktuellen Schnittstellenzustands.

Die Methode akzeptiert einen Parameter animated vom Typ Bool, der true ist, wenn das Erscheinen des Bildschirms von einer Animation begleitet wird. Dieser Parameter ist praktisch, um ihn an NavigationBar- und TabBar-Methoden zu übergeben, die ebenfalls einen ähnlichen Parameter für konsistentes Verhalten haben.

Wann wird viewWillAppear aufgerufen

Der Zeitpunkt des viewWillAppear-Aufrufs hängt von der Navigationsart ab, aber die allgemeine Regel bleibt unverändert: Die Methode wird ausgelöst, bevor die View sichtbar wird. Betrachten wir die Hauptszenarien.

Beim ersten Öffnen des Bildschirms

Nach viewDidLoad beginnt UIKit mit der Vorbereitung zur Anzeige: Die View wird zur Hierarchie hinzugefügt, Layout-Durchläufe werden ausgelöst, und unmittelbar vor Beginn der Übergangsanimation wird viewWillAppear aufgerufen. In diesem Moment ist der Bildschirm noch nicht sichtbar, aber alle Subviews haben korrekte Größen, und ihr Inhalt kann sicher aktualisiert werden.

Bei Rückkehr vom NavigationController

Wenn der Benutzer auf die Zurück-Taste tippt oder programmatisch popViewController aufruft, kehrt UIKit zum vorherigen Bildschirm zurück und ruft dessen viewWillAppear auf. Dies ist das Hauptszenario für die Verwendung von viewWillAppear — Aktualisieren einer Liste nach dem Hinzufügen eines Elements oder Synchronisieren von Einstellungen.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    updateBadgeCount()
}

Beim Schließen eines modalen Fensters

Nach dem Schließen eines modal präsentierten Controllers ruft UIKit viewWillAppear auf dem Controller auf, der es präsentiert hat. Dieses Szenario erfordert besondere Aufmerksamkeit, wenn Sie Delegaten oder Closures zum Zurückgeben von Daten verwenden — viewWillAppear stellt sicher, dass der Bildschirm nach Erhalt des Ergebnisses aktualisiert wird.

Beim Umschalten von TabBar-Tabs

TabBarController ruft viewWillAppear auf dem Controller des ausgewählten Tabs jedes Mal auf, wenn ein Wechsel stattfindet. Wenn der Tab dynamische Daten anzeigt — Wechselkurse, Benachrichtigungen, Benutzerstatus — ist viewWillAppear der ideale Ort, um sie zu aktualisieren.

Praktische Aufgaben in viewWillAppear

viewWillAppear löst mehrere spezifische Aufgaben, die in anderen Methoden unmöglich oder suboptimal auszuführen sind. Sehen wir uns die wichtigsten an.

Aktualisieren von Tabellendaten

Die häufigste Verwendung von viewWillAppear ist das erneute Laden einer UITableView oder UICollectionView jedes Mal, wenn der Bildschirm erscheint. Wenn sich Daten auf dem vorherigen Bildschirm geändert haben könnten (Element hinzugefügt, Status geändert), stellt der Aufruf von reloadData in viewWillAppear sicher, dass der Benutzer aktuelle Informationen sieht.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    viewModel.synchronize()
    tableView.reloadData()
}

Konfigurieren von NavigationBar und TabBar

In viewWillAppear kann das Erscheinungsbild der NavigationBar bequem konfiguriert werden: ein- oder ausblenden, Farbe ändern, Large Title setzen. Wenn verschiedene Bildschirme unterschiedliche NavigationBar-Stile haben, ist viewWillAppear der richtige Ort für diese Änderungen, da viewDidLoad nur einmal aufgerufen wird.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    navigationController?.setNavigationBarHidden(
        false, animated: animated
    )
    navigationController?.navigationBar.prefersLargeTitles = true
    tabBarController?.tabBar.isHidden = false
}

Abonnieren temporärer Benachrichtigungen

Benachrichtigungen, die nur sinnvoll sind, wenn der Bildschirm sichtbar ist — Tastaturbenachrichtigungen, Inhaltsänderungsbenachrichtigungen — werden in viewWillAppear abonniert und in viewDidDisappear gekündigt. Dies verhindert unnötige Handler, wenn der Bildschirm nicht aktiv ist, und schützt vor Speicherlecks.

Wiederherstellen des UI-Zustands

Wenn der Bildschirm von der App ausgeblendet oder minimiert werden kann, ist viewWillAppear ein praktischer Ort, um den UI-Zustand wiederherzustellen: Segmente umschalten, Bildlaufposition wiederherstellen, temporäre Änderungen zurücksetzen. Der Benutzer erhält den Bildschirm jedes Mal in einem vorhersagbaren Zustand.

Aktualisieren von Badges und Zählern

Auf Bildschirmen, die Zähler für ungelesene Nachrichten, Bewertungen oder Benachrichtigungen anzeigen, ist viewWillAppear der richtige Ort, um sie zu aktualisieren. Wenn der Benutzer die Menge auf einem anderen Bildschirm geändert haben könnte, werden hier die Neuberechnung und Aktualisierung von UITabBarItem.badgeValue oder benutzerdefinierten Indikatoren aufgerufen. Dies garantiert, dass der Benutzer immer aktuelle Zahlen sieht, unabhängig davon, wie lange er auf anderen Bildschirmen war.

Besondere Aufmerksamkeit sollte der Arbeit mit collectionView gewidmet werden: Wenn die Daten auf dem Bildschirm als Raster mit Zellen dargestellt werden, die Zähler oder Status enthalten, sollte deren Aktualisierung in viewWillAppear selektiv erfolgen. Verwenden Sie anstelle eines vollständigen reloadData reloadItemsAtIndexPaths für sichtbare Zellen, um Flackern und Verlust der Bildlaufposition zu vermeiden.

Unterschiede zwischen viewWillAppear und viewDidLoad

Den Unterschied zwischen viewWillAppear und viewDidLoad zu verstehen, ist die Grundlage einer korrekten UIViewController-Architektur. Diese Methoden haben unterschiedliche Aufruffrequenz, unterschiedlichen Kontext und unterschiedlichen Zweck.

viewDidLoad wird einmal aufgerufen und eignet sich für Konfigurationen, die sich im Laufe der Zeit nicht ändern: Zellen registrieren, Delegaten setzen, Konstanten initialisieren. viewWillAppear wird bei jedem Erscheinen aufgerufen und eignet sich für Operationen, die wiederholt werden müssen: Daten aktualisieren, sichtbare Elemente konfigurieren, Zustand synchronisieren.

Die goldene Regel: Wenn eine Operation nur einmal ausgeführt werden soll — legen Sie sie in viewDidLoad. Wenn sie jedes Mal ausgeführt werden soll, wenn Sie zum Bildschirm zurückkehren — legen Sie sie in viewWillAppear.

Häufige Fehler in viewWillAppear

Falsche Verwendung von viewWillAppear kann zu Leistungsproblemen, übermäßigen Aktualisierungen und inkonsistentem Schnittstellenzustand führen. Sehen wir uns die häufigsten Fehler an.

Der erste Fehler — Duplizieren der Logik von viewDidLoad. Wenn Sie Tabellenzellen sowohl in viewDidLoad als auch in viewWillAppear registrieren, wird die Registrierung mehrfach ausgeführt, obwohl eine einmalige Einrichtung ausreicht. Verschieben Sie alle einmaligen Konfigurationen in viewDidLoad.

Der zweite Fehler — bedingungsloses reloadData bei jedem Erscheinen. Wenn sich Daten nicht geändert haben, verursacht das erneute Laden der Tabelle unnötige Datenquellenabfragen und Zellenneuzeichnungen, was die Leistung beeinträchtigt. Überprüfen Sie, ob sich der Zustand tatsächlich geändert hat, bevor Sie reloadData aufrufen.

Der dritte Fehler — Arbeiten mit Netzwerkanfragen, ohne zu berücksichtigen, dass der Bildschirm vor Abschluss der Anfrage wieder ausgeblendet werden kann. Wenn Sie in viewWillAppear eine URLSession-Anfrage starten und der Benutzer sofort zu einem anderen Bildschirm navigiert, kann das Ergebnis auf eine bereits ausgeblendete View angewendet werden. Verwenden Sie abbrechbare Aufgaben oder überprüfen Sie isViewLoaded und window vor der Aktualisierung.

Der vierte Fehler — Vergessen, super aufzurufen. Das Nichtaufrufen von super.viewWillAppear kann das Verhalten der übergeordneten Controller (UINavigationController, UITabBarController) beeinträchtigen und zu falscher Behandlung von Gesten und Übergängen führen. super sollte immer aufgerufen werden.

Der fünfte Fehler — Ändern von Constraints ohne Aufruf von layoutIfNeeded. Wenn Sie Constraints in viewWillAppear programmatisch ändern, wendet UIKit sie nicht sofort an — die Änderungen sammeln sich bis zum nächsten Layout-Durchlauf. Für eine sofortige Anwendung der Änderungen nach der Constraint-Modifikation rufen Sie view.layoutIfNeeded() auf. Dies ist besonders wichtig beim Anpassen der Höhe inhaltsabhängiger Elemente.

Der sechste Fehler — Versuch, Animation in viewWillAppear auszuführen. Wie oben erwähnt, verarbeitet UIKit noch die Übergangsanimation, und Ihre Animation könnte mit der Systemanimation konkurrieren. Wenn Sie ein Element mit einem Effekt erscheinen lassen möchten, verwenden Sie eingehende Animation in viewDidAppear, und in viewWillAppear konfigurieren Sie nur den Anfangszustand: Transparenz 0, Transform bei Skalierung 0,8 und so weiter.

Der siebte Fehler — Ignorieren des Parameters animated. Einige Entwickler überprüfen den animated-Wert in viewWillAppear nicht und führen Operationen aus, die vom Vorhandensein einer Animation abhängen sollten. Zum Beispiel kann das Ausblenden der NavigationBar bei animated = false ohne Animation erfolgen, und bei animated = true — mit Animation, damit der Übergang fließend aussieht. Übergeben Sie den Parameter animated immer an die entsprechenden UIKit-Methoden.

Der achte Fehler — Ändern der UI bei nicht sichtbarem Bildschirm. Wenn Sie in viewWillAppear eine Netzwerkanfrage starten und ihr Completion-Block die UI aktualisiert, wenn der Bildschirm bereits verschwunden sein könnte, sieht der Benutzer Flackern oder einen inkonsistenten Zustand. Überprüfen Sie vor der Aktualisierung der UI in Closures immer isViewLoaded und window. Diese einfache Aktion verhindert Abstürze und unnötiges Neuzeichnen der Schnittstelle.