Cortesía de Andrés Nieto Porras (https://www.flickr.com/photos/anieto2k)
Couchbase Lite ejecuta réplicas (sincronizaciones) utilizando subprocesos en segundo plano. El inicio y la detención de las réplicas no se producen de forma sincrónica. Esto puede dar lugar a errores en la detección del estado de una replicación.
En Clase de replicación tiene, según la plataforma, un corriendo o una rutina como isRunning(). Se trata de una forma ligera de comprobar el estado de una replicación.
Sin embargo, su uso puede dar lugar a resultados inesperados. Por ejemplo, hace poco escribí una utilidad que utiliza réplicas continuas. Tengo un botón para iniciarlas y detenerlas. Es tentador usar isRunning para actualizar el estado del botón. Resulta que esto es una mala idea. No es sorprendente, dado que los cambios se producen en segundo plano, pero es fácil pasarlo por alto.
En su lugar, el enfoque preferido utiliza un escuchador de cambios. He aquí un ejemplo.
Tenemos dos clases. La clase de ayuda de base de datos envuelve algunas operaciones estándar para simplificar. He añadido una interfaz para emplear un patrón de devolución de llamada. La clase cliente tiene que implementarlo. La clase helper digiere la notificación de cambio de Couchbase Lite antes de pasar nada al cliente. Esto da una buena separación de preocupaciones.
Las listas de códigos que figuran a continuación son esquemas. Sólo muestran lo esencial. Veamos primero la clase helper.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
público clase DBHelper implementa Replicación.ChangeListener { privado booleano replicaciónActiva = falso; privado Lista stateListeners = nuevo ArrayList<>(); ... público interfaz ReplicationStateListener { void onChange(booleano isActive); } público void startReplication(URL pasarela, booleano continuo) { ... pushReplication.addChangeListener(este); pushReplication.iniciar(); } público void stopReplication() { ... } público void addReplicationStateListener(ReplicationStateListener oyente) { stateListeners.añada(oyente); } público void removeReplicationStateListener(ReplicationStateListener oyente) { stateListeners.eliminar(oyente); } // Replication.ChangeListener @Override público void cambiado(Replicación.Evento de cambio changeEvent) { si (changeEvent.getError() != null) { Throwable últimoError = changeEvent.getError(); // Reaccionar ante el error devolver; } si (changeEvent.getTransition() == null) devolver; ReplicationState dest = changeEvent.getTransition().getDestination(); replicaciónActiva = ((dest == ReplicationState.PARADA || dest == ReplicationState.PARADA) ? falso : verdadero); stateListeners.paraCada(oyente -> oyente.onChange(replicaciónActiva)); } } |
Vemos que DBHelper implementa el método Replication.ChangeListener interfaz. Se trata de una interfaz definida por Couchbase Lite. En startReplication añadimos este listener a la replicación. Tiene un método para anular, cambiado. En Evento de cambio puede tener varios valores diferentes. En el ejemplo, primero compruebo si hay errores y notifico al usuario si se produce alguno. De lo contrario, compruebo si se trata de un evento de transición de estado de replicación. El estado de destino puede ser uno de los siguientes INICIAL, RUNNING, IDLE, FUERA DE LÍNEA, PARADAo PARADA.
En este caso sólo quiero saber si la replicación se está cerrando, así que simplifico el valor de retorno. Permito a los clientes registrar más de un oyente, así que el último trozo de código hace un bucle sobre todas las retrollamadas y las invoca.
La clase cliente es aún más sencilla. Hago que la clase implemente la interfaz necesaria de la clase helper. Sólo tiene que registrar el oyente durante la construcción de la instancia, y tener onChange haz lo que necesites en la interfaz de usuario.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
público clase Cliente implementa DBHelper.ReplicationStateListener { privado DBHelper servicio = DBHelper.getInstance(); ... público Cliente() { servicio.addReplicationStateListener(este); } ... // DBHelper.ReplicationStateListener @Anular público void onChange(booleano isActive) { // Código para gestionar el cambio } } |
Este código procede de una herramienta que he creado. Lea sobre la herramienta en esta entradaPuede encontrar el código fuente en GitHub aquí.
Posdata
Consulte más recursos en nuestra portal para desarrolladores y síganos en Twitter @CouchbaseDev.
Puede enviar preguntas a nuestro foros. Y participamos activamente en Stack Overflow.
Contáctame en Twitter @HodGreeley
[...] proviene de la clase de ayuda DBService. Escribí un poco sobre la detección del estado de una replicación aquí. Para esta aplicación sólo necesito saber si una replicación se está ejecutando o no para mantener el botón Sync [...]
[...] El otro listener nos permite mostrar un spinner de ocupado-espera (barra de progreso indefinida) dependiendo del estado de Replicación. Puedes leer más sobre la monitorización del estado de replicación aquí. [...]