The Field-App Update That Cannot Wait
At a depot preparing for a 07:30 shift, the inspection team needs to make seal condition a required entry. Connected devices can receive the revised form at 07:00. One technician’s device remains disconnected, holding an unfinished inspection saved at 06:40. The release has to reach the next shift without changing what that technician already started.
For frequent changes to supported forms and workflows, a versioned metadata runtime is a sound default. It can deliver a new definition separately from an application package while keeping an in-progress record associated with the definition under which it opened. That advantage depends on the installed runtime already understanding the revised field and validation rule.
The useful measure of release speed includes the return trip. At 07:15, when the disconnected device reconnects, can the technician finish the old inspection, sync it, and identify which rules governed it? A quick publish offers little operational value if the team cannot answer those questions or withdraw a troublesome definition without losing track of records created under it.
What Actually Runs on the Device?
In the metadata model, an installed runtime interprets versioned definitions for forms, rules, and workflow. Call the existing inspection definition D12 and the revised one D13. D13 requires seal condition on newly opened inspections. An inspection opened under D12 retains its D12 identifier, even after D13 reaches the device.
Offline operation makes the storage boundary important. A device must hold the definition needed to open or resume a form locally; a design that fetches that definition when the form opens cannot perform the same task while disconnected. The team also needs a clear rule for how long older definitions remain available to unfinished records.
With code generation, the team changes its application model, generates source, builds and tests the result, then distributes an app package. The comparable release moves from build B1 to B2. Each local record should retain enough provenance to identify the build that created or last edited it. The app can package its revised behavior with the release, though distributing that package becomes part of the field update.
The distinction is the update boundary. D13 may travel without a new app package if the installed runtime already supports its field and validation behavior. A change that requires a new runtime capability still requires deployment. The generated approach puts the changed behavior through the build and app-release path from the outset.
Release a New Form Without Losing Offline Records
Start the rollout test with an incomplete D12 inspection saved offline at 06:40. Publish D13 to a small group of connected devices at 07:00, leaving the inspection device disconnected until 07:15. On reconnection, reopen the unfinished record before creating a new one. It should still identify D12 and follow the rules under which the technician began it; a fresh inspection on an updated device should use D13.
Next, submit records from both definitions. During a staged rollout, the sync service must accept valid D12 and D13 inspections. Retain each submitted record’s definition ID and local-data schema version so a later investigation can reconstruct the path it took. If D13 must be withdrawn, stop devices from opening new D13 forms. Withdrawal does not turn inspections already written under D13 back into D12 records. The team needs an explicit plan for completing and syncing those records.
Run the equivalent sequence with generated code. Distribute B2 to a subset of devices while B1 remains in use, then verify that both builds can sync their records. If B2 changes local storage, test the database migration with an unfinished B1 inspection present. Interrupt the upgrade and the subsequent sync in separate runs; the inspection should remain recoverable, and the device should resume from a known state. Record the app build ID and local-data schema version with the submission.
These are acceptance tests, not claims that either architecture passes automatically. The release is ready when the team can show where the 06:40 record went, which rules applied to it, and what happens if the new release is withdrawn.
When Sync Fails, Which Model Can You Debug?
A technician reports that an inspection will not sync. The useful question is where it stopped: on the device during validation, in transit after an interrupted connection, or at the server. A proof of concept should force a reproducible failure rather than relying on a successful demonstration.
For the metadata candidate, submit an offline inspection missing the seal-condition value, then reconnect. Ask for runtime logs that name the device and record, the definition ID, and the rule responsible for the rejection. For the generated candidate, ask for the build ID, the source-level path through validation, and a trace of the failed submission. In both cases, include the local-data version and the point where sync stopped. Repeat the submission after interrupting the connection to see whether the evidence distinguishes local validation from server rejection.
The two models also offer different routes to a fix. A generated application can implement bespoke device behavior in source code, subject to the team’s build and deployment process. A metadata runtime needs a supported extension point for that behavior; otherwise, the runtime itself must change. That boundary matters when a field report concerns device access rather than a form rule.
An engineer receiving only the technician’s report should be able to travel from the device and record identifiers to the responsible definition or build, then to the rejecting logic. If that path depends on guessing which version a device held, the diagnostic design needs work before rollout.
Own the Rules After the First Release
Put the seal-condition change through version control before judging either tool by its editor. For metadata, a reviewer should be able to see the change from D12 to D13 in a human-reviewable definition: the new field, its required rule, and the workflow point where validation runs. A deployable definition also needs an identifiable version so the reviewed change matches what reaches devices.
For generated code, establish which files the team owns. If developers change the model and regenerate, a reviewer needs to see both the model change and the resulting source change. Hand-editing generated output creates a fragile ownership boundary when the next generation pass replaces those edits. Source-level access is valuable only when the build process makes that boundary clear.
Performance deserves a workload test on the same representative device and stored inspection set. Measure startup, local-record search, seal-condition validation, and queued-record sync for both candidates. An older .NET mobile deployment may expose costs differently from a newer device, and interpretation alone does not establish whether any difference matters to the technician. Record runtime or app build ID and local-data version before starting the release-time clock, too; otherwise, timing results can conceal a different deployment state.
Security stays on the ownership list whichever model wins. Locally stored inspections need protection, definition delivery needs authentication in the metadata design, and the installed runtime or generated app needs maintenance. Those responsibilities belong in the operating plan alongside version review and release testing.
Pick the Model That Matches Your Change Boundary
The choice turns on which changes the team can release and recover with confidence:
- Favor versioned metadata when supported form and workflow edits are frequent, definitions can reach the intended devices in a controlled rollout, and unfinished records can remain pinned to their original definitions.
- Favor generated code when custom device integration, bespoke logic, or source-level ownership drives the application, and the team can manage package distribution and app-version coexistence.
- Consider a mixed design when device access and sync are stable in application code, while bounded workflow changes can use versioned definitions supported by the installed runtime.
Use the same offline inspection task to compare candidates. Make seal condition required, deploy the change to a subset, and leave one device disconnected with an unfinished inspection. Reconnect it, complete and sync the old record, then test withdrawal of the new change and diagnosis of a rejected record. Record the definition or build ID and local-data version before each run. This keeps the comparison tied to the change the depot actually needs to operate, rather than to how quickly a tool can display a new field.
Make the Next Field Update Boring
Choose the model whose change, deployment, and recovery boundaries the team can operate confidently. The release record should make an inspection’s origin plain, whether it links the synced record to D12 or D13 or to build B1 or B2.
Before the next shift, the technician reconnects the inspection device at the depot. The form begun at 06:40 opens with its unfinished work intact. Sync completes, and the release record shows exactly which definition or build handled that inspection.
Join the Conversation
Share your thoughts.
Your Comment