DriverVault

161 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
tajniak81andClaude Opus 5	7718b32013	Phone App: off the plugins that bring their own Kotlin flutter build apk warned that file_picker and shared_preferences_android apply the Kotlin Gradle Plugin themselves, and that a future Flutter will refuse to build an app whose plugins do. Both have versions that let Flutter's built-in Kotlin do it instead; neither of them is a version bump on its own. shared_preferences_android was free — 2.4.27 is inside the constraint that was already there and only pub.lock was holding it back. file_picker is not: 10 and 11 both apply KGP, so 12 is the floor, and 12 split into federated packages whose windows one wants win32 ^6, which flutter_secure_storage 9 forbids. So the fix reaches flutter_secure_storage, and that is the part worth reading twice. v11 satisfies win32 but its changelog is explicit: data written by a version before v10 is unusable after it, because v10 is what migrates the Jetpack Security (EncryptedSharedPreferences) backend Google deprecated to the package's own ciphers. Going 9 to 11 in one step would leave the stored credentials unreadable and quietly switch biometric login off for anyone who had it on. v10 satisfies win32 ^6 just as well, so the constraint is pinned below 11 with the reason written down: once a build carrying v10 has run on every device that had biometric login enabled, the ceiling can go. encryptedSharedPreferences: true goes with it — v10 ignores the parameter and migrates on first access, and v11 has removed it. file_picker 12's API is smaller and the call sites got smaller with it. FilePicker.platform.pickFiles returning a result whose files list had to be checked for emptiness becomes FilePicker.pickFile returning one nullable file, which is what both callers wanted. PlatformFile.bytes (populated only when withData was asked for) becomes readAsBytes(), so the "bytes, or read the path, or give up" ladder both callers carried is one await — and the give-up branch that raised errors.noFile and the import's notJson is gone, because a file that was picked can now always be read. Verified: flutter analyze is clean and flutter test still passes 32. flutter build apk --debug succeeds and prints no KGP warning, where the build before this named both plugins. Not verified: nothing was exercised on a device — the phone came off USB before the reinstall, so this APK has not run. The two things to try first are the ones that changed under the picker: attach a PDF to a service record, and Settings, data, import a previously exported JSON. Biometric login is the third — it should survive, since v10 migrates rather than resets, but a device that had it on is the only place that claim can be checked, and if the migration does fail the app treats it as stale credentials and asks for the password. Android is the only target built; the win32 bump underneath is untested because this app has no windows/ folder to build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 22:06:11 +02:00
tajniak81andClaude Opus 5	a2d9efec7e	Phone App: take the car screen off hardcoded English The previous commit left the car screen half translated: its tab labels went through t(), and everything underneath them did not. A Polish user opening a car got translated tabs over English tiles, English forms and English dialogs, which is worse than either extreme because it reads as a bug rather than as a missing translation. So the whole screen and everything it opens now reads from the language files: the record tiles, the share and delete-car dialogs, the service and part sheets it hosts, record_form_sheets.dart, car_form_sheet.dart, and the attachment field whose buttons surface inside all of them. Almost none of these strings are new. The Web App has said all of this in three languages since `b6bb6b1`, so forms., enums., attachment.* and errors.* are copied out of its language files the same way car.* was, and Polish and Danish arrive complete. What is written here is only what the phone alone needs, and the categories are worth naming because they are the reason the two apps' files are not identical: tooltips, because the web labels its buttons; the tiles' running prose, because the web lays the same data out as table columns; client-side validation, because the web leans on the browser's `required`; and the snackbars. Three things changed shape rather than just wording. The per-record delete prompts were one template with a noun slotted in - "Delete this $what?" - which does not survive translation into a language that inflects the noun. Each collection now names its own confirmation string, which is what the web already had. The delete-car dialog counted with a hand-rolled `"$n $noun${n == 1 ? '' : 's'}"`. Polish has three plural forms, so that could not be translated at all; it now goes through the CLDR plurals in car.delete.. It also only ever named service records and parts, while the cascade takes maintenance, fuel, charges and documents too - the translated body names all six, so it is now passed the whole data set rather than two counts. The enum labels (fuel types, maintenance type/status, document and reminder types) were four const maps duplicated between the tiles and the pickers. They are one lookup against enums. now, with an unknown value falling back to the raw key rather than a blank - the server owns that enum, and a value added there should stay legible in an app that has not caught up. Found and fixed while testing: the view picker rendered the literal string "car.tabs.provider" as a row label on an unlinked car. That key does not exist by design - a linked car's tab is named after the service, an unlinked one falls back to car.tabs.connected - and the picker was the one caller that did not know it. Verified by flutter analyze (clean), flutter test - 19 pass, 7 of them new - and flutter build apk --debug. The new tests cover what the analyzer cannot see: the lookups built from a key at render time (car.tabs.$key, enums.fuelType.$v, the delete dialog's plural counts, the connected service's readings) are checked to have a real label in all three languages, so a catalogue entry with no translation fails a test instead of reaching a screen as a raw key path. That is the check that caught the bug above. A one-off script also confirmed all 550 static t() keys resolve in en.json. Not verified: still nothing run against a live API Server or on a device. Known gaps, deliberately left: admin_users_screen.dart is still English, and settings.integrations.* / charging.control.* exist in en.json only. The second one is not the phone's alone - the Web App has exactly the same gap, so translating that OCPP and connector vocabulary belongs to both apps in one pass rather than letting the phone run ahead of the app the strings are copied from. Both are now recorded in TRANSLATIONS.md, which had claimed the car screen as untranslated and the web app as complete. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 21:49:48 +02:00
tajniak81andClaude Opus 4.8	ee28b522c7	Bring the Phone App up to parity with the web app Four rounds of web-app features never reached the phone: fuel, maintenance, document and reminder tracking; attachments; the currency setting and the locale split; and technical check history. The README claimed full parity throughout, so the gap was invisible. Catch the phone up, mirroring the web components field for field. Car detail grows the web app's tabs, in its order: technical checks, maintenance, fuel (with the summary panel), documents and reminders, beside the existing service and parts lists. The derived figures are the server's and are rendered as "—" wherever it sent null — a window with a missed fill has no consumption, and a plausible-looking 0.0 there would be a lie. Attachments hang off service records, technical checks, workshop visits, refills, documents and parts on identical terms, so one field and one apply helper cover all six rather than being copied per form. As on the web, the form only collects intent: the file endpoints address a record that must already exist, so a create-with-file is two calls, and a failure on the second reports as an attachment error because the metadata is committed. Two bugs fixed on the way: - _carPayload omitted technicalCheckIntervalDays. The API rewrites every column from the body, so any car edit — including the one-tap odometer update — silently zeroed the car's inspection interval. - main() never called initializeDateFormatting, so month names ignored the chosen language that the new Language picker exists to set. Luxembourgish and Romansh are deliberately left off the language list: intl ships no symbols for them and throws rather than falling back, which would take out every date on screen. The browser has full ICU data and has no such limit, so the web app can offer them. The server only validates a locale's shape, so an unrenderable tag can still arrive from the web; format.dart resolves through a supported-language check and falls back to en-US. Labels for the language/region/currency lists are hand-kept because Dart has no Intl.DisplayNames. The lists mirror validCurrencies in me.go. file_picker is pinned to ^10: v8 compiles against android-34, which no longer builds against the other plugins' compileSdk requirement of 36. Adds the project's first test, covering the parts that fail silently rather than loudly — null derived fields, the badge wording, and the locale guard. The phone was not authorized over ADB, so the UI was not exercised on a device: this is analyzer-, test- and build-clean, and every JSON field name and route was cross-checked against models.go and server.go. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 15:15:01 +02:00

