DEV Community: Salil Harit

Testing the business meaning of a Flutter staffing dashboard

Salil Harit — Wed, 14 Oct 2026 10:57:55 +0000

A staffing dashboard helps an operator decide where attention is needed. Its usefulness depends on what its labels mean and whether the operator can act on them.

In SEC ERP's mobile work, I shaped tests around those decisions: distinguishing assignment from presence, publishing the right duty result, and keeping staffing actions usable on a phone.

Test the facts behind the labels

An assignment, an attendance record, and an active duty session represent different facts. The roster needs to preserve those distinctions.

One regression fixture includes an assigned guard with null attendance and duty evidence. This exercises a realistic incomplete record. A perfectly populated fixture would miss the question that matters: what does the interface show when presence evidence is unavailable?

The read-only view receives no assignment callback, and its test verifies that assignment controls are absent. Action availability follows the capability supplied to the view.

Verify what a successful response means

For duty activation, a non-null response is too weak an assertion. The acknowledgment must correspond to the guard and assignment that initiated the request.

Tests change returned identity, company, facility, deployment, shift, date, status, and required evidence. An incorrect result must not publish confirmed duty.

A separate test accepts cloud activation and then fails device persistence. It expects confirmed duty to survive with a separate mirror-failure outcome. That tests the partial success the architecture is designed to handle.

Exercise the action inside its real layout

The roster presents posts and shifts as a grid. The assignment action must stay reachable and retain the selected cell's identity.

The widget test uses the application theme, a 360-by-800 viewport, and enlarged text. It scrolls to a target cell, taps its assignment button, and verifies the exact post and shift delivered to the callback.

This combines layout and behavior in a useful scenario: an operator can reach the action and act on the intended staffing gap.

Test changes during requests

Other regressions introduce logout, disposal, a newer duty selection, and listener-driven changes before or during publication. Controllable service completion reproduces each ordering precisely.

The assertion is that newer state survives while obsolete work cannot publish or persist. This protects the actual user journey beyond the initial screen render.

I chose these cases by the decisions they protect: interpreting staffing evidence, accepting duty confirmation, preserving current state, and reaching the correct assignment action. Device and operator checks answer additional questions such as location behavior and field usability.

The testing strategy gives architectural decisions an executable form. Each case checks a fact the dashboard communicates or an action its users depend on.

Keeping Flutter dashboards correct when async requests finish out of order

Salil Harit — Wed, 14 Oct 2026 10:56:58 +0000

A guard starts duty while an older dashboard request is still loading. Activation succeeds and the dashboard updates. Then the older response arrives and replaces the newer state.

The network request succeeded, but the product now shows an obsolete answer. In SEC ERP's mobile app, I addressed this with authentication generations and duty revisions in shared state.

Give results an owning context

A mounted check answers whether a widget still exists. Operational state also needs to know whether a result belongs to the current account.

Async work captures the provider's authentication generation before waiting. Before publication, it checks disposal, session teardown, and whether the generation still matches. An earlier response cannot restore old identity or dashboard data after that session boundary changes.

The request may finish remotely. The check controls whether its result becomes current client state.

Track changes inside the same account

An account can stay signed in while the selected duty changes. Authentication generation alone cannot distinguish those situations.

Duty activation therefore captures a duty revision too. Publication requires both values to match. The returned record must also match the requested guard, company, site, deployment, shift, and date, and contain required activation evidence.

Ordering checks and record validation complement each other. A response can arrive at the right time and still describe the wrong operation.

Treat notification as a control boundary

Publishing state invokes synchronous listeners. A listener can select another duty or invalidate the account before notification returns.

The activation path rechecks its assumptions after notification, before local persistence, and again after persistence. This prevents an obsolete selection from being mirrored merely because its cloud request succeeded.

The principle extends beyond await: whenever control passes to another owner, ask what could change before control returns.

Make races deterministic

The regression tests use controllable service completion. They start activation, introduce logout, disposal, or a newer duty, and then deliver the acknowledgment. Another case replaces duty from a listener during publication.

Assertions verify the operational effect: obsolete work must not publish or persist, and the newer selection must survive.

Session generations establish account continuity. Domain revisions establish operation continuity. Acknowledgment validation establishes identity. Together, they keep the dashboard aligned with the current operational decision as requests finish in whatever order the network allows.

Designing a SQLite outbox for field operations in Flutter

Salil Harit — Wed, 14 Oct 2026 07:52:16 +0000

When a field worker enters operational information, the valuable part is the work they have already done. Connectivity should not be the only thing keeping that work alive.

In SEC ERP's mobile app, I designed a buffered-write path around that requirement. Flutter handles the interaction, SQLite preserves the request, and Supabase processes the cloud write.

Persist intent before transport

The buffer inserts a queue entry before sending. It records the originating account, operation, payload, creation time, and status. If connectivity is unavailable, the request stays pending. A conditional claim moves an eligible entry to IN_FLIGHT before processing.

Compared with keeping retries in memory, this adds persistence and queue management. I chose that complexity because recovery needs a record that survives beyond the request's lifetime.

Make retries an architectural decision

A response can disappear after the server accepts an insertion. Sending again can create another record. Automatically retrying every error would turn a network problem into a data-quality problem.

The buffer classifies failures: recognized rejections are retained for correction, uncertain INSERT failures require review, and other eligible failures enter RETRYING.

The tradeoff is deliberate. Some requests need review instead of automatic completion, but entered work remains available. Where automatic insertion replay is required, stable request identities and server deduplication provide a stronger contract.

Attach recovery to the originating account

