Chapter 4 - Systems, Networks, and Distributed Apps

4.1 Internet Protocols and App Communication

When you open an app like TikTok, Spotify, or Google Maps, you’re not just using your phone—you’re reaching out across the Internet. The app is constantly communicating with other computers, downloading updates, retrieving information, and sending your input to remote services. But how does this communication actually happen?

Apps don’t just “talk” like people do—they follow a set of strict rules called protocols. These rules make sure that devices can find each other, understand each other, and exchange information securely and efficiently.

In this section, you’ll learn how mobile apps use Internet protocols to communicate, how these systems are structured, and how you can design your own apps to send and receive data across the web.

What Is a Protocol?

In everyday life, a protocol is a standard way of doing something—like shaking hands or saying “hello.” In computing, a network protocol is a set of rules that two devices follow to exchange data successfully.

Think of your app like a person calling a friend. Before the conversation can begin:

You need to know their address.
You need a way to connect (like a phone or the Internet).
You need to agree on how to talk (language, volume, order).
You need to know how to end the conversation.

That’s exactly what Internet protocols do for your app.

How Apps Use the Internet

Let’s break it down step by step. When your app connects to a remote service, like a weather database or a news feed, it follows this general process:

Find the server
The app uses DNS (Domain Name System) to turn a web address like weatherapi.com into an IP address like 104.22.0.60.
Connect to the server
It uses IP (Internet Protocol) and TCP (Transmission Control Protocol) to send a request to that address.
Send a request
The app formats the request using HTTP or HTTPS, asking for specific data (like today’s forecast for New York).
Receive a response
The server sends back data—often in a format like JSON—and the app displays it on screen.
Close the connection
Once the app gets what it needs, it ends the conversation and waits until it’s needed again.

Key Protocols Every App Developer Should Know

Protocol	What It Does
IP (Internet Protocol)	Provides unique addresses to every device on a network.
TCP (Transmission Control Protocol)	Ensures data arrives completely and in the correct order.
DNS (Domain Name System)	Converts domain names (like `google.com`) into IP addresses.
HTTP/HTTPS	Handles requests and responses between apps and web servers.

HTTP stands for HyperText Transfer Protocol. It defines how your app sends a request (like “GET weather”) and how it expects to receive a response.

HTTPS is the secure version—it encrypts the communication so no one can spy on the data. This is the standard for all modern apps.

Example: A Weather App

Let’s say you’re building an app that shows today’s temperature.

Here’s how it might use Internet protocols:

The user opens the app and enters their city: “Atlanta.”
The app sends an HTTP GET request to https://api.weatherapi.com/current?city=Atlanta.
This request is packaged and sent using IP and TCP.
The server finds the data and sends back a JSON response.
Your app reads the JSON, extracts the temperature, and displays it.

All of this happens in less than a second, using the protocols above.

Why This Matters for App Developers

Understanding these protocols helps you:

Debug network issues (e.g., is the server down or did your app send the wrong request?)
Protect user data by choosing secure (HTTPS) connections
Work with APIs effectively, knowing how requests and responses are formatted
Design fault-tolerant systems (covered in the next section)

Even if you’re not a networking expert, knowing the basics helps you build more reliable, responsive, and connected apps.

Try It Yourself

Here’s a simple breakdown of what a raw HTTP request might look like from your app:

GET /current?city=Atlanta HTTP/1.1
Host: api.weatherapi.com
Accept: application/json

And here’s a possible response from the server (in JSON):

{
  "location": "Atlanta",
  "temperature": 72,
  "condition": "Sunny"
}

Your app reads that data and turns it into a screen that says:

“The current temperature in Atlanta is 72°F and sunny.”

Final Thoughts

Every modern mobile app depends on Internet communication to be useful. Whether it’s updating a feed, retrieving news, or checking your progress, your app is constantly exchanging information over a system of carefully structured protocols.

As you design your own apps, remember:

