React para alterações - Swift SDK

Realm Collections

Ao observar caminhos-chave nos vários tipos de coleção, espere estes comportamentos:

• LinkingObjects:: Observar uma propriedade do LinkingObject dispara uma notificação para uma alteração nessa propriedade, mas não dispara notificações para alterações em suas outras propriedades. Inserções ou exclusões na lista ou no objeto em que a lista está aciona uma notificação.

• Listas: A observação de uma propriedade do objeto da lista acionará uma notificação para uma alteração nessa propriedade, mas não acionará notificações para alterações em suas outras propriedades. Inserções ou exclusões na lista ou no objeto em que a lista está no trigger de uma notificação.

• Mapa: Observando uma propriedade do objeto do mapa Atlas Triggers uma notificação para uma alteração nessa propriedade, mas não trigger notificações para alterações em suas outras propriedades. Inserções ou exclusões no Mapa ou no objeto em que o mapa está trigger uma notificação. O parâmetro change relata, na forma de chaves dentro do mapa, quais pares de chave-valor foram adicionados, removidos ou modificados durante cada transação de escrita.

• MutableSet: A observação de uma propriedade do objeto de um MutableSet aciona uma notificação para uma alteração nessa propriedade, mas não aciona notificações para alterações em suas outras propriedades. Inserções ou exclusões no MutableSet ou no objeto em que o MutableSet está ativa uma notificação.

• Resultados: Observar uma propriedade do Resultado aciona uma notificação para uma alteração nessa propriedade, mas não aciona notificações para alterações em suas outras propriedades. Inserções ou exclusões no resultado aciona uma notificação.

Conformidade de observação de valor-chave

Objetos de Realm são compatíveis com observação de valor-chave (KVO) para a maioria das propriedades:

• Quase todas as propriedades gerenciadas (não assinadas) em Object subclasses

• A propriedade invalidated em Object e List

Não é possível observar propriedades LinkingObjects por meio da observação de valor-chave.

Considerações sobre KVO gerenciado versus não gerenciado

Observar as propriedades de instâncias não gerenciadas de Object subclasses funciona como qualquer outra propriedade dinâmica.

Observar as propriedades dos objetos gerenciados funciona de forma diferente. Com objetos gerenciados pelo real, o valor de uma propriedade pode mudar quando:

• Você atribui a ele

• O realm é atualizado manualmente com realm.refresh() ou automaticamente em uma thread runloop

• Você inicia uma transação de escrita após alterações em outro thread

O realm aplica alterações feitas na(s) transação(ões) escrita(s) em outras threads de uma só vez. Os observadores veem notificações de observação de valor-chave de uma só vez. Etapas intermediárias não acionam notificações KVO.

Evite modificar objetos de real gerenciados a partir de observeValueForKeyPath(_:ofObject:change:context:). Os valores da propriedade podem mudar quando não estão numa transação escrita ou como parte do início de uma transação escrita.

Observando listas Realm

Observar as alterações feitas nas propriedades do realm List é mais simples do que propriedades NSMutableArray:

• Você não precisa marcar List propriedades como dinâmicas para observá-las.

• Você pode chamar métodos de modificação diretamente em List. Qualquer pessoa que observe a propriedade que a armazena recebe uma notificação.

Você não precisa usar o mutableArrayValueForKey(_:), embora o realm seja compatível com isso para compatibilidade de código.

Executar gravações apenas em um thread diferente da thread de observação

A leitura de uma coleção ou objeto observado de dentro de uma notificação de alteração sempre informa com precisão o que foi alterado na coleção passada para a chamada de resposta desde a última vez que a chamada de resposta foi invocada.

A leitura de coleção ou objects fora das change notifications sempre gives exatamente os mesmos valores que you saw na most recent change notification para that object.

A leitura de objetos diferentes do observado dentro de uma notificação de alteração pode ver um valor diferente antes de a notificação dessa alteração ser entregue. O realm refresh traz todo o realm da “versão antiga” para a “versão mais recente” em uma operação. No entanto, pode ter havido várias notificações de alteração entre a “versão antiga” e a “versão mais recente”. Dentro de uma chamada de resposta, você pode ver alterações com notificações pendentes.

As escritas em threads diferentes por fim se tornam visíveis no thread de observação. Chamando explicitamente refresh() blocos até que as escritas feitas em outros threads sejam visíveis e as notificações apropriadas tenham sido enviadas. Se você chamar refresh() em um chamada de resposta de notificação, não haverá operação.

Execute escritas no tópico de observação, fora das notificações

No início da transação escrita, todos os comportamentos acima se aplicam a este contexto. Além disso, você pode esperar sempre ver a versão mais recente dos dados.

Dentro de uma transação de escrita, as únicas alterações que você vê são aquelas que você fez até agora na transação de escrita.

Entre a confirmação de uma transação de gravação e o próximo conjunto de notificações de alteração que está sendo enviado, você pode ver as alterações feitas na transação de gravação, mas nenhuma outra alteração. As gravações feitas em tópicos diferentes não ficam visíveis enquanto você não receber o próximo conjunto de notificações. Executar outra gravação no mesmo thread envia primeiro as notificações da gravação anterior.

Executar gravações dentro de notificações

