@Environment in SwiftUI — was es ist, Schlüsselkonzepte und Mechanismus

Was ist @Environment in SwiftUI?

@Environment ist ein SwiftUI Property Wrapper zum Lesen von Werten aus der Systemumgebung. Die Umgebung ist ein hierarchischer Container von Werten, den SwiftUI automatisch von Eltern-Views an Kinder-Views verteilt. Jeder Umgebungswert wird durch einen Schlüssel identifiziert — einen Typ, der dem EnvironmentKey-Protokoll entspricht.

Der Umgebungsmechanismus ähnelt der Dependency Injection auf Framework-Ebene: Das System bietet einen vordefinierten Satz von Werten — Farbschema (hell/dunkel), Gebietsschema, Schriftgröße, managedObjectContext für Core Data, dismiss zum Schließen von Bildschirmen und viele andere. Eine View, die @Environment mit einem bestimmten Schlüssel deklariert, erhält automatisch den aktuellen Wert und wird bei Änderung neu gerendert.

Die SwiftUI-Umgebungsarchitektur basiert auf dem EnvironmentValues-Protokoll — einer Struktur, die alle Systemwerte enthält. Jeder Wert wird als Eigenschaft dieser Struktur mit Getter und Setter gespeichert. @Environment verwendet einen Key Path, um auf eine bestimmte Eigenschaft zuzugreifen: @Environment(\.colorScheme) — Zugriff auf Farbschema, @Environment(\.locale) — Zugriff auf Gebietsschema.

@Environment als Property Wrapper

Der Property Wrapper @Environment implementiert zwei Schlüsselmechanismen: Lesen eines Werts aus der Umgebung und Abonnement seiner Änderungen. Wenn eine View erstellt wird, durchläuft SwiftUI alle @Environment-Eigenschaften und verknüpft sie mit den entsprechenden Werten aus dem aktuellen Kontext. Wenn eine Eltern-View einen Wert über den .environment()-Modifikator ändert, werden alle Kinder-Views, die diesen Wert lesen, automatisch neu gerendert.

Eine wichtige Funktion: @Environment unterstützt optionale Werte. Wenn ein Wert in der Hierarchie nicht gesetzt ist, wird der in EnvironmentKey definierte Standardwert zurückgegeben. Für Systems Schlüssel ist der Standardwert immer sinnvoll — zum Beispiel ist das Standard-Farbschema .light. Für benutzerdefinierte Schlüssel definiert der Entwickler den Standardwert in der defaultValue-Methode des EnvironmentKey-Protokolls.

struct EnvironmentReaderView: View {
    @Environment(\.colorScheme) var colorScheme
    @Environment(\.locale) var locale
    @Environment(\.sizeCategory) var sizeCategory

    var body: some View {
        VStack {
            Text("Current scheme: \(colorScheme == .dark ? "Dark" : "Light")")
            Text("Locale: \(locale.identifier)")
            Text("Font size: \(sizeCategory)")
        }
    }
}

Im Beispiel liest die View drei Systemumgebungswerte. Wenn sich colorScheme ändert — zum Beispiel hat der Benutzer den Dunkelmodus in den Einstellungen aktiviert — wird die View automatisch mit dem neuen Wert neu gerendert. Ebenso bei Änderung der Region oder Schriftgröße (Dynamic Type). Die View muss keine Benachrichtigungen abonnieren oder refresh aufrufen — SwiftUI verwaltet dies automatisch.

Systemumgebungswerte

SwiftUI bietet Dutzende von Systemumgebungswerten, die verschiedene Aspekte der Oberfläche und des Verhaltens abdecken. Farbschema (\.colorScheme) ist einer der am häufigsten verwendeten Werte und ermöglicht die Anpassung der Oberfläche an helle und dunkle Designs. Gebietsschema (\.locale) enthält die regionalen Einstellungen des Benutzers für die Formatierung von Daten, Zahlen und Währungen.

Für Core Data wird managedObjectContext (\.managedObjectContext) verwendet — ein Kontext, der über die Umgebung vom Persistenzcontainer übergeben wird. Für die Navigation stehen dismiss (\.dismiss) zum Schließen des aktuellen Bildschirms und isPresented (\.isPresented) für modale Darstellungen zur Verfügung. Für Kalender und Zeitzone — calendar bzw. timeZone.

Um auf Systemwerte zuzugreifen, verwenden Sie den Key Path mit einem Punkt: @Environment(\.dismiss) var dismiss. Der Compiler überprüft die Existenz des Key Path in EnvironmentValues, daher führt ein falscher Schlüssel zu einem Compiler-Fehler. Apple fügt mit jeder iOS-Version neue Systemwerte hinzu — die vollständige Liste finden Sie in der EnvironmentValues-Dokumentation.

