DataStore Compliance / Flutter compliance UI prototype / 2026
Connecting a Flutter fieldwork prototype through one shell.
Shared navigation, typed demo records and reusable Material components connect the prototype's forms, check-in and incident screens.
- ROLE
- Software engineering
- STATE OF THE BUILD
- Prototype
- RECORD UPDATED
THE WORK
The project.
DataStore Compliance turns a set of fieldwork screens into a connected Flutter prototype. One shell owns the main tabs and secondary routes, while feature screens use callbacks and shared components to stay consistent. The implemented work is the interface structure; form persistence, authenticated sessions and offline synchronization still need services behind them.
IMPLEMENTATION
Design choices.
- The shell owns navigation and features expose callbacks. This makes the connected flow explicit without coupling every screen to the app's route decisions.
- Typed fixtures let related screens represent the same kinds of records before a backend exists. A displayed form status or offline-ready flag remains demonstration data, not proof of persistence or synchronization.
HOW IT FITS TOGETHER
Architecture.
- The app passes a display name into HomeShell after a local login interaction. AnimatedSwitcher changes the visible screen from LoginScreen to the shell; the flag driving that change isn't an authenticated session.
- HomeShell holds five main pages in an IndexedStack and selects the active tab. Dashboard actions call back to the shell, which either changes the tab or pushes a policy or incident page through Navigator. Feature screens can request navigation without each carrying the route structure.
- Typed Dart records and constant demo collections give the screens the same vocabulary for tasks, form states and prompts. A central Material 3 theme and reusable cards, buttons and status pills supply common presentation, keeping those choices out of individual feature implementations.
Explore the architecture map7 components · 6 connections
Flutter shell, feature screens and placeholder actions
The app holds local demo-session state, the shell owns navigation, and typed fixtures feed the feature widgets.
Entry and navigation
Flutter screen composition
Current action boundary
Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.
Choose a component to explore
Select a numbered component on the map or use the component menu. Its details and connections will appear here.
No component selected.
All connections (6)
- 01 · Login presentation → 02 · Local demo sessiondisplay-name callback · Direct call
- 02 · Local demo session → 03 · HomeShell navigationswitch demo view · Direct call
- 03 · HomeShell navigation → 05 · Feature screenstab selection / pushed page · Direct call
- 04 · Typed demo fixtures → 05 · Feature screensread static examples · Direct call
- 05 · Feature screens → 06 · Check-in, form and AI buttonsprototype action · Direct call
- 06 · Check-in, form and AI buttons → 07 · Placeholder feedbackshow stub message · Direct call
MADE WITH
Flutter · Dart · Material 3
ACCESS & INPUT
Security controls.
- The login button changes local presentation state. It doesn't check the entered password or obtain a session, so the prototype doesn't provide authentication.
- Device-status, biometric and certification-style labels are mock interface elements. They don't perform device checks, enforce access rules or establish a certification.
CHECKS & RESULTS
What was checked.
A source review shows what the code does. It is not a fresh test of the running app.
Code and development records reviewedReviewed
The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.
- Scope of this check
- Code review, not a fresh run of the app
NEXT
Still to work through.
The next implementation needs to make the interface's states real: drafts that survive a restart, submission retries and reconciliation, and collected device signals with acceptance rules for check-in. The included widget test only checks login labels and wasn't run for this account. The prototype isn't established as suitable for real care records or operational compliance work.