tajniak81andClaude Opus 5

7718b32013

Phone App: off the plugins that bring their own Kotlin

flutter build apk warned that file_picker and shared_preferences_android apply
the Kotlin Gradle Plugin themselves, and that a future Flutter will refuse to
build an app whose plugins do. Both have versions that let Flutter's built-in
Kotlin do it instead; neither of them is a version bump on its own.

shared_preferences_android was free — 2.4.27 is inside the constraint that was
already there and only pub.lock was holding it back. file_picker is not: 10 and
11 both apply KGP, so 12 is the floor, and 12 split into federated packages
whose windows one wants win32 ^6, which flutter_secure_storage 9 forbids.

So the fix reaches flutter_secure_storage, and that is the part worth reading
twice. v11 satisfies win32 but its changelog is explicit: data written by a
version before v10 is unusable after it, because v10 is what migrates the
Jetpack Security (EncryptedSharedPreferences) backend Google deprecated to the
package's own ciphers. Going 9 to 11 in one step would leave the stored
credentials unreadable and quietly switch biometric login off for anyone who
had it on. v10 satisfies win32 ^6 just as well, so the constraint is pinned
below 11 with the reason written down: once a build carrying v10 has run on
every device that had biometric login enabled, the ceiling can go.

encryptedSharedPreferences: true goes with it — v10 ignores the parameter and
migrates on first access, and v11 has removed it.