Every time you fetch or send data, you’re participating in this system.
Learning how these protocols work helps you avoid errors and build smarter features.
Your app doesn’t exist on its own—it’s part of a global, distributed network.

Next, you’ll learn how to make your app fault tolerant—so it works even when that network connection isn’t perfect.

4.2 Fault Tolerance in Mobile Apps

Imagine this: you’re using a homework app on the bus to upload your assignment. You hit “submit”—but the app crashes because you lost internet connection for a moment. Your work is gone. You’re frustrated. You delete the app.

This is why fault tolerance is one of the most important features in mobile app design. A fault-tolerant app is one that can anticipate problems and recover gracefully instead of crashing, freezing, or losing data.

In the real world, apps operate under imperfect conditions: slow Wi-Fi, limited data, low battery, server errors, and even hardware issues. Your job as a developer is to design your app to expect those problems—and to still give the user a smooth experience.

What Is Fault Tolerance?

Fault tolerance means your app is built to:

Detect when something goes wrong
Respond in a user-friendly way
Recover if possible, or wait and try again

It’s not about preventing every problem—it’s about handling them when they happen. Good fault tolerance helps your app stay:

Stable – It doesn’t crash.
Informative – It tells the user what’s wrong.
Recoverable – It gives users a way to fix or retry.

Apps with fault tolerance are more trustworthy. Apps without it get uninstalled.

Common Faults in Mobile Apps

Here are some typical problems your app might run into—and how you can prepare for them:

Problem	Example	Good App Behavior
No Internet connection	The user goes offline while making a request	Show a message: “No connection. Try again later.”
Server error (500 error)	The backend service is down	Display a default screen or cached content
Slow network or timeout	The request takes too long	Show a loading spinner and retry automatically
Bad input from the user	User submits an empty form	Show a validation message like “Name is required”
Device crash or low memory	Too much data is loaded at once	Only load what’s needed, save progress often

Building Fault Tolerance into Your App

Let’s walk through a few basic strategies for making your app more fault-tolerant in Android Studio.

1. Use Try/Catch Blocks

When your app makes a network request or processes data, you can wrap the code in a try/catch block to catch errors instead of crashing.

try {
    val response = makeNetworkCall()
    displayResult(response)
} catch (e: Exception) {
    errorText.text = "Oops! Something went wrong. Try again."
}

This way, if the network fails or something unexpected happens, the app doesn’t stop working—it just handles the issue and lets the user continue.

2. Show Meaningful Error Messages

If something goes wrong, don’t leave the user wondering. A blank screen or a frozen app is confusing. Instead, show a message that explains what happened and what they can do.

Example:

errorText.text = "We couldn't reach the server. Check your internet connection."

This is much better than the app crashing or displaying a generic “Error” popup.

3. Retry Failed Requests

Sometimes, a small network glitch is temporary. If the app can retry automatically, users might not even notice there was a problem.

Example strategy:

Try a request up to three times before giving up
Wait a few seconds between tries
Show a loading indicator during retries

var attempts = 0
val maxRetries = 3

fun tryRequest() {
    attempts++
    makeNetworkCall(onSuccess = { data ->
        displayData(data)
    }, onFailure = {
        if (attempts < maxRetries) {
            Handler().postDelayed({ tryRequest() }, 3000)
        } else {
            errorText.text = "Could not load content. Please try again later."
        }
    })
}

4. Use Local Storage for Offline Use

One of the most powerful tools in mobile fault tolerance is caching—storing data locally so it can be shown even if the user loses connection.

For example:

Store the last loaded weather forecast or news story in SharedPreferences or a local database.
If the user goes offline, show the cached version with a message like:

“This data is from your last update. Connect to refresh.”

This gives users a backup plan and builds trust.

5. Add Visual Feedback: Loaders and Placeholders

When your app is loading data from the Internet, don’t just leave the screen blank. Show a spinner, a “Loading…” message, or a placeholder image. This tells users the app is working.

You can also design graceful fallback screens:

