TAMITOS Move development: recover a queued outing on return

The reviewed TAMITOS Move development build attempts to send a queued outing when the signed-in app opens or returns to the foreground. This gives a saved outing another opportunity to reach the service without asking the person to start a second run. The implementation also separates the outing still being recorded from earlier entries awaiting a retry. The change was reviewed in the November 5 development merge. Its availability in the current store build has yet to be confirmed.

Finishing a route and sending it are separate events

A person can finish moving before their phone is able to send the result. Think of a walk that ends where reception is poor. They put the phone away, open the app later and expect to see the same outing in their history. Asking them to start again to recover the old entry makes two unrelated actions depend on each other. Starting a fresh session means they want to record a new outing. Opening the app means they want to see where things stand.

The reviewed change adds a retry at that second moment. On the first frame after the signed-in interface mounts, the app checks for pending local entries. It checks again when the app returns to the foreground. An empty queue ends the check locally. If a pending entry exists, the app checks whether the service can accept it. The code bounds that availability check and leaves the entry queued when the service cannot be reached or does not support the operation.

What keeps the current outing separate?

The retry logic shares a queue with the start flow. The code serializes their work and protects the local record that an active recorder is still using. This matters when a person briefly leaves the app to check another screen while the outing is in progress. The app can receive a resume event even though the person has not finished. The background retry needs to recognize that the active record still belongs to the recording session.

Rapid resume events introduce another practical case. A second event can arrive while the first check is still working. The host records that it should check again after the current attempt. It does not begin a separate send for each event. The intended result is one orderly recovery path even when the interface comes and goes quickly.

A model example for a release check

Imagine a test account with one completed walk in the queue and another activity being recorded. Start with the network unavailable. Open the app and check that the completed walk stays queued. Bring the network back and return to the app. Check whether the old walk appears once in the movement history and whether the active recorder is still showing its own session.

Run a second version with no local entries. Verify that opening the app does not start a needless availability request for this feature. Then repeat with several quick returns to the foreground. Count the finish calls and the resulting history entries separately. A single entry in the interface could hide a duplicate request, while a single request does not by itself prove the history refreshed.

These are proposed checks for a test build. Use synthetic routes and a test account so a failed test cannot change a real participant's movement record. The code includes widget tests for opening with a queued record, resuming after an offline attempt and keeping an active session out of the drain. These tests document the expected behaviour. This review did not run them on a device.

What should a person see when recovery succeeds?

A successful recovery prompts the app to refresh the balance view and, where movement history is already loaded, refresh that history. The retry host is a part of the signed-in interface and has no separate screen. The useful acceptance check is whether the original outing becomes visible in the places a person already checks. A technical success message in a log provides only part of that answer.

The same distinction comes up when the app refreshes a contribution status and when it presents one outing across screens. Each flow needs a clear boundary between an operation being attempted and the result the person can see. Read the studio's contribution status review, outing totals review and support reply development note for related examples.

Does this change record a new outing?

The recovery described here concerns entries the app already holds. A new recording still has its own start and finish. The date of the development merge does not establish when this behaviour reaches a downloaded app. Follow QORPO Studio Live for development progress and see the TAMITOS Move overview for the product.