file_picker 12's API is smaller and the call sites got smaller with it.
FilePicker.platform.pickFiles returning a result whose files list had to be
checked for emptiness becomes FilePicker.pickFile returning one nullable file,
which is what both callers wanted. PlatformFile.bytes (populated only when
withData was asked for) becomes readAsBytes(), so the "bytes, or read the path,
or give up" ladder both callers carried is one await — and the give-up branch
that raised errors.noFile and the import's notJson is gone, because a file that
was picked can now always be read.

Verified: flutter analyze is clean and flutter test still passes 32. flutter
build apk --debug succeeds and prints no KGP warning, where the build before
this named both plugins.

Not verified: nothing was exercised on a device — the phone came off USB before
the reinstall, so this APK has not run. The two things to try first are the
ones that changed under the picker: attach a PDF to a service record, and
Settings, data, import a previously exported JSON. Biometric login is the third
— it should survive, since v10 migrates rather than resets, but a device that
had it on is the only place that claim can be checked, and if the migration
does fail the app treats it as stale credentials and asks for the password.
Android is the only target built; the win32 bump underneath is untested because
this app has no windows/ folder to build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-22 22:06:11 +02:00

tajniak81andClaude Opus 5

a2d9efec7e

Phone App: take the car screen off hardcoded English

The previous commit left the car screen half translated: its tab labels went
through t(), and everything underneath them did not. A Polish user opening a
car got translated tabs over English tiles, English forms and English
dialogs, which is worse than either extreme because it reads as a bug rather
than as a missing translation.

So the whole screen and everything it opens now reads from the language
files: the record tiles, the share and delete-car dialogs, the service and
part sheets it hosts, record_form_sheets.dart, car_form_sheet.dart, and the
attachment field whose buttons surface inside all of them.

Almost none of these strings are new. The Web App has said all of this in
three languages since b6bb6b1, so forms.*, enums.*, attachment.* and errors.*
are copied out of its language files the same way car.* was, and Polish and
Danish arrive complete. What is written here is only what the phone alone
needs, and the categories are worth naming because they are the reason the
two apps' files are not identical: tooltips, because the web labels its
buttons; the tiles' running prose, because the web lays the same data out as
table columns; client-side validation, because the web leans on the browser's
`required`; and the snackbars.

Three things changed shape rather than just wording.

The per-record delete prompts were one template with a noun slotted in -
"Delete this $what?" - which does not survive translation into a language
that inflects the noun. Each collection now names its own confirmation
string, which is what the web already had.

The delete-car dialog counted with a hand-rolled `"$n $noun${n == 1 ? '' :
's'}"`. Polish has three plural forms, so that could not be translated at
all; it now goes through the CLDR plurals in car.delete.*. It also only ever
named service records and parts, while the cascade takes maintenance, fuel,
charges and documents too - the translated body names all six, so it is now
passed the whole data set rather than two counts.

