What Happens When the Internet Breaks?

Handling Broken Network Requests in Android (The Right Way)

Most Android apps don’t fail because APIs are wrong.

They fail because real-world networks are unreliable.

Users switch networks, turn on airplane mode, move through tunnels, or use slow 2G connections. If your app freezes, crashes, or silently stops working in these situations, the problem is not the internet — it’s the networking design.

Let’s break down why apps freeze on broken requests and how senior Android engineers handle it properly.

The Real Problem: Broken Network Requests

A broken request is any network call that cannot complete normally due to:

• Internet disconnection

• Very slow or unstable network

• Server timeout

• DNS failure

• TLS / handshake issues

• App going to background mid-request

If your app assumes “request will always succeed”, it’s already broken.

Why Does the App Freeze?

1. Network Work on the Main Thread

The most common mistake.

If a network call runs on the Main/UI thread, the UI is blocked until the request finishes or times out.

Result:

• Screen becomes unresponsive

• ANR (Application Not Responding)

• App gets killed by the system

Rule:
Network operations must never touch the main thread.

2. Missing Timeouts

By default, a request can hang for a very long time.

If:

• No connection timeout

• No read timeout

• No write timeout

The app waits endlessly, appearing frozen to the user.

Timeouts exist to fail fast, not to slow things down.

3. No Failure Handling

Many apps only handle the “success” case.

When internet disconnects:

• Exception is thrown

• Response is null

• App crashes or shows nothing

If errors aren’t explicitly handled, the UI has no idea what to show.

4. UI Waiting for Network Response

This is a design flaw.

The UI is tightly coupled to the network response:

• No loading state

• No cached data

• No fallback

When the request breaks, the UI has nothing to render.

How Senior Engineers Handle Broken Requests

1. Always Use Background Threads

In modern Android:

• Use suspend functions

• Execute work on Dispatchers.IO

• Let the main thread only render UI

This keeps the app responsive even when the network is slow or broken.

2. Set Proper Timeouts

Every request must have:

• Connection timeout – how long to wait to connect

• Read timeout – how long to wait for response

• Write timeout – how long to send request body

Timeouts ensure:

• Requests fail predictably

• UI does not hang

• Errors can be handled cleanly

3. Treat Errors as First-Class Citizens

Network failure is not an edge case — it’s normal.

Handle:

• No internet

• Timeout

• 4xx / 5xx responses

• Serialization issues

Convert low-level exceptions into domain-level errors that the UI understands.

4. Use Explicit Result Wrapping

Instead of returning raw data, return a result state:

• Loading

• Success

• Error

This allows the UI to:

• Show loaders

• Display cached data

• Show retry options

• Avoid crashes

5. Never Block UI Waiting for Network

The UI should react to state, not wait for data.

Good apps:

• Show loading immediately

• Render cached data if available

• Update UI when fresh data arrives

• Show error messages when needed

Bad apps:

• Freeze screen

• Show blank UI

• Crash on failure

6. Implement Retry — But Carefully

Retries help only for temporary failures.

Use:

• Limited retries

• Exponential backoff

• Only for idempotent requests (safe to retry)

Never retry blindly — that creates request storms and drains battery.

7. Cache and Offline Support

Production apps assume internet will break.

Use:

• HTTP caching

• Local database (Room)

• Offline-first strategy

The app should still work when the internet doesn’t.

Why This Matters in Interviews and Real Apps

Senior Android engineers are expected to answer questions like:

• What happens if the network drops mid-request?

• Why does the UI freeze?

• How do you design offline-first networking?

• How do you prevent ANRs?

• How do you map network errors to UI states?

If your answer is just:

“We call APIs using Retrofit”

That’s junior-level understanding.

Final Thought

Broken requests are not bugs.

They are reality.

A strong Android app:

• Never freezes

• Never crashes on bad internet

• Always communicates state to the user

• Recovers gracefully

That’s not magic.
That’s networking fundamentals done right.

This is exactly what we teach in Job-Ready Android Program

Not “how to call APIs”
But:

• Why apps freeze

• Why prod crashes happen

• How to design resilient networking layers

• How to explain this clearly in interviews

If you want a real networking + system design mindset, Join now