Quando você executa gravações em notificações, você vê muitos dos mesmos comportamentos acima, com algumas exceções.

Os retornos de chamada invocados antes daquele que executou uma gravação se comportam normalmente. Embora o realm invoque chamada de resposta de alteração em uma ordem estável, essa não é estritamente a ordem em que você adicionou as observações.

Se o início da gravação atualizar o realm, o que pode acontecer se outro thread estiver fazendo gravações, isso aciona notificações recursivas. Essas notificações aninhadas relatam as alterações feitas desde a última chamada à chamada de resposta. Para chamadas de resposta antes de fazer a gravação, isso significa que a notificação interna relata apenas as alterações feitas após as já relatadas na notificação externa. Se a chamada de resposta que faz a gravação tentar gravar novamente na notificação interna, o realm lançará uma exceção. As chamas de resposta após aquela que fez o registro recebem uma única chamada de resposta para ambos os conjuntos de alterações.

Depois que a chamada de resposta concluir a gravação e retornar, o realm não invoca nenhuma das chamas de resposta subsequentes, pois eles não têm mais alterações a serem relatadas. O realm fornece uma notificação mais tarde para a escrita como se a escrita tivesse acontecido fora de uma notificação.

Se o início da escrita não atualizar o Realm, a escrita ocorrerá normalmente. No entanto, o Realm invoca as chamada de resposta subsequentes em um estado inconsistente. Elas continuam a relatar as informações de alteração originais, mas o objeto/collection observado agora inclui as alterações da escrita feitas na chamada de resposta anterior.

Se você tentar realizar verificações manuais e tratamento de gravação para obter notificações mais detalhadas de dentro de uma transação de escrita, poderá receber notificações aninhadas com mais de dois níveis de profundidade. Um exemplo de tratamento manual de gravação é verificar realm.isInWriteTransaction e, em caso afirmativo, fazer alterações, chamar realm.commitWrite() e depois realm.beginWrite(). As notificações aninhadas e o potencial de erro tornam esta manipulação manual propensa a erros e difícil de depurar.

Você pode usar a API writeAsync para contornar a complexidade se não precisar de informações de alteração refinadas de dentro do bloco de gravação. Observar uma gravação assíncrona semelhante a essa fornece notificações mesmo se a notificação for entregue dentro de uma transação de escrita:

let token = dog.observe(keyPaths: [\Dog.age]) { change in
   guard case let .change(dog, _) = change else { return }
   dog.realm!.writeAsync {
      dog.isPuppy = dog.age < 2
   }
}

No entanto, como a escrita é assíncrona, o Realm pode ter mudado entre a notificação e quando a escrita acontece. Nesse caso, as informações de alteração passadas para a notificação podem não ser mais aplicáveis.

Atualizar um UITableView com base em notificações

Se você só atualizar um UITableView por meio de notificações, no intervalo de tempo entre uma transação de escrita e a chegada da próxima notificação, o estado do TableView estará fora de sincronia com os dados. O TableView pode ter uma atualização pendente agendada, o que pode parecer causar atualizações atrasadas ou inconsistentes.

Você pode abordar esses comportamentos de algumas maneiras.

Os exemplos a seguir usam esse UITableViewController muito básico.

class TableViewController: UITableViewController {
    let realm = try! Realm()
    let results = try! Realm().objects(DemoObject.self).sorted(byKeyPath: "date")
    var notificationToken: NotificationToken!
    override func viewDidLoad() {
        super.viewDidLoad()
        tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell")
        notificationToken = results.observe { (changes: RealmCollectionChange) in
            switch changes {
            case .initial:
                self.tableView.reloadData()
            case .update(_, let deletions, let insertions, let modifications):
                // Always apply updates in the following order: deletions, insertions, then modifications.
                // Handling insertions before deletions may result in unexpected behavior.
                self.tableView.beginUpdates()
                self.tableView.deleteRows(at: deletions.map { IndexPath(row: $0, section: 0) }, with: .automatic)
                self.tableView.insertRows(at: insertions.map { IndexPath(row: $0, section: 0) }, with: .automatic)
                self.tableView.reloadRows(at: modifications.map { IndexPath(row: $0, section: 0) }, with: .automatic)
                self.tableView.endUpdates()
            case .error(let err):
                fatalError("\(err)")
            }
        }
    }
    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return results.count
    }
    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let object = results[indexPath.row]
        let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)
        cell.textLabel?.text = object.title
        return cell
    }
    func delete(at index: Int) throws {
        try realm.write {
            realm.delete(results[index])
        }
    }
}

func delete(at index: Int) throws {
    try realm.write(withoutNotifying: [notificationToken]) {
        realm.delete(results[index])
    }
    tableView.deleteRows(at: [IndexPath(row: index, section: 0)], with: .automatic)
}

func delete(at index: Int) throws {
    try realm.write {
        realm.delete(results[index])
    }
    realm.refresh()
}

func delete(at index: Int) throws {
    func delete(at index: Int) throws {
        @ThreadSafe var object = results[index]
        DispatchQueue.global().async {
            guard let object = object else { return }
            let realm = object.realm!
            try! realm.write {
                if !object.isInvalidated {
                    realm.delete(object)
                }
            }
        }
    }
}