“No data available”
“Something went wrong”
“Tap to retry”

These signals help users know what’s going on and what to do next.

Designing for Real Life

Here’s a helpful way to think about fault tolerance:

If the user’s Internet goes out, will they be confused, frustrated, or helped?

Your goal is to always provide:

Clarity – Show what went wrong
Control – Let the user try again or cancel
Continuity – Save progress or offer offline features when possible

Even big apps like YouTube, Gmail, and Instagram rely heavily on fault tolerance to protect the user experience. Your app should do the same, even in its early stages.

Conclusion

You can’t control the Internet. You can’t control whether the server crashes or someone closes your app halfway through. But you can control how your app responds to those things.

Fault-tolerant apps:

Are more stable and professional
Prevent data loss and crashes
Keep users happy—even when things go wrong

As you continue building apps, keep asking:

What could go wrong here?
How would the user feel if it did?
How can I help them recover and keep going?

These questions will make you not just a better coder—but a better designer and problem-solver.

4.3 Parallel Processing and Distributed Computing

Most apps you use every day do more than just run on your phone. They connect to cloud services, run background processes, and share work across multiple devices and servers. From voice assistants to video editors and multiplayer games, today’s apps rely on distributed computing to get things done fast, reliably, and at scale.

In this section, you’ll learn how apps split up work between devices (like your phone), remote servers (like cloud platforms), and even other users. You’ll also explore parallel processing, which helps apps run multiple tasks at once—making them faster and smarter.

What Is Distributed Computing?

Distributed computing means breaking a task into smaller parts and running those parts on different computers—sometimes all at once. These computers may be:

On your device (your phone, tablet, or watch)
On a server in the cloud (like Google Cloud or AWS)
On another user’s device (in peer-to-peer systems)

The goal is to share the workload so things run faster and more efficiently.

You’ve seen distributed computing in action when:

You use Google Docs and edits sync instantly across devices
You play a multiplayer game and see other players’ actions in real time
Your phone backs up your photos to Google Photos

Apps like these are powered by a network of connected systems working together behind the scenes.

Client-Server Model: The Foundation

Most distributed apps follow a model called client-server architecture.

Component	Role
Client	The app or device the user interacts with (your phone)
Server	A powerful remote computer that processes data, stores files, or runs algorithms

In this model, your app (the client) sends requests to a server and receives data in return.

Example:

Your weather app asks: “What’s the forecast for today?”
The server processes the request and responds with the temperature.
The app displays the result.

This model keeps your app lightweight—it doesn’t need to store or process everything itself. Instead, it “borrows brainpower” from the cloud.

Why Use Distributed Computing?

Apps use distributed systems because:

Phones have limits (battery, memory, storage)
Servers are powerful and can handle big tasks
Tasks can be split up and done faster in parallel
User data needs to be shared or synced across devices

Let’s say your app analyzes a large image for facial recognition. Instead of doing it all on the phone (which would be slow), the app can:

Send the image to a cloud server
Let the server process the image using advanced AI
Receive and display the result in seconds

This method gives users the power of high-performance computing—without draining their battery or crashing the app.

What Is Parallel Processing?

Sometimes, a single task is too big or time-consuming to run all at once. That’s where parallel processing comes in. Instead of doing one thing at a time (sequential processing), the app runs multiple tasks at the same time.

Parallel processing happens in:

Video editors rendering frames
Apps scanning multiple files for viruses
Simulations running hundreds of scenarios at once
Games tracking movement, sound, and physics together

Even your phone’s multi-core processor allows it to handle tasks in parallel—like playing music while you browse the web.

Parallelism in Mobile Development

Here’s a simple example in Kotlin using a coroutine (a way to run tasks in parallel):

GlobalScope.launch {
    val data1 = async { loadUserData() }
    val data2 = async { loadSettings() }
    val data3 = async { loadMessages() }

    // Wait for all tasks to finish
    val user = data1.await()
    val settings = data2.await()
    val messages = data3.await()

    // Now update the UI
    updateScreen(user, settings, messages)
}

