Reaccionar a los cambios - Swift SDK

Colecciones de reinos

Cuando observe las rutas clave en los distintos tipos de colecciones, espere estos comportamientos:

• ObjetosDeEnlace:: Al observar una propiedad del ObjetoDeEnlace, se activa una notificación para cualquier cambio en dicha propiedad, pero no para cualquier cambio en sus otras propiedades. Las inserciones o eliminaciones en la lista o en el objeto que la contiene activan una notificación.

• Listas: La observación de una propiedad del objeto de la lista activará una notificación por un cambio en esa propiedad, pero no activará notificaciones por cambios en sus otras propiedades. Las inserciones o eliminaciones en la lista o en el objeto donde se encuentra la lista activan una notificación.

• Mapa: Observar una propiedad del objeto del mapa activa una notificación para cualquier cambio en dicha propiedad, pero no para cualquier cambio en las demás propiedades. Las inserciones o eliminaciones en el mapa o en el objeto donde se encuentra activan una notificación. El change parámetro indica, en forma de claves dentro del mapa, qué pares clave-valor se añaden, eliminan o modifican durante cada transacción de escritura.

• MutableSet: Observar una propiedad de un objeto de un MutableSet activa una notificación para un cambio en dicha propiedad, pero no para cambios en sus otras propiedades. Las inserciones o eliminaciones en el MutableSet o en el objeto en el que se encuentra activan una notificación.

• Resultados: Al observar una propiedad del Resultado, se activa una notificación para cualquier cambio en dicha propiedad, pero no para cualquier cambio en sus otras propiedades. Las inserciones o eliminaciones en el Resultado sí activan una notificación.

Cumplimiento de la observación de valores clave

Los objetos de reino cumplen con la observación de clave-valor (KVO) para la mayoría de las propiedades:

• Casi todas las propiedades administradas (no ignoradas) en Object subclases

• La propiedad invalidated en Object y List

No se pueden observar propiedades LinkingObjects a través de la observación de clave-valor.

Consideraciones sobre KVO administrado y no administrado

La observación de las propiedades de instancias no administradas de subclases Object funciona como cualquier otra propiedad dinámica.

La observación de las propiedades de los objetos administrados funciona de forma diferente. Con los objetos administrados por dominio, el valor de una propiedad puede cambiar cuando:

• Tú le asignas

• El realm se actualiza, ya sea manualmente con realm.refresh() o automáticamente en un hilo de runloop.

• Comienza una transacción de escritura después de los cambios en otro hilo

Realm aplica los cambios realizados en las transacciones de escritura en otros subprocesos simultáneamente. Los observadores ven las notificaciones de observación de clave-valor inmediatamente. Los pasos intermedios no activan notificaciones de KVO.

Evitar modificar objetos Realm gestionados desde observeValueForKeyPath(_:ofObject:change:context:). Los valores de propiedad pueden cambiar cuando no se está en una transacción de escritura, o como parte de comenzar una transacción de escritura.

Observando listas de reinos

Observar los cambios realizados en las propiedades de Realm List es más sencillo que en las propiedades NSMutableArray:

• No es necesario marcar List propiedades como dinámicas para observarlas.

• Puedes llamar directamente a los métodos de modificación en List. Cualquiera que observe la propiedad que lo almacena recibe una notificación.

No necesitas usar mutableArrayValueForKey(_:), aunque Realm sí permite esto para la compatibilidad de código.

Realizar escrituras solo en un hilo diferente al hilo de observación

La lectura de una colección o un objeto observado desde dentro de una notificación de cambio siempre le indica con precisión qué ha cambiado en la colección pasada a la devolución de llamada desde la última vez que se invocó la devolución de llamada.

La lectura de colecciones u objetos fuera de las notificaciones de cambio siempre le brinda exactamente los mismos valores que vio en la notificación de cambio más reciente para ese objeto.

Al leer objetos distintos del observado dentro de una notificación de cambio, se podría ver un valor distinto antes de que se hubiera entregado la notificación de ese cambio. Realm refresh trae todo el realm desde la 'antigua versión' a la 'última versión' en una sola operación. Sin embargo, puede que se hayan disparado varias notificaciones de cambio entre la 'versión antigua' y la 'versión más reciente'. Dentro de una función de retorno, puedes ver cambios que tengan notificaciones pendientes.

