View Protocol — klíčové pojmy, protokol View ve SwiftUI

Co je View Protocol ve SwiftUI?

View Protocol — je centrální protokol SwiftUI, který určuje, jak každý vizuální prvek popisuje svůj obsah. Na rozdíl od UIKit, kde každý prvek dědí z UIView pomocí tříd, SwiftUI používá protokolově orientovaný přístup: jakýkoli typ odpovídající protokolu View může být zobrazen na obrazovce.

Protokol View vyžaduje implementaci jediné vypočítávané vlastnosti body, která vrací určitý obsah. Za touto jednoduchostí se však skrývá výkonný systém kompozice: body může vrátit jakýkoli typ odpovídající View, včetně primitiv (Text, Image, Button), kontejnerů (VStack, HStack, ZStack) a vlastních složených komponent.

Podle WWDC 2023 je více než 95 % všech obrazovek v aplikacích SwiftUI postaveno prostřednictvím kompozice struktur implementujících protokol View. To činí View Protocol základem celé architektury SwiftUI.

Value type vs reference type

SwiftUI vyžaduje, aby View byl value type (struktura, struct), nikoli třída. Toto je klíčové architektonické rozhodnutí: value types mají předvídatelnou životnost, nemají sdílený měnitelný stav a umožňují SwiftUI efektivně určit, které části hierarchie se změnily a vyžadují překreslení.

Pokud se pokusíte udělat View třídou, kompilátor vrátí chybu: protokol View dědí z protokolu DynamicViewProperty, který vyžaduje value semantics. Třídy mohou odpovídat View, ale to porušuje idiomatický přístup a zbavuje výhod automatické aktualizace.

body: vypočítávaná vlastnost protokolu View

body — jediný povinný požadavek protokolu View. Je to vypočítávaná vlastnost, která vrací obsah zobrazený na obrazovce. Typ vrácené hodnoty — some View, což znamená „nějaký typ odpovídající View, který bude určen kompilátorem".

struct GreetingView: View {
    var name: String

    var body: some View {
        VStack {
            Text("Ahoj, \(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Button("Start") {
                print("Tlačítko stisknuto")
            }
        }
    }
}

Jak body funguje: SwiftUI volá body pokaždé, když se stav aplikace změní a je vyžadováno překreslení. Framework porovnává nový strom View se starým a aplikuje pouze nezbytné změny (diffing). Toto je zcela deklarativní přístup — popisujete, co má být zobrazeno, a SwiftUI se stará o to, jak to implementovat.

Důležitý detail: body by neměl mít vedlejší účinky. Je volán opakovaně během životnosti aplikace, a pokud se uvnitř body mění vnější stav — vede to k nepředvídatelnému chování. Pro vedlejší účinky používejte task, onChange nebo DispatchQueue.

Omezení počtu prvků

SwiftUI ukládá omezení: body může vrátit pouze jeden kořenový prvek. Pokud potřebujete zobrazit více prvků na stejné úrovni, zabalte je do kontejneru — VStack, HStack, ZStack nebo Group. S příchodem @ViewBuilder se toto omezení stalo méně nápadným, ale koncepčně body vždy vrací jeden View.

some View: neprůhledný typ v protokolu

some View — je syntaxe neprůhledného typu (opaque type) zavedená v Swift 5.1 speciálně pro SwiftUI. Znamená, že funkce nebo vlastnost vrací konkrétní typ odpovídající protokolu View, ale volající kód neví a neměl by vědět, jaký přesný typ je vrácen.

Kompilátor Swift fixuje konkrétní typ ve fázi kompilace pro každou implementaci body, ale skrývá ho před vnějším světem. To umožňuje SwiftUI optimalizovat hierarchii View tím, že zná přesné typy všech komponent, ale dává vývojáři flexibilitu při změně implementace bez změny signatury.

struct ContentView: View {
    var body: some View {
        Text("Ahoj, světe!") // Kompilátor ví, že toto je Text
    }
}