Each task loads different data at the same time. When they’re all done, the screen updates. This makes apps feel faster and more responsive.

Examples of Distributed Apps

App Type	Distributed Task
Music Streaming App	Music files stream from servers, not stored on your phone
Language Translator	Voice input is sent to the cloud for real-time processing
Multiplayer Game	Player actions are shared across servers and other devices
Social Media App	Posts and comments are synced and stored across regions
Fitness Tracker	Data is collected locally and uploaded to a server

These apps rely on cloud services, APIs, and background processing to deliver seamless performance—even when millions of users are active at once.

Designing for Distributed and Parallel Workflows

When designing your own app, ask:

Does this feature require fast processing?
Can I split the task into smaller pieces?
Could part of this work be done on a server or in the background?
What happens if the server is slow or unavailable?

These questions help you build apps that are:

More efficient
More scalable
More responsive to user input

Challenges and Fault Tolerance

Of course, distributed systems aren’t perfect. Things can go wrong:

A server might go offline
Internet connection could drop
One part of the task might fail

That’s why distributed apps also need fault tolerance, which you learned about in the previous section. You can add:

Backups and retries
Timeouts and loading states
User messages to explain delays or errors

Designing with both distributed computing and fault tolerance in mind helps you build real-world apps that users can rely on.

Final Thoughts

As you move beyond basic apps, you’ll find that real mobile development means thinking bigger than the phone. It means understanding how your app can:

Work with the cloud
Share data across devices and users
Divide tasks into pieces and run them in parallel

You don’t need to build massive systems from scratch—but knowing how they work gives you the power to connect your app to limitless resources.

In the next section, you’ll learn how to use RESTful APIs to bring real-time, distributed functionality into your apps—like getting live news, translating text, or sending messages to the cloud.

4.4 RESTful APIs in Mobile Development

By now, you know that your app can do a lot on its own. It can store user data, display screens, and even respond to user input with logic and loops. But if you want your app to be truly connected—pulling real-world data, interacting with cloud services, or even syncing between users—you need to learn how to use an API.

In mobile development, one of the most common ways apps connect to outside systems is through a RESTful API. These APIs are what power features like:

Showing live weather
Translating text
Looking up current news headlines
Logging in with Google or Facebook
Sending and receiving messages in real time

This section will teach you how RESTful APIs work, how to use them in your own mobile projects, and how to handle the responses they return.

What Is an API?

An API (Application Programming Interface) is like a menu at a restaurant. It tells your app:

What kinds of requests it can make (like ordering a forecast or posting a comment)
How to ask for it (in what format and structure)
What to expect in return (like a data response in JSON)

In mobile development, APIs let your app talk to other programs, databases, or servers over the Internet. And the most common kind of API used in mobile apps is called a RESTful API.

What Does REST Mean?

REST stands for Representational State Transfer. It’s a set of rules for how APIs should work over the Internet using HTTP—the same system your web browser uses.

When your app uses a RESTful API, it sends HTTP requests (like “GET” or “POST”) and receives JSON data in return.

Here’s a breakdown of the most common REST methods:

HTTP Method	Purpose	App Example
`GET`	Retrieve data from the server	Get a list of jokes, user data, or weather
`POST`	Send new data to the server	Save a new journal entry or message
`PUT`	Update existing data	Change a user’s settings
`DELETE`	Remove data from the server	Delete a task from a to-do list

JSON: The Language of API Responses

Most RESTful APIs return data in a format called JSON (JavaScript Object Notation). JSON is like a digital version of a spreadsheet—it’s structured, readable, and perfect for apps to process.

Here’s an example of JSON your app might receive:

{
  "location": "New York",
  "temperature": 71,
  "condition": "Cloudy"
}

Your app can then read this data and display:

“The temperature in New York is 71°F and cloudy.”

In Kotlin, you can parse this JSON using libraries like Gson, Moshi, or Ktor.

