@ObservedObject: co to je, pozorování objektů a aktualizace View

Co je @ObservedObject ve SwiftUI

@ObservedObject je property wrapper, který přihlašuje View ke změnám ObservableObject. Když objekt označený @ObservedObject změní některou ze svých vlastností deklarovaných s @Published, SwiftUI automaticky překreslí View. @ObservedObject nevytváří objekt — pouze vytváří spojení mezi již existující instancí ObservableObject a View, které má reagovat na jeho změny.

Klíčový rozdíl mezi @ObservedObject a @StateObject — je vlastnictví. @ObservedObject předpokládá, že objekt byl vytvořen a uložen někde výše v hierarchii View. Podřízené View získá referenci na tento objekt přes inicializátor a jednoduše jej pozoruje. Pokud je podřízené View znovu vytvořeno, obdrží stejnou referenci od rodiče — data se neztratí.

Podle Apple Developer Documentation — SwiftUI (2025) je @ObservedObject dostupný od iOS 13, což jej činí jedinou možností pro pozorování ObservableObject v projektech podporujících staré verze iOS. V iOS 14+ je preferován @StateObject pro vytváření objektů, ale @ObservedObject zůstává relevantní pro předávání existujících objektů.

Jak @ObservedObject funguje

Mechanismus @ObservedObject je založen na protokolu ObservableObject z frameworku Combine. Každá třída odpovídající ObservableObject automaticky získá publisher objectWillChange, který vysílá signál před změnou libovolné @Published vlastnosti. SwiftUI se přihlásí k tomuto publisheru přes @ObservedObject a po přijetí signálu označí View jako vyžadující překreslení.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // načíst data
        isLoading = false
    }
}

struct TaskListView: View {
    @ObservedObject var viewModel: TaskViewModel
    
    var body: some View {
        List(viewModel.tasks) { task in
            Text(task.title)
        }
        .task { await viewModel.loadTasks() }
    }
}

Když nadřazené View předá viewModel do TaskListView přes inicializátor, SwiftUI vytvoří spojení mezi objektem a View. Při změně pole tasks nebo příznaku isLoading SwiftUI překreslí TaskListView. Objekt přitom zůstává nezměněn — je uložen v nadřazeném View přes @StateObject.

@ObservedObject vs @StateObject: kdy co použít

Rozdíl mezi @ObservedObject a @StateObject — je rozdíl mezi pozorovatelem a vlastníkem. @StateObject vytváří objekt a spravuje jeho životní cyklus. @ObservedObject pouze pozoruje objekt, který byl vytvořen a uložen na jiném místě. Volba mezi nimi je určena odpovědností View za data.

Hlavní pravidlo: pokud View vytváří objekt — @StateObject. Pokud View přijímá objekt — @ObservedObject. Porušení tohoto pravidla ve prospěch @ObservedObject pro vytváření objektu vede ke ztrátě dat při přestavbě View. Porušení ve prospěch @StateObject pro přijímání objektu vytváří duplicitní instanci, nezávislou na rodiči.

Příklady použití @ObservedObject

Typický scénář použití @ObservedObject — seznam úkolů, kde kořenové View vytváří view model a buňka seznamu jej získává přes @ObservedObject. Každá buňka může volat metody view modelu a změny se automaticky zobrazí v celém seznamu, protože všechny buňky pozorují stejný objekt.

struct TaskRow: View {
    @ObservedObject var viewModel: TaskViewModel
    let task: Task
    
    var body: some View {
        HStack {
            Text(task.title)
            Spacer()
            Button("Hotovo") {
                viewModel.completeTask(task)
            }
        }
    }
}

struct TaskListContainer: View {
    @StateObject var viewModel = TaskViewModel()
    
    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(viewModel: viewModel, task: task)
        }
    }
}

V tomto příkladu TaskListContainer vytváří viewModel přes @StateObject a každá TaskRow jej získává přes @ObservedObject. Když uživatel klikne na „Done” v libovolném řádku, viewModel.completeTask změní published vlastnost a všechna View pozorující tento objekt se automaticky aktualizují.

Typické chyby s @ObservedObject

Nejčastější chyba — použití @ObservedObject k vytvoření objektu uvnitř View. Když je View přestavěno (např. při změně state), SwiftUI vytvoří novou instanci ObservableObject, což vede ke ztrátě všech nahromaděných dat. Tato chyba je obzvláště bolestivá v NavigationStack, kde uživatel může vyplnit formulář a při návratu zpět ztratit data.

Chyba: @ObservedObject místo @StateObject

// ❌ Ztráta dat: @ObservedObject neuchovává objekt
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // Nový formVM vytvořen při každé přestavbě View!
}

// ✅ Správně: @StateObject uchovává objekt
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // Objekt vytvořen jednou za dobu životnosti View
}

Chyba: předání @StateObject tam, kde je potřeba @ObservedObject

Pokud podřízené View deklaruje stejný ObservableObject přes @StateObject, vytvoří nezávislou kopii. Změny v nadřazeném objektu nebudou viditelné v podřízeném a naopak. Vždy používejte @ObservedObject pro podřízená View, která přijímají objekt zvenčí.

Alternativy k @ObservedObject ve SwiftUI

V moderním SwiftUI existuje několik alternativ k @ObservedObject, každá se svými výhodami. Volba závisí na architektuře aplikace, verzi iOS a konkrétním scénáři použití.

• @EnvironmentObject — umožňuje získat objekt z prostředí SwiftUI bez explicitního předávání přes inicializátor. Pohodlný pro objekty potřebné na mnoha obrazovkách, ale vyžaduje explicitní vložení přes .environmentObject().
• @State + @Binding — pro jednoduché typy hodnot nejsou potřeba ObservableObject. Použijte @State pro ukládání a @Binding pro předávání do podřízených View.
• @AppStorage — pro hodnoty UserDefaults, které by se měly automaticky synchronizovat s View.
• @SceneStorage — pro ukládání dočasného stavu mezi restartováním scény (např. pozice v seznamu).

Volba mezi @ObservedObject a @EnvironmentObject — je otázka stylu a architektury. @ObservedObject explicitně ukazuje závislosti View přes inicializátor, což činí kód předvídatelnějším. @EnvironmentObject je pohodlný pro hluboké hierarchie, ale skrývá závislosti, což může ztížit ladění.