Queue entries carry an owner identifier. Reads and status updates use that owner, and processing checks account continuity around claims and transport.

This makes ownership part of persistence. Switching accounts does not transfer the previous account's pending work to the new user.

Expired claims also have explicit recovery rules: UPDATE operations return to RETRYING, while other expired in-flight operations require review. Recovery follows the operation type.

Separate confirmation from caching

Duty activation shows why one success flag is insufficient. Supabase can confirm activation while the device fails to cache the returned record.

The provider validates and publishes the confirmed duty, then attempts local mirroring. A mirror failure is reported separately while confirmed duty remains in live state. Recovery can focus on device storage rather than repeating an already-confirmed action.

Validate the failure boundaries

Regression cases challenge zero-row updates, wrong returned targets, rejected activation, and accepted activation followed by local persistence failure.

Each protects a business meaning across a failure boundary. The result is an architecture where field work has a durable home, retries have explicit rules, and cloud confirmation remains distinct from device storage.

Building a bulk import pipeline for fixed-asset accounting in Spring Boot

Salil Harit — Wed, 14 Oct 2026 07:14:10 +0000

In fixed-asset accounting, importing a spreadsheet means reconstructing a business model: who purchased an asset, what it cost, which accounting rules apply, and which physical units the business now owns. If those relationships are wrong, the consequences travel into custody records, depreciation schedules, and disposal reports.

I built the import pipeline in FAMS, a fixed asset management system using Flutter, Spring Boot, and PostgreSQL. The business problem was to bring existing asset registers into the application without making accountants manually recreate every vendor, asset definition, and purchase. The engineering problem was to preserve accounting relationships while handling validation, partial failures, and growing datasets.

Start with the asset lifecycle

The data model separates three responsibilities. A purchase header holds invoice-level information. Its items hold asset quantities and financial details. Individual labels identify the physical units that continue through allocation, verification, depreciation, and disposal.

Consider an invoice for ten identical laptops. The invoice is one financial transaction, but the laptops can go to different employees and eventually have different disposal histories. Separating financial ownership from physical identity lets those histories evolve without rewriting the purchase.

That model shapes ingestion. The import must create connected domain records, rather than copy spreadsheet cells into one flat table.

Put accounting decisions behind a service boundary

The architecture follows a clear path:

Excel → Flutter parsing and validation → REST bulk endpoint → Spring Boot services → JPA repositories → PostgreSQL

Flutter interprets the workbook and presents validation feedback. The backend owns reference resolution, dependency checks, and persistence. Controllers coordinate requests and responses; services implement the business operation; repositories handle relational access.

This keeps accounting behavior reusable across clients. Changing a screen should not change how a purchase connects to its asset definitions or financial rules. It also gives debugging a useful structure: distinguish a parsing problem from a reference-resolution problem or a database write failure.

Resolve dependencies in business order

Spreadsheet users work with names. Database relationships work with identifiers. Bridging that gap is a substantial part of the pipeline.

For an asset item, the service resolves its block, then its sub-block using the resolved parent. It resolves the depreciation rule using both its name and method, and then finds or creates the asset definition with those references. Vendor resolution similarly connects the purchase to the appropriate company-specific master.

The order matters. A sub-block needs its block identity; an asset definition needs the accounting references that describe it. Resolving those prerequisites inside the import reduces the separate setup work required before an accountant can load a register.

Company identity is included in relevant lookups. Two companies can use the same asset or vendor name without those names implying the same record.

Cache repeated resolutions within the import

A register often repeats the same vendor, asset definition, unit, and depreciation rule. Looking up each reference again for every item repeats work without adding business value.

The bulk request creates an import context with maps for these resolutions. Keys reflect the domain: company and vendor name; company, block, and sub-block name; or company, rule name, and depreciation method. When the service creates a vendor or asset definition, it remembers that result for subsequent entries.

This makes reuse explicit at the application layer, including across separate transaction calls. The cache lifetime matches the import operation, keeping the optimization close to the workflow it serves.

Make one purchase the unit of consistency

The bulk controller processes submitted transactions individually and returns an outcome for each. Each service call uses a database transaction to create the purchase and its related items together.

This boundary serves two business needs. A failed item should not leave its purchase half-created. At the same time, one bad purchase should not undo other valid purchases in the upload. The controller records each success or failure and continues, giving the interface enough information to direct corrections.

The response position identifies a submitted transaction; the frontend maps that outcome back to the workbook. This distinction matters when several spreadsheet entries belong to one business transaction.

Bound Hibernate's managed state

Within a large purchase, JPA can accumulate managed entities as items are created. I added a flush-and-clear step every 20 items, then reacquired the purchase before continuing:

// Simplified excerpt inside the transactional item loop.
entityManager.persist(item);
if ((index + 1) % 20 == 0) {
    entityManager.flush();
    entityManager.clear();
    purchase = entityManager.find(Purchase.class, purchaseId);
}

Flushing synchronizes pending writes; clearing releases managed state and detaches the parent too, which explains the reacquisition. The purchase transaction remains the consistency boundary. This addresses persistence-context growth while preserving the business operation's transaction semantics.

Results

The pipeline was client-tested with 956 records, and I personally tested imports up to 10,000 records.

The architecture connects those workload results to a practical outcome: accountants can load existing registers through a familiar spreadsheet workflow, while the application constructs the relationships needed for the rest of the asset lifecycle. Ordered dependency resolution removes setup friction, transactional writes preserve connected purchases, cached lookups reduce repeated work, and per-entry feedback makes corrections manageable.