@ObservedObject: какво е това, наблюдение на обекти и актуализиране на View

Какво е @ObservedObject в SwiftUI

@ObservedObject — е property wrapper, който абонира View за промените в ObservableObject. Когато обект, маркиран с @ObservedObject, промени някое от своите свойства, декларирани с @Published, SwiftUI автоматично прерисува View. @ObservedObject не създава обект — той само установява връзка между вече съществуващ екземпляр на ObservableObject и View, което трябва да реагира на неговите промени.

Ключовата разлика между @ObservedObject и @StateObject — е собствеността. @ObservedObject предполага, че обектът е създаден и съхранен някъде по-нагоре в йерархията на View. Дъщерното View получава референция към този обект чрез инициализатор и просто го наблюдава. Ако дъщерното View бъде пресъздадено, то ще получи същата референция от родителя — данните няма да бъдат загубени.

Според Apple Developer Documentation — SwiftUI (2025), @ObservedObject е достъпен от iOS 13, което го прави единствената опция за наблюдение на ObservableObject в проекти, поддържащи стари версии на iOS. В iOS 14+ се предпочита @StateObject за създаване на обекти, но @ObservedObject остава актуален за предаване на съществуващи обекти.

Как работи @ObservedObject

Механизмът на @ObservedObject се основава на протокола ObservableObject от Combine framework. Всеки клас, съответстващ на ObservableObject, автоматично получава publisher objectWillChange, който изпраща сигнал преди промяна на което и да е @Published свойство. SwiftUI се абонира за този publisher чрез @ObservedObject и при получаване на сигнала маркира View като изискващо прерисуване.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // извличане на данни
        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() }
    }
}

Когато родителското View предава viewModel на TaskListView чрез инициализатор, SwiftUI създава връзка между обекта и View. При промяна на масива tasks или флага isLoading, SwiftUI прерисува TaskListView. Обектът остава непроменен — той се съхранява в родителското View чрез @StateObject.

@ObservedObject vs @StateObject: кога какво да използваме

Разликата между @ObservedObject и @StateObject — е разликата между наблюдател и собственик. @StateObject създава обект и управлява неговия жизнен цикъл. @ObservedObject само наблюдава обект, който е създаден и съхранен на друго място. Изборът между тях се определя от отговорността на View за данните.

Основно правило: ако View създава обект — @StateObject. Ако View приема обект — @ObservedObject. Нарушаването на това правило в посока @ObservedObject за създаване на обект води до загуба на данни при възстановяване на View. Нарушаването в посока @StateObject за приемане на обект създава дублиран екземпляр, независим от родителския.

Примери за използване на @ObservedObject

Типичен сценарий за използване на @ObservedObject — списък със задачи, където кореновото View създава view model, а клетката на списъка го получава чрез @ObservedObject. Всяка клетка може да извиква методи на view model-а и промените автоматично се показват в целия списък, тъй като всички клетки наблюдават един и същ обект.

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

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

В този пример TaskListContainer създава viewModel чрез @StateObject, а всеки TaskRow го получава чрез @ObservedObject. Когато потребителят кликне „Done” във всеки ред, viewModel.completeTask променя published свойството и всички View, наблюдаващи този обект, се актуализират автоматично.

Типични грешки с @ObservedObject

Най-честата грешка — използване на @ObservedObject за създаване на обект вътре в View. Когато View бъде възстановено (например при промяна на state), SwiftUI създава нов екземпляр на ObservableObject, което води до загуба на всички натрупани данни. Тази грешка е особено болезнена в NavigationStack, където потребителят може да попълни формуляр и да загуби данни при връщане назад.

Грешка: @ObservedObject вместо @StateObject

// ❌ Загуба на данни: @ObservedObject не запазва обекта
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // Нов formVM се създава при всяко възстановяване на View!
}

// ✅ Правилно: @StateObject запазва обекта
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // Обектът е създаден веднъж за времето на живот на View
}

Грешка: предаване на @StateObject там, където е необходим @ObservedObject

Ако дъщерното View декларира същия ObservableObject чрез @StateObject, то създава независимо копие. Промените в родителския обект няма да бъдат видими в дъщерния и обратно. Винаги използвайте @ObservedObject за дъщерни View, които получават обекта отвън.

Алтернативи на @ObservedObject в SwiftUI

В съвременния SwiftUI съществуват няколко алтернативи на @ObservedObject, всяка със своите предимства. Изборът зависи от архитектурата на приложението, версията на iOS и конкретния сценарий на използване.

• @EnvironmentObject — позволява получаване на обект от средата на SwiftUI без изрично предаване чрез инициализатор. Удобен за обекти, необходими на много екрани, но изисква изрично инжектиране чрез .environmentObject().
• @State + @Binding — за прости типове стойности не са необходими ObservableObject. Използвайте @State за съхранение и @Binding за предаване в дъщерни View.
• @AppStorage — за стойности на UserDefaults, които трябва автоматично да се синхронизират с View.
• @SceneStorage — за запазване на временно състояние между рестартирания на сцената (например позиция в списък).

Изборът между @ObservedObject и @EnvironmentObject — е въпрос на стил и архитектура. @ObservedObject изрично показва зависимостите на View чрез инициализатор, което прави кода по-предвидим. @EnvironmentObject е удобен за дълбоки йерархии, но скрива зависимостите, което може да затрудни отстраняването на грешки.