aboutsummaryrefslogtreecommitdiff
path: root/mobile
Commit message (Collapse)AuthorAgeFilesLines
* perf(readings): stack calendar layers and load the book table once per Days callLukasz Kasprzak2026-08-243-3/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mobile.Days (dlectio's 7-day calendar view) called readings.Load once per date. Load's offlineLoad re-ran caldata.Stack (parses the embedded calendar INI, plus any user calendar layer) and bible.LoadBookTable (parses the embedded books.ini, plus any user override) on every call, even though neither depends on the date -- only on cfg.Selection().Form and cfg.Use, which mobile.Days holds fixed across its whole loop. Verified before changing anything: isolated benchmarks put Stack+ LoadBookTable at ~1.1ms/call (OF) and ~1.6ms/call (EF) -- real INI parsing and, for a user override, file I/O -- and for the OF form that redundant work was ~67% of a 7-day view's total time. Load gains a Prepared value (the layer stack + book table) and a Prepare/LoadWith pair: Prepare builds a Prepared once, LoadWith reuses it across dates. Load itself is unchanged, still calling Prepare on every invocation -- every existing caller keeps its current behaviour untouched. mobile.Days now Prepares once and loops LoadWith; mobile.Day picks up the same fix for its own two same-cfg Load calls. Benchmarked (interleaved before/after pairs, to control for machine thermal drift): the OF 7-day view (BenchmarkDaysWeek) drops from ~11.5ms to ~6.4ms/op (allocs 53359 -> 16347, -69%), an EF 7-day view (BenchmarkDays7EF) from ~74ms to ~66-73ms/op (allocs 299204 -> 253815, -15%; the EF form's per-day calendar computation dominates its total cost far more than OF's does, so the fix's share of the win is smaller there), and a single Day call (BenchmarkDay1) from ~4.3ms to ~2.9ms/op (allocs 15357 -> 9192, -40%). Output identity verified separately (not part of this diff): a 288-case sweep of mobile.Day/mobile.Days across both forms, both UI languages, all four corpora, a leap day, the Sacred Triduum, a Requiem day, and windows spanning Christmas/Pentecost/Assumption/All Souls produced byte-identical (SHA-256-equal) JSON before and after this change. New TestLoadWithAgreesWithLoad asserts LoadWith(Prepare(cfg), cfg, opts) equals Load(cfg, opts) for every case, so the fast path cannot silently drift from the slow one. go test ./... and make ci (both build tags, oracle/differential suite included) are green.
* mobile: fix the documented gomobile bind command so it reproduces the ↵Lukasz Kasprzak2026-08-051-1/+8
| | | | | | | | | | | | shipped .aar The comment omitted -javapkg, the second -target ABI and -androidapi. A clean clone following it got a .aar whose classes sit under go.mobile.gojni instead of xyz.labunix.dlectio.engine.mobile, carries only arm64-v8a, and declares no minSdkVersion match to the app's 26 -- the app cannot import the result. Verified by rebuilding the binding with the corrected command and confirming the artifact's ABIs, package and minSdkVersion against the shipped one.
* readings: PartIDs(new) stops declaring aklamacja, which the engine never emitsLukasz Kasprzak2026-08-051-11/+38
| | | | | | | | | | | | | | | | | | | | | caldata.go:42 parses only first/psalm/second/gospel out of the lectionary data, so no OF reading ever carries Part == "acclamation". PartIDs("new") listed aklamacja anyway, so the app built a checkbox from it that filters an ID that never appears -- a dead control, same defect class the app previously shipped for the whole 1962 form. ofPartOrder stays the full five-ID set: it also drives render.LocalizeHeading's label matching, where a scraped heading can still read "Aklamacja" even though this engine's own readings never produce that section. PartIDs now draws from a new, narrower ofEmittedPartOrder instead. Rewrote TestPartLabelsMatchesWhatTheEngineEmits's OF half: it compared PartLabels("of") to a hand-copied duplicate of ofPartOrder, asserting a declaration against itself, which cannot fail for this class of bug. It now sweeps Days over calendar year 2026 and asserts PartLabels("of") matches the observed part-ID set exactly (0.5s). Confirmed red against the pre-fix code, green after.
* mobile: strengthen the PartLabels fallback test and count boundsLukasz Kasprzak2026-08-042-4/+20
|
* mobile: add PartLabels so the app stops hardcoding part IDsLukasz Kasprzak2026-08-032-0/+76
|
* mobile: add Days, a text-free week projection for the calendarLukasz Kasprzak2026-08-032-0/+155
| | | | | A week through Days benchmarks at ~9-10ms/op, versus ~23ms for seven full days through Day.
* mobile: return the day's rank and its localised labelLukasz Kasprzak2026-08-032-9/+56
|
* baseline: track the gomobile engine facade as-isLukasz Kasprzak2026-08-031-0/+112
mobile/mobile.go and its go.mod/go.sum additions were sitting untracked in the working tree. Recorded here unchanged so the work that follows has a diff baseline; no lines of it are modified by this commit. Also ignore the cmd/dlectio-gen build product and the SDD scratch dir.