La estantería deja de pedir la misma página sin parar #23

Closed

HBB wants to merge 0 commits from HBB:fix/enrichment-sweep-blocked into main

HBB commented

2026-08-01 15:42:00 +00:00

First-time contributor

Dos arreglos sobre main (v1.2.0), los dos en MyBooksScreen.

La paginación no terminaba nunca

Se daba por acabada la estantería al llegar una página con menos de diez libros
(fetchedItems.size < 10, ahí desde efe49b3). Pero las páginas vienen de quince, y a una
página que no existe la instancia responde con la última otra vez. Si la última página
trae justo diez libros —una estantería de 70, por ejemplo— la condición no se cumple jamás:
la app sigue pidiendo la misma página, una cada medio segundo, mientras la pantalla esté
abierta. En una prueba llegó a la página 56 antes de cerrarla.

Con la estantería sin darse por completa:

la lista nueva no llega a la pantalla, así que un libro recién añadido no aparece;
no se guarda la estantería entera en la caché, solo la primera página;
el relleno de datos por libro no empieza nunca, porque espera a que termine la
paginación: los libros se quedan sin autor, sin fechas de lectura y sin serie;
y la instancia recibe dos peticiones por segundo de cada usuario al que le pase.

Ahora el final lo marca que una página no traiga ningún libro nuevo, que es cierto tanto
si la instancia repite la última como si devuelve una vacía, y no depende del tamaño de
página. Con un tope de 200 páginas como red de seguridad.

El relleno de datos podía bloquearse a sí mismo

Abrir un libro nada más entrar en la estantería levanta la misma bandera con la que se dibuja
la barra de progreso, y el recorrido que iba a empezar la miraba, se daba media vuelta y no
volvía. Lo mismo al pedir «actualizar datos» mientras uno estaba en marcha: cancelaba el que
había y el nuevo se encontraba la bandera levantada. Quedaban libros a medio rellenar hasta
volver a entrar sin tocar nada.

Lo que impide ahora que dos recorridos se pisen es un candado y no la bandera: el segundo
espera al primero y, como recuenta lo que falta al entrar, no rehace su trabajo. De paso, el
refresco de un libro suelto guarda solo ese libro en vez de volcar el mapa entero, que borraba
lo que el recorrido acabara de guardar mientras tanto.

Comprobado

En un Galaxy S23 contra bookwyrm.social, con una estantería «Leídos» de 70 libros —el caso que
lo dispara—. Antes: páginas repetidas sin fin y la caché parada en 15 libros. Después: los 70
libros traídos y guardados en menos de cinco segundos, las peticiones paran, y el relleno de
datos llega hasta el final (70 de 70). ./gradlew testDebugUnitTest pasa.

Dos arreglos sobre `main` (v1.2.0), los dos en `MyBooksScreen`. ## La paginación no terminaba nunca Se daba por acabada la estantería al llegar una página con menos de diez libros (`fetchedItems.size < 10`, ahí desde `efe49b3`). Pero las páginas vienen de quince, y a una página que no existe la instancia responde con **la última otra vez**. Si la última página trae justo diez libros —una estantería de 70, por ejemplo— la condición no se cumple jamás: la app sigue pidiendo la misma página, una cada medio segundo, mientras la pantalla esté abierta. En una prueba llegó a la página 56 antes de cerrarla. Con la estantería sin darse por completa: - la lista nueva no llega a la pantalla, así que **un libro recién añadido no aparece**; - **no se guarda la estantería entera** en la caché, solo la primera página; - **el relleno de datos por libro no empieza nunca**, porque espera a que termine la paginación: los libros se quedan sin autor, sin fechas de lectura y sin serie; - y la instancia recibe dos peticiones por segundo de cada usuario al que le pase. Ahora el final lo marca que una página no traiga **ningún libro nuevo**, que es cierto tanto si la instancia repite la última como si devuelve una vacía, y no depende del tamaño de página. Con un tope de 200 páginas como red de seguridad. ## El relleno de datos podía bloquearse a sí mismo Abrir un libro nada más entrar en la estantería levanta la misma bandera con la que se dibuja la barra de progreso, y el recorrido que iba a empezar la miraba, se daba media vuelta y no volvía. Lo mismo al pedir «actualizar datos» mientras uno estaba en marcha: cancelaba el que había y el nuevo se encontraba la bandera levantada. Quedaban libros a medio rellenar hasta volver a entrar sin tocar nada. Lo que impide ahora que dos recorridos se pisen es un candado y no la bandera: el segundo espera al primero y, como recuenta lo que falta al entrar, no rehace su trabajo. De paso, el refresco de un libro suelto guarda solo ese libro en vez de volcar el mapa entero, que borraba lo que el recorrido acabara de guardar mientras tanto. ## Comprobado En un Galaxy S23 contra bookwyrm.social, con una estantería «Leídos» de 70 libros —el caso que lo dispara—. Antes: páginas repetidas sin fin y la caché parada en 15 libros. Después: los 70 libros traídos y guardados en menos de cinco segundos, las peticiones paran, y el relleno de datos llega hasta el final (70 de 70). `./gradlew testDebugUnitTest` pasa.

HBB added 2 commits

2026-08-01 15:42:00 +00:00

fix: la estantería termina de rellenarse aunque se abra un libro al entrar 9061582918

Abrir un libro nada más entrar en «Leídos» dejaba la estantería a medias:
la ficha refresca los datos de ese libro y para ello levanta la misma
bandera con la que se dibuja la barra de progreso, y el recorrido que
estaba a punto de empezar la miraba, se daba media vuelta y no volvía. Lo
mismo pasaba al pedir «actualizar datos» mientras uno estaba en marcha:
cancelaba el que había y el nuevo se encontraba la bandera levantada.
Quedaban libros sin autor, sin fechas y sin serie hasta que se entraba
otra vez sin tocar nada.

Ahora lo que impide que dos recorridos se pisen es un candado y no la
bandera: el segundo espera al primero, y como recuenta lo que falta al
entrar, no rehace su trabajo.

De paso, el refresco de un libro suelto guarda solo ese libro en vez de
volcar el mapa entero, que borraba lo que el recorrido acabara de
guardar mientras tanto.

fix: la estantería deja de pedir la misma página para siempre b2d36d6cdd

Se daba por terminada la estantería al llegar una página con menos de
diez libros. Pero las páginas vienen de quince, la última de «Leídos»
traía justo diez, y a una página que no existe la instancia responde con
la última otra vez: la condición no se cumplía nunca y la app siguió
pidiendo la misma página, una cada medio segundo, hasta que se cerraba.

Con la estantería sin darse por completa, la lista nueva no llegaba a la
pantalla —un libro recién añadido no aparecía— y el relleno de datos por
libro, que espera a que termine la paginación, no empezaba nunca: los
libros se quedaban sin autor, sin fechas y sin serie.

Ahora el final lo marca que una página no traiga ningún libro nuevo, que
es cierto tanto si la instancia devuelve la última repetida como si
devuelve una vacía, y da igual de cuántos sean las páginas. Con un tope
de 200 por si acaso.

ferlagod closed this pull request

2026-08-01 19:01:40 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ferlagod/rocinante_android!23

No description provided.

Rows
Columns