@Environment vs @EnvironmentObject

Trotz der ähnlichen Namen haben @Environment und @EnvironmentObject unterschiedliche Zwecke. @Environment liest System- oder benutzerdefinierte Werte, die über EnvironmentKey registriert wurden. @EnvironmentObject ist ein Property Wrapper für ein ObservableObject, das nach Typ über die Umgebung übergeben wird, ohne expliziten Schlüssel.

@EnvironmentObject wird für Dependency Injection verwendet: Eine Eltern-View erstellt ein Objekt (z. B. ViewModel) und übergibt es an Kinder-Views über den .environmentObject()-Modifikator. Kinder-Views erhalten es über @EnvironmentObject und können seine Eigenschaften lesen und ändern. @Environment hingegen ist schreibgeschützt für Systemwerte und unterstützt kein Feedback.

In der Praxis: Verwenden Sie @Environment für den Zugriff auf Systemparameter (Design, Gebietsschema, Schriftgröße) und benutzerdefinierte Konfigurationen, die sich zur Laufzeit nicht ändern. Verwenden Sie @EnvironmentObject, um ein ViewModel oder einen Service durch die View-Hierarchie zu übergeben, wenn der Status von untergeordneten Komponenten geändert werden muss.

@Environment Code-Beispiele

Betrachten wir die Erstellung eines benutzerdefinierten Umgebungswerts. Dazu müssen Sie eine Struktur definieren, die dem EnvironmentKey-Protokoll entspricht, und EnvironmentValues um eine neue Eigenschaft erweitern. Dies ermöglicht die Übergabe von Designkonfiguration oder App-Einstellungen durch den gesamten View-Baum ohne Props.

struct AppThemeKey: EnvironmentKey {
    static let defaultValue: AppTheme = .system
}

extension EnvironmentValues {
    var appTheme: AppTheme {
        get { self[AppThemeKey.self] }
        set { self[AppThemeKey.self] = newValue }
    }
}

enum AppTheme { case system, light, dark }

Das EnvironmentKey-Protokoll erfordert die Implementierung der statischen Eigenschaft defaultValue — der Wert, der verwendet wird, wenn die Eltern-View keine benutzerdefinierte Umgebung gesetzt hat. Die Erweiterung von EnvironmentValues fügt eine berechnete Eigenschaft appTheme hinzu, die einen Subscript mit dem Schlüssel verwendet. Danach kann jede View den Wert über @Environment(\.appTheme) lesen.

Verwendung von @Environment mit einem benutzerdefinierten Schlüssel

struct ThemedView: View {
    @Environment(\.appTheme) var appTheme
    @Environment(\.colorScheme) var colorScheme

    var body: some View {
        VStack {
            if appTheme == .dark || (appTheme == .system && colorScheme == .dark) {
                Text("Dark mode active")
                    .foregroundStyle(.white)
                    .background(Color.black)
            } else {
                Text("Light mode active")
                    .foregroundStyle(.black)
                    .background(Color.white)
            }
        }
    }
}

struct ContentView: View {
    @State private var selectedTheme = AppTheme.system

    var body: some View {
        ThemedView()
            .environment(\.appTheme, selectedTheme)
    }
}

ThemedView liest zwei Umgebungen: die benutzerdefinierte appTheme und die systemeigene colorScheme. Die Kombination ermöglicht eine flexible Designkonfiguration: Der Benutzer kann Hell, Dunkel oder Systemdesign wählen. Wenn System ausgewählt ist, wird der Wert von colorScheme übernommen, der sich beim Umschalten des Designs in den iOS-Einstellungen automatisch ändert. Die Eltern-View (ContentView) setzt den appTheme-Wert über den .environment()-Modifikator.

Verwendung von dismiss zum Schließen eines Bildschirms

struct ModalView: View {
    @Environment(\.dismiss) var dismiss
    @State private var name = ""

    var body: some View {
        NavigationStack {
            Form {
                TextField("Your name", text: $name)
                Button("Save") { dismiss() }
            }
            .navigationTitle("Edit Profile")
        }
    }
}

Dieses Beispiel zeigt die praktische Verwendung von dismiss — einer Instanz von DismissAction aus der Umgebung. Der Aufruf von dismiss() als Funktion schließt den modalen Bildschirm oder geht den NavigationLink zurück. Die einzige Voraussetzung ist, dass die View modal präsentiert wird oder sich innerhalb eines NavigationStack befindet. dismiss wird automatisch aus dem Kontext bestimmt: Wenn die View als Sheet geöffnet wurde — wird das Sheet geschlossen, wenn als Popover — wird das Popover geschlossen.