mobile-networking
Skill8 starsChanged 58 days agoMITView on GitHub
Implements and reviews mobile API integration across Flutter, Android, iOS, React Native and Kotlin Multiplatform. Use for HTTP clients, pagination, request cancellation, concurrent token refresh, resumable uploads and WebSocket lifecycle. Durable offline mutation queues belong to mobile-offline-sync.
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- mobile-accessibilitySkill
- mobile-analyticsSkill
- mobile-androidSkill
- mobile-architectureSkill
- mobile-authSkill
- mobile-billingSkill
- mobile-ciSkill
- mobile-code-reviewSkill
- mobile-debugSkill
- mobile-detect-stackSkill
- mobile-firebaseSkill
- mobile-flutterSkill
- mobile-hardwareSkill
- mobile-iosSkill
- mobile-kmpSkill
- mobile-migrationSkill
- mobile-notificationsSkill
- mobile-observabilitySkill
- mobile-offline-syncSkill
- mobile-performanceSkill
- mobile-privacySkill
- mobile-releaseSkill
- mobile-rnSkill
- mobile-securitySkill
- mobile-testSkill
- mobile-ui-uxSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Start from the project brief.
- Distinctive: line 31
Treat a connection indicator as a hint.
- Distinctive: line 34
Check session generation before persisting refreshed credentials or replaying requests.
- Distinctive: line 35
Use offline sync for durable queues, reconciliation and conflict resolution.
- Distinctive: line 39
Follow the server's cursor/offset contract.
- Distinctive: line 40
Avoid buffering large files entirely in memory.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Mobile Networking
Start from the project brief. Locate the actual client, request/response models, repository, session owner and nearest tests. Read the server contract or observed sanitized responses before designing pagination, retries or upload recovery. Preserve the requested audit/implementation scope.
Pick the reference
| Project | Read |
| Flutter | references/flutter.md |
| Android | references/android.md |
| iOS | references/ios.md |
| React Native / Expo | references/react-native.md |
| Kotlin Multiplatform | references/kotlin-multiplatform.md |
Define the request contract
- Record endpoint, method, identity, input bounds, response mapping, timeout/deadline, cancellation owner and observable failure. Keep transport details out of UI components.
- Validate untrusted responses at the boundary. Distinguish transport, HTTP, decoding and domain failures without exposing bodies or credentials in user messages/logs.
- Scope cache keys and in-flight results to the account, query and filters. An account change invalidates the old generation; late responses cannot write into the new account's store.
- Propagate cancellation to the transport when supported and fence late completions regardless. Leaving a screen is not evidence that a mutation was rolled back on the server.
Recover without duplicating work
- Treat a connection indicator as a hint; still handle request failure. Bound retries by attempt count/deadline, use backoff and honor applicable server retry instructions.
- Retry reads when their semantics permit it. Replay a mutation only when its server contract makes replay safe, for example an idempotency key retained for the same logical operation. A timed-out purchase/upload may already have succeeded.
- Coalesce refresh work for one active session. Waiting requests share its result, retry with a fresh credential at most within the declared budget, and do not recursively refresh a failing refresh endpoint.
- Check session generation before persisting refreshed credentials or replaying requests. Logout/account switch cancels or invalidates the old refresh; do not resurrect that session. Distinguish invalid credentials from temporary network failure.
- Use offline sync for durable queues, reconciliation and conflict resolution; use security auth guidance for the login protocol.
Pagination, transfers and real time
- Follow the server's cursor/offset contract. Reset pagination on account/filter change, prevent overlapping page loads and handle an exhausted cursor explicitly. Do not infer the next cursor from item count unless the API specifies it.
- Avoid buffering large files entirely in memory. Report progress from transferred bytes where available; cancellation and failure must release file/stream resources.
- Resume only if the server protocol supports it. Persist the upload identity securely, query acknowledged state after interruption, handle expiry, and validate completion before publishing the resulting object. Background continuation depends on native OS APIs, not a timer.
- Give a WebSocket one owner. Bound reconnection, refresh authentication appropriately, and specify missed-event recovery with the server (cursor/replay/snapshot). Reconnect alone does not recover events lost while suspended.
Verify and deliver
Test concurrent 401s, refresh failure, logout during refresh, late responses after account switch, timeout after server acceptance, malformed response, cancelled pagination, upload interruption and reconnect with missed events. Use a fake transport or local test server and virtual time for deterministic retries; test native background behavior separately.
Return the actual request/state contract, changed symbols, failure-to-UI mapping, tests run and unknown server guarantees. Reference background execution for scheduling and observability for sanitized diagnostics.
Official source: HTTP semantics, including idempotence and Retry-After.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