The enum labels (fuel types, maintenance type/status, document and reminder
types) were four const maps duplicated between the tiles and the pickers.
They are one lookup against enums.* now, with an unknown value falling back
to the raw key rather than a blank - the server owns that enum, and a value
added there should stay legible in an app that has not caught up.

Found and fixed while testing: the view picker rendered the literal string
"car.tabs.provider" as a row label on an unlinked car. That key does not
exist by design - a linked car's tab is named after the service, an unlinked
one falls back to car.tabs.connected - and the picker was the one caller that
did not know it.

Verified by flutter analyze (clean), flutter test - 19 pass, 7 of them new -
and flutter build apk --debug. The new tests cover what the analyzer cannot
see: the lookups built from a key at render time (car.tabs.$key,
enums.fuelType.$v, the delete dialog's plural counts, the connected service's
readings) are checked to have a real label in all three languages, so a
catalogue entry with no translation fails a test instead of reaching a screen
as a raw key path. That is the check that caught the bug above. A one-off
script also confirmed all 550 static t() keys resolve in en.json.

Not verified: still nothing run against a live API Server or on a device.

Known gaps, deliberately left: admin_users_screen.dart is still English, and
settings.integrations.* / charging.control.* exist in en.json only. The
second one is not the phone's alone - the Web App has exactly the same gap,
so translating that OCPP and connector vocabulary belongs to both apps in one
pass rather than letting the phone run ahead of the app the strings are
copied from. Both are now recorded in TRANSLATIONS.md, which had claimed the
car screen as untranslated and the web app as complete.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-21 21:49:48 +02:00

tajniak81andClaude Opus 4.8

ee28b522c7

Bring the Phone App up to parity with the web app

Four rounds of web-app features never reached the phone: fuel, maintenance,
document and reminder tracking; attachments; the currency setting and the
locale split; and technical check history. The README claimed full parity
throughout, so the gap was invisible. Catch the phone up, mirroring the web
components field for field.

Car detail grows the web app's tabs, in its order: technical checks,
maintenance, fuel (with the summary panel), documents and reminders, beside
the existing service and parts lists. The derived figures are the server's
and are rendered as "—" wherever it sent null — a window with a missed fill
has no consumption, and a plausible-looking 0.0 there would be a lie.

Attachments hang off service records, technical checks, workshop visits,
refills, documents and parts on identical terms, so one field and one apply
helper cover all six rather than being copied per form. As on the web, the
form only collects intent: the file endpoints address a record that must
already exist, so a create-with-file is two calls, and a failure on the
second reports as an attachment error because the metadata is committed.

Two bugs fixed on the way:

- _carPayload omitted technicalCheckIntervalDays. The API rewrites every
  column from the body, so any car edit — including the one-tap odometer
  update — silently zeroed the car's inspection interval.
- main() never called initializeDateFormatting, so month names ignored the
  chosen language that the new Language picker exists to set.

Luxembourgish and Romansh are deliberately left off the language list: intl
ships no symbols for them and throws rather than falling back, which would
take out every date on screen. The browser has full ICU data and has no such
limit, so the web app can offer them. The server only validates a locale's
shape, so an unrenderable tag can still arrive from the web; format.dart
resolves through a supported-language check and falls back to en-US.

Labels for the language/region/currency lists are hand-kept because Dart has
no Intl.DisplayNames. The lists mirror validCurrencies in me.go.

file_picker is pinned to ^10: v8 compiles against android-34, which no longer
builds against the other plugins' compileSdk requirement of 36.

Adds the project's first test, covering the parts that fail silently rather
than loudly — null derived fields, the badge wording, and the locale guard.

The phone was not authorized over ADB, so the UI was not exercised on a
device: this is analyzer-, test- and build-clean, and every JSON field name
and route was cross-checked against models.go and server.go.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-17 15:15:01 +02:00