Table of Contents
Why Networking Matters in Android Apps
Many modern Android apps rely on data that does not live on the device. Messaging apps load new conversations from a server, weather apps request forecasts from an online service, and news apps fetch the latest articles from web APIs. All these tasks require networking.
Networking in Android is the process of connecting your app to remote services over the internet or a local network. In this chapter you will understand the essential concepts that appear again and again when you work with APIs and remote data. Later chapters will show concrete libraries and implementations, but here the focus is on the ideas that sit underneath those tools.
A strong grasp of networking fundamentals will help you design APIs, understand error cases, and debug problems when your app cannot reach a server or when responses are not what you expect.
Networking is about communication between your app and remote services. Every network call can fail, be slow, or return unexpected data. Always design your app to handle these cases gracefully.
Basic Concepts: Clients, Servers, and Requests
At the core of app networking is a conversation between two parties. Your Android app is almost always the client. The remote machine or service is the server. The client initiates the communication, and the server responds.
When your app needs data, it sends a request to a server. The server processes that request, then sends back a response. Both the request and the response follow rules defined by a protocol so that both sides can understand each other.
For you as an Android developer, this usually looks like sending a request to a web address, also called a URL, and receiving data such as JSON in return. That response might contain information you show to the user, or it might confirm that an operation such as a login or a data upload was successful.
Understanding that your app is a client helps you think about responsibilities. You control the way you send data to the server and how you treat the response. You do not control how the server is implemented, which is why careful error handling and a clear understanding of the protocol are essential.
URLs, Endpoints, and Resources
When talking to a server, your app does not connect in a vague way. It connects to specific addresses that identify the server and the resource you want.
A URL, which stands for Uniform Resource Locator, is a text representation of that address. It usually includes a protocol, a host, an optional port, a path, and optional query parameters. For example:
https://api.example.com/users?active=true
In this example, the protocol is https, the host is api.example.com, the path is /users, and the query part is ?active=true. The path identifies the resource group, in this case perhaps a list of users. The query narrows or filters what you want, for example only active users.
On the server side, a specific combination of path and sometimes query parameters is often called an endpoint. Each endpoint represents a particular operation such as listing users, creating a new user, or fetching details for a single user. You will call these endpoints from your Android app when you interact with an API.
Working with URLs requires care with details. Spelling mistakes, missing segments, or wrong query parameters can all lead to errors or incorrect data. For that reason it is common to define base URLs and construct paths systematically in your networking layer, instead of scattering raw strings across your app.
HTTP as the Foundation
Most Android apps use HTTP as their main network protocol. HTTP stands for Hypertext Transfer Protocol and defines how requests and responses are structured between clients and servers on the web.
When your app performs an HTTP request, it chooses an HTTP method, a URL, optional headers, and optional body data. The server processes that incoming data and responds with a status code, headers, and a body that may contain content such as JSON.
You usually do not build HTTP messages by hand. In Android you work with libraries that represent these concepts as objects and functions. Still, knowing what an HTTP method or status code means is essential to interpret what is going on and to configure these libraries correctly.
HTTP is stateless. That means each request is independent. The server does not automatically remember past requests from your app between calls. Any continuity, such as staying logged in, must be handled by passing data such as tokens or cookies with each request.
Every HTTP request is independent. If your app requires a notion of a "session", it must send identifying information such as a token in each relevant request.
HTTP Methods and Typical Uses
HTTP defines methods that describe the intent of the request. The most common methods you will encounter in Android apps are GET, POST, PUT, PATCH, and DELETE.
A GET request asks the server to send data without changing anything. For example, your app might use GET to retrieve a list of products or the profile of a user. The request body is usually empty, and any parameters are passed in the URL query.
A POST request asks the server to create something new or perform an action with data you provide. When a user registers in your app, the registration screen might send a POST that contains the username, email, and password in its body.
A PUT request usually replaces an entire resource with the data you provide. If your app allows a user to edit their full profile, it might send a PUT with all profile fields, not just changed ones.
A PATCH request is similar to PUT but is often used for partial updates. Instead of sending a complete profile, your app might send a PATCH for only the fields that changed, like an updated display name.
A DELETE request asks the server to remove something. For example, when a user removes an item from a favorites list, your app might send a DELETE to the corresponding endpoint.
Although these are conventions and servers can define their own behavior, it is good practice to follow expected meanings. This clarity makes API usage more predictable and easier to document.
HTTP Status Codes and Error Handling
When a server responds, it includes an HTTP status code. This is a three digit number that quickly tells you the general outcome of the request, before you even look at the body.
Codes in the 200 range indicate success. The common 200 OK means the request worked and the response body likely contains useful data. 201 Created is typically used after a POST that successfully created a resource.
Codes in the 300 range involve redirection. In simple Android apps that talk to stable APIs you might not encounter these often, since libraries usually handle redirects automatically.
Codes in the 400 range indicate client errors. 400 Bad Request suggests there is something wrong with the data your app sent. 401 Unauthorized often means your app did not provide valid authentication credentials. 403 Forbidden indicates the server understood the request but refuses to authorize it. 404 Not Found usually means the URL does not match a valid endpoint or resource.
Codes in the 500 range indicate server errors. For example, 500 Internal Server Error suggests that something went wrong on the server side. In such cases your app is usually not at fault, but you still need to respond gracefully.
In Android development you rarely present raw status codes to users. Instead, you interpret them and show friendly messages or take specific actions. For example, a 401 might trigger a logout and show a login screen again. A 500 might show an error message that invites the user to try again later.
Always check HTTP status codes and handle failures. Never assume that every network call succeeds or that responses always contain valid data.
HTTP Headers, Body, and Content Types
In addition to the status line, HTTP messages include headers. Headers are key value pairs that provide extra information about the request or response.
On the request side, headers can include authentication data such as Authorization, language preferences, or instructions about the type of content your app is sending. On the response side, headers can tell you how to interpret the body. For example, a Content-Type header of application/json means the response body contains JSON.
The body is the main content of the request or response. In a GET request, the body is often empty. In a POST, PUT, or PATCH, the body usually contains data your app wants to send to the server, for example a JSON object with user details. For responses, the body can hold text, JSON, HTML, binary data such as images, or be empty.
Correct handling of Content-Type is fundamental. If you send JSON, you typically set a request header such as Content-Type: application/json. This tells the server what to expect. Similarly, you read the response Content-Type to know how to parse the response body.
When working with Android libraries later, you will often configure headers automatically or through simple annotations. Knowing what they represent makes it easier to debug odd behavior, such as when a server refuses your request or responds with a different format than you expected.
JSON as a Data Format
Most modern APIs communicate using JSON, which stands for JavaScript Object Notation. JSON is a text based format that represents structured data using pairs of names and values, arrays, and simple primitives like strings and numbers.
JSON maps naturally to Kotlin data classes, which makes it very convenient in Android apps. A server might respond with JSON describing a user, for example containing fields like id, name, and email. Your app then parses that JSON into an object that you can work with in your code.
JSON is readable and lightweight, which helps during development and debugging. When something goes wrong, you can log the raw JSON string and inspect its structure. This is a big advantage compared to opaque binary formats.
Parsing JSON correctly requires you to align your model structure with the API. If the server changes a field name or data type, your app must update as well. You will see in later chapters how to use libraries that map JSON to Kotlin classes automatically, but you should always keep in mind that underneath those tools is a simple textual structure.
Treat JSON from the network as untrusted input. Validate the structure and handle missing or unexpected fields without crashing your app.
Network Constraints on Android
Networking in Android is not just about protocols. The device environment introduces specific challenges and rules that influence how you design network features.
Mobile networks are often unstable, slow, or temporary. A user might start a request on Wi Fi and then move into an area with no signal. This means every network call can fail for reasons outside your control. Timeouts, partial responses, and connection drops are normal events that you must handle.
Network usage also consumes battery and data. Repeated polling or large downloads in the background can quickly drain resources. As an Android developer you need to think about when to fetch data, how often to refresh, and how much information you really need to transfer.
Android also requires that your app does not perform long running or blocking network calls on the main thread, which is the thread that updates the UI. Blocking the main thread with network operations can freeze the interface. Later chapters will cover proper background execution with threads and coroutines, but this rule shapes every networking design decision.
Security is another constraint. By modern standards, apps should use https rather than http. With https, traffic is encrypted between your app and the server, which protects sensitive data such as passwords, tokens, or personal details from being intercepted. Android has policies and configuration options that encourage or enforce the use of secure connections.
Stateless APIs and Authentication
Because HTTP is stateless, keeping a user logged in or enforcing permissions requires extra data. When a user signs in, the server typically responds with some form of token. Your app stores this token securely and sends it in a header, often something like Authorization: Bearer <token>, with every protected request.
From the perspective of your app, this means many network calls look similar. You add the same authentication header repeatedly so that the server can decide if a request is allowed. If the token expires or becomes invalid, the server often responds with a status like 401 Unauthorized. Your app then needs to refresh the token or ask the user to log in again.
Because your app may be closed and reopened at any time, it must persist any authentication state it needs for future network calls. Later chapters on storage and security will show where and how to keep such data. For networking fundamentals it is enough to understand that stateless communication requires explicit identifiers on each call.
Caching and Freshness of Data
Not every request has to contact the server each time. Caching is the practice of storing copies of responses so you can reuse them instead of requesting the same data repeatedly.
Servers can guide caching through headers. For example, a server might include a header that marks the response as valid for a certain number of seconds. Within that time, your app or underlying HTTP client can use the cached version instead of hitting the network again. This improves speed and reduces data usage.
However, caching introduces a trade off between freshness and performance. If you rely too heavily on cached data, you might show outdated information. If you always bypass the cache, you might waste resources and increase loading times.
In Android, you will often rely on the HTTP client library to handle low level caching behavior. At a higher level, you decide when to trust cached values, when to force a refresh, and how to present that behavior to users. For critical operations, such as account balances or security related information, you might always require a fresh response.
Do not assume cached data is always up to date. For important information, design explicit refresh paths and clearly communicate loading states to users.
Latency, Timeouts, and User Experience
Every network call takes time. The delay between sending a request and receiving a response is known as latency. Latency is affected by physical distance, network quality, and server processing time.
Latency strongly influences how responsive your app feels. Long silent waits frustrate users. For a good experience, you should show clear loading indicators while a network request is in progress, disable or adjust related UI actions, and offer the ability to cancel or retry.
Timeouts are limits you set so that your app does not wait forever for a response. A connection timeout might specify how long to wait for a connection to be established. A read timeout might specify how long to wait for data after the connection is open. When a timeout is reached, the library throws an error that your app must catch and handle.
Choosing timeouts involves balancing patience and responsiveness. Very short timeouts might cause frequent failures on slow networks. Very long timeouts might make the app feel unresponsive. You may tune these values differently for different operations. For example, a lightweight data fetch might have a shorter timeout than a large file download.
Security Considerations in Networking
Whenever your app deals with user information over the network, security becomes central. Using https is a basic requirement. It encrypts data between device and server and helps prevent eavesdropping and tampering.
Certificates and certificate authorities verify that you are indeed talking to the real server and not an imposter. Android and HTTP libraries manage these cryptographic details for you by default. However, any time you change default security settings, such as allowing clear text http, you should do so only with a clear reason and full understanding of the risk.
Authentication data such as tokens or API keys should never be hard coded in the app in a simple way. If an attacker extracts your app package, they may find those keys. Instead, your server should perform most sensitive operations, and your app should store only what is truly necessary to identify the user. On the wire, you should treat every value as potentially visible to attackers unless you are using secure transport and careful practices.
Finally, be cautious with third party APIs. When your app sends data to any remote service, consider what is being shared and whether you trust that service to handle it properly. Privacy regulations and user expectations require transparent and careful handling of personal information.
How Networking Fits with Later Topics
Networking fundamentals provide the language and mental models you will use throughout the rest of this course when working with APIs and remote data. When you set up Retrofit later, you will be configuring HTTP methods, URLs, headers, and response types. When you handle errors, you will interpret status codes and exceptions that result from timeouts or connection failures.
The structure of JSON responses will influence the design of your Kotlin data classes and how you map network models to UI data. Concepts such as stateless communication, authentication, and caching will shape how you structure your app architecture, especially in combination with ViewModel, LiveData, and persistence layers.
As you move forward, keep revisiting these fundamental ideas. Libraries and frameworks change over time, but the core networking concepts of HTTP, requests and responses, and the realities of unreliable mobile networks remain constant.