Las escrituras en diferentes hilos se hacen visibles en el hilo observador. Llamar explícitamente a refresh() bloquea el proceso hasta que las escrituras realizadas en otros hilos sean visibles y se hayan enviado las notificaciones correspondientes. Si se llama a refresh() dentro de una devolución de llamada de notificación, la operación no es válida.

Realizar escrituras en el hilo de observación, fuera de las notificaciones

Al inicio de la transacción de escritura, todos los comportamientos anteriores se aplican a este contexto. Además, siempre puedes esperar ver la versión más reciente de los datos.

Dentro de una transacción de escritura, los únicos cambios que verá son aquellos que haya realizado hasta el momento dentro de la transacción de escritura.

Entre la confirmación de una transacción de escritura y el envío del siguiente conjunto de notificaciones de cambio, puede ver los cambios realizados en la transacción de escritura, pero ningún otro cambio. Las escrituras realizadas en diferentes subprocesos no son visibles hasta que recibe el siguiente conjunto de notificaciones. Al realizar otra escritura en el mismo subproceso, se envían primero las notificaciones de la escritura anterior.

Realizar escrituras dentro de las notificaciones

Cuando realiza escrituras dentro de las notificaciones, verá muchos de los mismos comportamientos mencionados anteriormente, con algunas excepciones.

Las devoluciones de llamada invocadas antes de la que realizó la escritura se comportan con normalidad. Si bien Realm invoca las devoluciones de llamada de cambio en un orden estable, este no es estrictamente el orden en el que se agregaron las observaciones.

Si al iniciar la escritura se actualiza el dominio, lo cual puede ocurrir si otro hilo está escribiendo, se activan notificaciones recursivas. Estas notificaciones anidadas informan de los cambios realizados desde la última llamada a la devolución de llamada. Para las devoluciones de llamada anteriores a la que realiza la escritura, esto significa que la notificación interna solo informa de los cambios realizados después de los ya informados en la notificación externa. Si la devolución de llamada que realiza la escritura intenta escribir de nuevo en la notificación interna, Realm lanza una excepción. Las devoluciones de llamada posteriores a la que realiza la escritura reciben una sola notificación para ambos conjuntos de cambios.

Una vez que la devolución de llamada completa la escritura y retorna, Realm no invoca ninguna de las devoluciones de llamada posteriores, ya que ya no tienen cambios que reportar. Realm proporciona una notificación posterior de la escritura, como si esta se hubiera producido fuera de ella.

Si al iniciar la escritura no se actualiza el dominio, esta se realiza de forma normal. Sin embargo, Realm invoca las devoluciones de llamada subsiguientes de forma inconsistente. Estas siguen reportando la información del cambio original, pero el objeto/colección observado ahora incluye los cambios de la escritura realizada en la devolución de llamada anterior.

Si intenta realizar comprobaciones y gestión de escritura manuales para obtener notificaciones más detalladas dentro de una transacción de escritura, puede obtener notificaciones anidadas a más de dos niveles de profundidad. Un ejemplo de gestión de escritura manual es comprobar realm.isInWriteTransaction y, en caso afirmativo, realizar cambios, llamando a realm.commitWrite() y luego a realm.beginWrite(). Las notificaciones anidadas y la posibilidad de errores hacen que esta manipulación manual sea propensa a errores y difícil de depurar.

Puedes usar la API writeAsync para evitar la complejidad si no necesitas información detallada sobre los cambios dentro de tu bloque de escritura. Observar una escritura asíncrona similar a esta proporciona notificaciones incluso si la notificación se entrega dentro de una transacción de escritura:

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
   }
}

Sin embargo, dado que la escritura es asíncrona, es posible que el dominio haya cambiado entre la notificación y el momento de la escritura. En este caso, es posible que la información de cambio enviada a la notificación ya no sea aplicable.

Actualización de una UITableView según notificaciones

Si solo actualiza un UITableView mediante notificaciones, entre una transacción de escritura y la siguiente notificación, el estado de TableView no está sincronizado con los datos. TableView podría tener una actualización pendiente programada, lo que puede causar actualizaciones retrasadas o inconsistentes.

Puedes abordar estos comportamientos de varias maneras.

Los siguientes ejemplos utilizan este UITableViewController muy 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)
                }
            }
        }
    }
}