A Health Connect raw-record import is complete only when every page has been consumed under the SDK’s token contract. An apparently successful first page can contain only part of the requested interval. Keep page traversal, record identity and durable progress together so a restart converges on the same local records.
Use raw-record pagination when the product actually needs records. For a cumulative total, first consider the platform aggregation contract. Reading every page fixes incomplete traversal; it does not automatically fix overlapping sources or make a manual sum equivalent to a platform aggregate.
Treat the response token as part of the result
Android documents pageToken traversal and warns that some system or provider versions can return an empty string at completion instead of null. Normalize both terminal forms in the adapter. The documentation’s explanatory note is stricter than a null-only loop, so inspect the actual bridge result rather than copying a loop without checking its termination condition.
Android: raw-record pagination and empty terminal tokens
let token = savedToken;
do {
const page = await readPage({ ...fixedRequest, token });
await applyAndCheckpoint(page.records, page.nextToken);
token = page.nextToken;
} while (token != null && token !== "");This pseudocode describes an application adapter. Confirm field names and token serialization for the installed native module. Keep the record type, time bounds and filters fixed through traversal. A token should not be reused after silently changing the request it belongs to.
Checkpoint after durable application
The dangerous ordering is saving page B’s next token before its records are durably stored. A process interruption then skips those records forever on resume. Reverse the ordering or use a transaction that commits records and progress together. If a crash occurs after records are applied but before progress is saved, replay must use stable identities so it remains safe.
| Step | Durable progress | Local records |
|---|---|---|
| Apply A | second | A |
| Apply B, crash before checkpoint | second | A, B |
| Replay B and commit empty token | complete | A, B |
| Final synthetic total | complete | 30; not 50 |
The local fixture uses an in-memory map keyed by record ID. It produced A and B once each, total 30, and an empty terminal token after replay. This demonstrates the proposed ordering and upsert behavior. It does not execute the Android bridge, measure quota behavior or validate a production database transaction.
Protect retries from becoming a busy loop
Classify a transient page failure separately from terminal completion. Back off according to the current platform guidance and preserve the last committed progress. Put a bound on repeated attempts and keep the user-visible import pending or recoverable. A repeated nonterminal token should produce a diagnosable stalled traversal, not an infinite loop that repeatedly processes one page.
Record page number, record count and a redacted request identity for synthetic tests. Do not print health records or opaque tokens into public examples. A token is progress state, not a customer-facing percentage; record sizes and later corrections can make a simple pages-read progress bar misleading.
Review the native boundary and downstream totals
The reviewed UltraFit360 step path destructures records from one readRecords response. That narrow observation motivates pagination review; it is not proof that every wrapper lacks internal pagination. Verify the exact module version and implementation before attributing an end-user discrepancy to this call.
Acceptance should cover a one-page response, null completion, empty-string completion, failure before apply, failure after apply, duplicate records across replay and a source correction. Verify the final logical identities and derived summary, not only the number of HTTP or bridge calls. Keep the pagination article distinct from the source-priority policy: both can affect completeness, but they fail for different reasons.
Page traversal is not a snapshot guarantee. Records may change while an import is running, depending on the provider contract. Retain a fixed interval and define a follow-up reconciliation or supported changes workflow for corrections that occur during traversal. Do not advertise a complete historical mirror merely because the last token was consumed. The acceptance record should state which request was completed and what later synchronization is responsible for detecting changes after that point.
Bring the specific record types, device/OS targets and one failing or proposed data journey to scope a wearable integration review.
How should a Health Connect reader terminate pagination?
Traverse until the returned token is null or empty, and advance durable progress only after the page records have been applied safely.
Can I persist a page token before storing its records?
Doing so can skip records after a crash. Commit progress with the corresponding records or ensure records are durable first.