Proč some View, a ne jen View? Pokud by body vracel prostě View (jako protokol), SwiftUI by nemohl určit konkrétní typ během kompilace. To vede k dodatečné režii na zabalení do existenciálního kontejneru (existential container). some View poskytuje kompilátoru dostatek informací pro optimalizaci při zachování flexibility protokolu.

Omezení some View

Hlavní omezení — body musí vracet stejný typ. Nelze vrátit Text v jedné větvi podmínky a Image v druhé bez speciálních obalů (AnyView, Group nebo @ViewBuilder). Kompilátor to kontroluje ve fázi kompilace: všechny možné návratové cesty musí mít stejný typ.

Pro obejití tohoto omezení se používá @ViewBuilder (vytváří jednotný typ TupleView), Group (který také vrací jednotný typ) nebo AnyView (maže typ, ale přidává režii). AnyView by se měl používat pouze tehdy, když jiné možnosti nejsou možné, protože vypíná optimalizace SwiftUI.

@ViewBuilder: skládání více View

@ViewBuilder — je result builder, jehož anotace umožňuje skládat několik View do jedné kompozice bez vnořených kontejnerů. @ViewBuilder automaticky zabaluje několik výrazů do n-tice (TupleView) nebo aplikuje podmíněnou logiku (If / else / switch) se správným návratovým typem.

struct DashboardView: View {
    var isLoggedIn: Bool

    @ViewBuilder
    var body: some View {
        if isLoggedIn {
            Text("Vítejte!")
                .font(.largeTitle)
            ProfileCard()
        } else {
            LoginButton()
                .padding()
        }
    }
}

Jak @ViewBuilder funguje: kompilátor převádí každý blok kódu uvnitř @ViewBuilder na volání statických metod buildBlock, buildEither, buildOptional atd. Pokud blok obsahuje několik výrazů — jsou zabaleny do TupleView. Pokud blok obsahuje podmíněnou logiku — kompilátor generuje ConditionalContent skrývající typ větve.

@ViewBuilder ukládá omezení: až 10 prvků v jednom bloku (omezení TupleView). Pokud potřebujete seskupit více než deset prvků, použijte Group, ForEach nebo rozdělte na podkomponenty. Toto omezení existuje, protože Swift generuje samostatné přetížení buildBlock pro každou aritu od 1 do 10.

Kompozice View a modifikátory

Kompozice — klíčový princip SwiftUI: složitá rozhraní se staví z malých, znovu použitelných View komponent. Každá komponenta implementuje protokol View a odpovídá za svou část obrazovky. Modifikátory (font, padding, foregroundColor) se aplikují na View a vracejí nový View s změněnými nastaveními.

Modifikátory ve SwiftUI nejsou mutace, ale vytvoření nového obalu kolem původního View. Každý modifikátor vrací nový typ (ModifiedContent), což umožňuje SwiftUI postavit strom modifikátorů a efektivně překreslovat pouze změněné části. Pořadí aplikace modifikátorů je důležité: různá pořadí dávají různé vizuální výsledky.

Text("Ahoj, SwiftUI!")
    .font(.title)        // ModifiedContent
    .padding()           // ModifiedContent<..., PaddingModifier>
    .background(.yellow) // ModifiedContent<..., BackgroundModifier>
    .cornerRadius(8)    // ModifiedContent<..., CornerRadiusModifier>

Optimalizace výkonu: SwiftUI porovnává ne konkrétní hodnoty View, ale jejich identitu prostřednictvím mechanismu identity (id, ForEach, stabilní identita struktur). Pokud se struktura View nezměnila — body není voláno. Toho je dosaženo pomocí Equatable porovnání a mechanismu PreferenceKey pro předávání dat nahoru hierarchií.

Pro efektivní kompozici se doporučuje rozdělovat složité obrazovky na nezávislé podkomponenty, každou s vlastním minimálním stavem. To umožňuje SwiftUI překreslovat pouze změněné části hierarchie, nikoli celou obrazovku.