LocalList

Overview

LocalList is a private .NET MAUI project for creating, saving, and sharing grocery lists across supported device platforms. A reusable item catalog and named lists are stored locally with SQLite, while JSON files and compressed QR payloads provide explicit snapshot transfer between devices. The application does not depend on an account system, server API, or cloud synchronization service.

1. 1DiscoveryNot complete
2. 2ResearchNot complete
3. 3PlanningNot complete
4. ✓PrototypeComplete
5. 5ValidationNot complete
6. 6DocumentationNot complete
7. 7ReleaseNot complete
8. 8MaintenanceNot complete

Current Focus

Current engineering priorities are stronger import limits and validation, transactional list persistence, automated coverage for storage and interchange behavior, and consistent permission and file-integration behavior across supported platforms.

Design Decisions

Use a local-first application boundary

Keep core list creation, editing, persistence, file interchange, and QR transfer on the device so normal use does not require an application server or internet connection.

Use .NET MAUI for cross-platform delivery

Share the application model, XAML interface, and most workflow code across mobile and desktop targets while retaining platform-specific integration points where required.

Persist saved lists with SQLite

Store the reusable catalog, named-list records, and saved list items in an on-device relational database so saved data survives normal application restarts.

Model interchange separately from persistence

Use a versioned JSON envelope containing list content rather than exposing internal database identifiers in shared snapshots.

Make import behavior explicit

Ask the user to merge an imported snapshot into the active list or replace the active list instead of applying an implicit conflict policy.

Use compressed QR snapshots for direct transfer

Compress and encode the existing interchange model for QR display, providing a serverless transfer option for lists that fit within the practical payload limit.

Use platform file and share services

Rely on native file pickers, file saving, sharing, and camera permission flows instead of building a separate storage or transport service.

Tradeoffs

Local-first storage versus synchronized access

On-device state supports offline operation and avoids mandatory accounts or hosting, but lists do not update automatically across devices.

SQLite persistence versus remote shared storage

SQLite provides restart-durable named lists with low infrastructure overhead, while collaboration, remote backup, and coordinated multi-device changes remain outside the current architecture.

Snapshot transfer versus live synchronization

Files and QR codes make transfer explicit and serverless, but sender and recipient copies diverge after import and have no automatic conflict resolution.

Compressed QR transfer versus payload capacity

Compression makes direct visual transfer practical for smaller lists, while larger snapshots require file export because QR capacity is limited.

Readable JSON versus protected interchange

A versioned JSON format is portable and straightforward to inspect, but shared snapshots require stronger validation and are not encrypted or authenticated.

Shared MAUI code versus platform-specific integration

A common application and UI layer reduces duplicated feature code, but permissions, file activation, packaging, and device behavior still require platform-specific implementation and verification.

Known Limitations

• Imported files and QR snapshots need stronger size, item-count, field-length, and numeric constraints.
• List save and replacement operations need transactional guarantees so partial failures cannot leave incomplete persisted state.
• Shared JSON and QR snapshots are not encrypted or authenticated and should be treated as deliberately shared data rather than secure synchronization.
• Temporary, imported, and quick-share files do not yet have a defined cleanup and retention lifecycle.
• Permission, file-activation, and sharing behavior is not yet implemented and verified consistently across every targeted platform.
• Saved lists persist locally, while an unsaved active list and current interface preferences do not survive process termination.
• There is no account system, server API, cloud synchronization, or automatic multi-device conflict resolution.
• The project does not yet include an automated test suite or application build pipeline.
• Release packaging, distribution-channel validation, accessibility review, and production readiness are not established.

Development Log

Lessons Learned

• Offline operation and synchronization are different capabilities; local persistence plus explicit sharing does not create shared state.
• A versioned interchange format also needs resource limits and field-level validation to form a reliable import contract.
• Delete-and-replace persistence operations should be transactional when partial failure could remove valid data.
• Cross-platform UI reuse does not remove the need for platform-specific permission, activation, packaging, and device testing.
• Compression and encoding improve QR portability but do not provide confidentiality or authenticity.
• Session-long view-model state is not a substitute for explicitly persisted preferences or draft recovery.
• Build success does not establish complete validation when analyzer warnings, platform behavior, and automated tests remain unresolved.

Future Improvements

• Centralize bounded validation and cancellation behavior across file, QR, and platform share imports.
• Wrap saved-list creation and replacement in database transactions and add recovery-focused integration tests.
• Add automated coverage for merge rules, totals, serialization, persistence, and malformed input.
• Introduce versioned database migrations and explicit relationship and deletion behavior.
• Persist interface preferences and evaluate safe recovery for an unsaved active list.
• Define cleanup rules for cached imports, shared files, and locally generated exports.
• Complete and verify permissions, file associations, and sharing behavior on each supported platform.
• Resolve current view-model generation and compiled-binding warnings, then add continuous build checks.
• Align in-application help and supporting documentation with the verified feature set.

Future Direction

The next phase is to harden the local-first foundation by improving persistence recovery, temporary-file lifecycle management, cross-platform verification, and build automation. Any future backup or synchronization capability would require a separate design for identity, privacy, conflicts, and operations rather than extending the current snapshot-transfer model implicitly.