Flutter · One codebase, native feel
How do you structure networking and API error handling?
Short answer
Wrap HTTP calls in a client with timeouts, typed decoding and explicit error mapping. Add retries only for safe or idempotent requests, and keep tokens in secure storage rather than logs or source.
I keep transport concerns in one client and map responses into domain models. The UI should not know about status codes. Timeouts, cancellation, retry policy and auth refresh belong at that boundary, with logging that redacts tokens and personal data.
Future<List<Repo>> fetchRepos(http.Client client) async {
final uri = Uri.parse('https://api.example.com/repos');
final response = await client
.get(uri, headers: {'Accept': 'application/json'})
.timeout(const Duration(seconds: 10));
if (response.statusCode != 200) {
throw ApiException('HTTP ' + response.statusCode.toString());
}
final decoded = jsonDecode(response.body) as List<dynamic>;
return decoded
.map((item) => Repo.fromJson(item as Map<String, dynamic>))
.toList();
}- Set connect and receive timeouts; the default may be too long for mobile networks
- Retry with exponential backoff and jitter only for transient, idempotent failures
- Do not retry a payment or create call unless the server supports idempotency keys
- Cancel requests when the screen is disposed or superseded
- Never log authorization headers, tokens or full response bodies containing personal data
Auth refresh and errors
Handle token refresh in one interceptor or client wrapper, serialising concurrent refreshes so many requests do not trigger many refreshes. Map network, timeout, unauthorised, rate limited and server errors into distinct states. The UI needs to tell the user whether retrying is useful.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you prevent a thundering herd of token refreshes?
- 2Which HTTP methods are safe to retry automatically?
- 3How do you distinguish offline from a server error?
- 4What are the risks of certificate pinning?
Say it in the interview
I keep HTTP behind a client that owns timeouts, auth refresh, error mapping and redacted logging. Callers receive typed results or domain exceptions, not raw status codes. Retries use backoff and only apply to transient idempotent calls. I also cancel stale requests, show whether a failure is retryable, and only add certificate pinning with a rotation plan.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Flutter mock interview and get scored feedback on depth, clarity and confidence.