React to Changes - Swift SDK

Realm Collections

Cuando observas rutas clave en los distintos tipos de colecciones, puedes esperar estos comportamientos:

• LinkingObjects:: Observing a property of the LinkingObject triggers a notification for a change to that property, but does not trigger notifications for changes to its other properties. Insertions or deletions to the list or the object that the list is on trigger a notification.

• 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 MutableSet activa una notificación de cambio para esa propiedad, pero no activará notificaciones para cambios en sus otras propiedades. Las inserciones o eliminaciones en el MutableSet o en el objeto en el que se encuentra el MutableSet desencadenan una notificación.

• Results: Observing a property of the Result triggers a notification for a change to that property, but does not trigger notifications for changes to its other properties. Insertions or deletions to the Result trigger a notification.

Cumplimiento de la observación de pares clave-valor

Realm objects are key-value observing (KVO) compliant for most properties:

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

• The invalidated property on Object and List

You cannot observe LinkingObjects properties via Key-value observation.

Managed vs. Unmanaged KVO Considerations

Observing the properties of unmanaged instances of Object subclasses works like any other dynamic property.

Observar las propiedades de los objetos gestionados funciona de manera diferente. Con objetos gestionados por Realm, el valor de una propiedad puede cambiar cuando:

• You assign to it

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

• You begin a write transaction after changes on another thread

Realm applies changes made in the write transaction(s) on other threads at once. Observers see Key-value observation notifications at once. Intermediate steps do not trigger KVO notifications.

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.

Observing Realm Lists

Observing changes made to Realm List properties is simpler than NSMutableArray properties:

• You don't have to mark List properties as dynamic to observe them.

• You can call modification methods on List directly. Anyone observing the property that stores it gets a notification.

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

Perform Writes Only on a Different Thread than the Observing Thread

Reading an observed collection or object from inside a change notification always accurately tells you what has changed in the collection passed to the callback since the last time the callback was invoked.

Leer colecciones u objetos fuera de las notificaciones de cambio siempre te da exactamente los mismos valores que viste 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.

Writes on different threads eventually become visible on the observing thread. Explicitly calling refresh() blocks until the writes made on other threads are visible and the appropriate notifications have been sent. If you call refresh() within a notification callback, it's a no-op.

Realizar guardados 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.

Inside a write transaction, the only changes you see are those you've made so far within the write transaction.

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.

Perform Writes Inside of Notifications

Al realizar guardados dentro de notificaciones, se observan muchos de los mismos comportamientos mencionados anteriormente, con algunas excepciones.

Las funciones de retorno invocadas antes de la que realizó un guardado se comportan normalmente. Aunque Realm invoca las funciones de retorno de cambio en un orden estable, este no es estrictamente el orden en que se agregaron las observaciones.

If beginning the write refreshes the realm, which can happen if another thread is making writes, this triggers recursive notifications. These nested notifications report the changes made since the last call to the callback. For callbacks before the one making the write, this means the inner notification reports only the changes made after the ones already reported in the outer notification. If the callback making the write tries to write again in the inner notification, Realm throws an exception. The callbacks after the one making the write get a single notification for both sets of changes.

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.

If beginning the write doesn't refresh the realm, the write happens as usual. However, Realm invokes the subsequent callbacks in an inconsistent state. They continue to report the original change information, but the observed object/collection now includes the changes from the write made in the previous callback.

If you try to perform manual checks and write handling to get more fine-grained notifications from within a write transaction, you can get notifications nested more than two levels deep. An example of a manual write handling is checking realm.isInWriteTransaction, and if so making changes, calling realm.commitWrite() and then realm.beginWrite(). The nested notifications and potential for error make this manual manipulation error-prone and difficult to debug.

You can use the writeAsync API to sidestep complexity if you don't need fine-grained change information from inside your write block. Observing an async write similar to this provides notifications even if the notification happens to be delivered inside a write transaction:

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

However, because the write is async the realm may have changed between the notification and when the write happens. In this case, the change information passed to the notification may no longer be applicable.

Actualización de una UITableView según notificaciones

If you only update a UITableView via notifications, in the time between a write transaction and the next notification arriving, the TableView's state is out of sync with the data. The TableView could have a pending update scheduled, which can appear to cause delayed or inconsistent updates.

You can address these behaviors in a few ways.

The following examples use this very basic UITableViewController.

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