Jean-Luc Makiola
ec2e2eb59d
The store picker and the export screen were the two frontend surfaces the own-store work left unbuilt, so both backends shipped unreachable. Settings gains a Storage section holding them: a full-screen picker over Own / an installed external provider (dimmed when none is present, named after the provider's own app), and an export screen with a per-list tick and the two SAF destinations, a folder or a single zip. The picker asks for the provider's runtime permission before writing the mode, so a denial leaves the readable store in place instead of dropping the user on the gate; a refusal is reported with a route to app settings. Making the mode switchable at runtime had two consequences: - reminders are armed off whichever store was active when they were scheduled, so a switch rebuilds the set. ReminderScheduler.sync() is now serialised — it is a read-modify-write over ScheduledReminderStore, and overlapping runs each wrote their own set as the whole truth - the permission gate is the only screen an External user can reach once their provider app stops answering, so it offers the way back to our own store ExportWriter no longer deletes a previous export before recreating it (a failure in between lost both), lists the target directory once instead of per document, and carries a typed ExportFailure so the screen can report in the user's language rather than an exception message.
Agendula — documentation
Agendula is a Material 3 Expressive task app for Android. It carries its
own task store — the dmfs task provider vendored under our own authority — so
it is complete and local-first with nothing else installed; an external provider
(OpenTasks / tasks.org, synced by DAVx5 / SmoothSync / DecSync) is a user choice
rather than a requirement, and our own CalDAV sync is the 1.x arc. Sibling to
Calendula. See the
top-level ../README.md for the project pitch.
Index
| Doc | What it covers |
|---|---|
ARCHITECTURE.md |
How Agendula is built today — layers, the data seam, provider resolution, the reminder engine, DI, build/tooling, manifest. Start here to work on the code. |
ROADMAP.md |
Status and what's next — milestones (M0–M6 + Posture B), what's done, open decisions, how to build/verify. |
STORAGE-AND-SYNC.md |
Where task data lives — the decision to ship our own provider, the storage modes, permissions, distribution, and the dead ends. Supersedes PLAN.md on storage. |
SYNC.md |
How data reaches a server — the CalDAV sync adapter: the VTODO ↔ TaskContract mapper, Nextcloud sign-in, the engine, libraries and their licenses. Step 5 of STORAGE-AND-SYNC.md. |
STORAGE-DECISION.md |
Keep the vendored provider, or build our own? The measured cost of both. Decided: build our own. |
OWN-STORE.md |
Agendula's own Room store — the schema, recurrence design, migration off the vendored provider, and the six-phase plan that deletes :provider. Supersedes the "keep the provider" position in STORAGE-AND-SYNC.md. |
PLAN.md |
The original implementation plan and design rationale — the A-now-B-later thesis, what transfers from Calendula, the locked decisions. The "why". |
RELEASING.md |
How to cut a release — the git-tag-as-source-of-truth flow, CI jobs, F-Droid repo, required secrets. |
../provider/PROVENANCE.md |
What the vendored :provider module is, where it came from, and every deviation from upstream dmfs. |
Also: ../CHANGELOG.md (Keep a Changelog format; tag sections
feed the release notes).
How the docs relate
- PLAN is the original design decisions (the "why"), left as the historical record. On storage it is superseded by STORAGE-AND-SYNC.
- STORAGE-AND-SYNC and SYNC are the standing decision documents: the first settles where data lives, the second how it syncs. Both record rejected alternatives on purpose, so decisions don't get relitigated.
- ARCHITECTURE is the current shape of the code (kept in sync with the source as it grows).
- ROADMAP is the moving status layer (update as milestones land).
- RELEASING is the operational runbook.