Jean-Luc Makiolaandmakiolaj
836817cd12
Views now re-query after the app's own writes and whenever the app comes back to the foreground, instead of relying only on the provider's change notification.
On the reporter's Samsung (Android 12, "My Calendar") edits and deletes went through, but no view refreshed until a restart. Tapping today in the agenda, which starts a fresh query, showed the correct data, so the provider had the change and the notification never reached us.
- `CalendarRepositoryImpl`: every write goes through a `write { }` helper that triggers a re-query when it finishes, also when the write threw.
- New `CalendarRepository.refresh()`, called from `MainActivity.onStart()`.
- Change ticks use `DROP_OLDEST`, so a tick is never dropped while a subscriber holds the previous one.
- The instances query filters `Events.DELETED = 0`, for providers that soft-delete and keep the instances around.
- `docs/ARCHITECTURE.md`: the observer principle mentions the extra re-queries.
The issue reads like a save/delete bug, but the writes themselves work. The fix targets the refresh, which is what was broken. The agenda opening on the 1st of the month, also mentioned in the thread, is the existing focus behaviour and isn't changed here.
Closes #364
Co-authored-by: Jean-Luc Makiola <business@jeanlucmakiola.de>
Reviewed-on: https://codeberg.org/jlmakiola/calendula/pulls/370
Documentation map
Where to look for what:
| Document | What it is |
|---|---|
../CONTRIBUTING.md |
How to contribute: issue-first workflow, which branch to target, translations, the rules a change is reviewed against |
BUILDING.md |
Building from source: submodule, JDK/SDK requirements, Gradle tasks, what CI runs |
ARCHITECTURE.md |
Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing |
RELEASING.md |
Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody |
../CHANGELOG.md |
Release history (Keep a Changelog, SemVer) |
| Issues + milestones | The roadmap: what's planned, in progress and shipped. A milestone maps to its release/vX.Y.Z branch |
../.planning/PROJECT.md |
What the project is: core value, stack + version pins, constraints, naming, forge/release infrastructure |
design/ |
Per-feature design notes kept for features whose provider behaviour is worth recording |
../fastlane/metadata/android/ |
Store metadata (single source of truth) for every app language, mapped in store-locales.txt: descriptions, title, graphics. Harvested directly by the official F-Droid repo, pushed to Google Play with every release, validated by ../scripts/check_store_listing.py; transformed into the self-hosted repo layout at release time by ../scripts/fastlane_to_fdroid_localized.sh |
../fdroid-metadata/ |
App-level F-Droid control file (*.yml: Categories, License, links) for the self-hosted repo's fdroid update |
fdroid-official/ |
Recipe and notes for publishing to the official F-Droid repo (reproducible build + developer-signed binary) |
Planning lives in the issue tracker and its milestones, not in this repository.
.planning/PROJECT.md describes the project itself.
ARCHITECTURE.md is updated with the code and is the place to record a lesson
learned about the calendar provider.