How Your App Uses a RESTful API

Here’s the basic process:

The user triggers a request
(e.g., taps “Get Weather”)
Your app sends an HTTP request to the API
(e.g., GET https://api.weatherapi.com/current?city=Mobile)
The server responds with JSON data
Your app reads the data and updates the screen

Simple Example in Kotlin Using Fuel

Let’s say you want to connect to a public joke API:

Fuel.get("https://official-joke-api.appspot.com/random_joke")
    .response { _, _, result ->
        val json = result.get().toString()
        // Use a JSON parser to extract the joke
        println(json)
    }

You would then parse the JSON to pull out the setup and punchline, and display it in a TextView.

APIs You Can Use in Student Projects

API Name	What It Does	Example Use in an App
OpenWeatherMap	Provides current weather data	Display today’s forecast on the home screen
ZenQuotes API	Sends motivational quotes	Show a daily quote in a journal app
SpaceX Launch API	Lists recent and upcoming space launches	Build a space news tracker
REST Countries API	Shows country data	Create a geography quiz
Fun Translations API	Translates text into pirate or Yoda speak	Add a fun feature to a messaging app

Most public APIs require no login, but some may need an API key—a special code that tells the server who you are.

Tips for Using RESTful APIs

Always check the API documentation to see what URL to use and what kind of data it returns.
Test your requests in Postman or the browser before using them in your code.
Handle errors using try/catch so your app doesn’t crash if the API is down.
Don’t hard-code sensitive data like API keys into your app. Use secure methods.

What Makes RESTful APIs Powerful?

With RESTful APIs, your app becomes a live, connected system. You can:

Pull in data from around the world
Add new features quickly without writing everything yourself
Keep your app lightweight while relying on external services

You’re no longer working alone—your app is now part of a global network of services, content, and computation.

Final Thoughts

Using RESTful APIs is one of the most important steps toward building real-world apps. Whether you’re building a travel app, a quiz, a productivity tool, or a game, APIs help you:

Deliver live content
Connect to cloud services
Scale your app without overloading your device

In the next chapter, you’ll explore how to secure data, protect user privacy, and build trust as your app starts handling more information and working across systems.

Discussion Prompt

“Think about an app you use that depends on the Internet—like Google Maps, Spotify, Instagram, or your school’s grade portal. What happens if the Internet goes out? How should that app behave to avoid frustrating users?”

Now discuss:

What parts of the app rely on communication with a server?
How do you think it uses RESTful APIs or cloud services?
What would good fault tolerance look like in that app?
If you were designing a similar app, what would you store locally, and what would you fetch remotely?

Follow-up:
Design a “Plan B” screen for one feature in that app—what would you show the user if the network wasn’t available?

Key Vocabulary

Term	Definition
Client	A device or app that sends requests to a server to access data or services.
Server	A powerful computer that processes requests and sends data back to clients.
Internet Protocol (IP)	A set of rules for addressing and sending data between devices on the Internet.
HTTP/HTTPS	Protocols used to send and receive data over the web; HTTPS is the secure version.
DNS (Domain Name System)	Translates website names (like google.com) into IP addresses that computers understand.
Fault Tolerance	The ability of an app to keep working, or recover gracefully, when something goes wrong.
Distributed Computing	When tasks are shared across multiple computers or devices to increase efficiency.
Parallel Processing	Running multiple parts of a task at the same time to improve speed and performance.
API (Application Programming Interface)	A set of rules that lets apps communicate with other apps or services.
RESTful API	A style of API that uses HTTP methods (like GET and POST) to connect apps to web services.
JSON (JavaScript Object Notation)	A common format for sending structured data between apps and servers.
GET Request	A type of HTTP request used to ask a server for information (like getting the weather).
POST Request	A type of HTTP request used to send data to a server (like submitting a form or saving info).
Cloud Computing	Using remote servers on the Internet to store and process data instead of relying only on a local device.