Practical network for Android Developers (part 1)

Easy data layer for every Application

Here is the list of the blogs in this series:

• Part 1 — HTTP and Network Layer
• Part 2— TLS, Certificates, and Pinning
• Part 3— Authenticators and Interceptors
• Part 4 — Performance, Redundancy, and Concurrency
• Part 5 — Testing and Integration

Practical network for Android Developers

This is the first part of this serial “Practical Network for Android Developers” when we are gonna be talking about the Network data layer with a different vision that usually is addressed, cause networking on Android is difficult to work it, with multiples carriers, different and rich contents, streaming and all of this should arrive at our users without missing a single detail

HTTP and Network Layer

Http is a network protocol, if you are connecting to the internet you are using it, the pretty version of the definition is that Http is:

“An application layer protocol for distributed, collaborative, hypermedia information systems”

This means a bunch of things, basically, if you are building a website, smartphone app, IoT, even only a download of a file, you are using this protocol, it has grown from web pages with simple HTML to web applications to mobile apps, has evolved to become an API layer that is commonly used.

Http requests are generated by our users as the user interacts with our mobile app, we start requesting information from a server when the made some click, maybe a scroll or deletion, for example, imagine Gmail, every time you enter inside the app an Http request is made so the emails get refreshed, if you delete, answer or even open an email this will generate an Http request, these Http requests go to either an origin server or a proxy caching server, and that server will generate an Http response. Usually, any set of request/response has:

• Request — Make an HTTP request to an URL
• Response — The Request will return a response that can be an error or success.
• Data that can be parsed — In mobile we need to parse the response to an Object, Data Class or Struct that we can use inside the app, using some third parties like Moshi, Json, Gson*, you can even build your own, but when it reaches the phone, is a plain string.

Usually, any Http Request/Response has the next couple of things:

• Uniform Resource Locator: a URL is a specific location, an address somewhere on the internet with a specific type of method
• Headers: Gives the client and the server passes additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (:), then by its value.
• Body: The actual response, a simple string exposing the body content, can be nothing for some method, even a Unit for example.

For every request we get a response, no matter if is not successful, we have a status code to know it:

• 1xx — Everything is cool, just wait a little bit
• 2xx — Everything is fine, this is a response fully successive
• 3xx —The response is somewhere else, you are lost
• 4xx— The request by the client is poorly fulfilled, so this is an error from the mobile side
• 5xx — The server failed to fulfill a correct request, so this is an error from the backend side

HTTP Methods

There are multiple HTTP methods

• @GET: Is used for reading or retrieving information on a resource. GET requests are used only to read data and not change it, they are considered safe
• @POST: Is used for the creation of new resources. In particular, it’s used to create subordinate resources. Is neither safe nor idempotent. It is therefore recommended for non-idempotent resource requests. Making two identical POST requests will most likely result in two resources containing the same information.
• @PUT: Is used for update capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource. PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent. In other words, if you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call.
• @DELETE: Is used to delete a resource identified by a URL.
• @PATCH: Is used to modify capabilities. The PATCH request only needs to contain the changes to the resource, not the complete resource. PATCH is neither safe nor idempotent.

Whatsoever, any modification inside any of these methods for a mobile application can be significative dangerous, lets picture an application that receives a variable as a double in a response, if this somehow is changed to a Boolean, the parsing of the data will be broken, this is a huge pitfall that backend engineers have to take in consideration every time they are changing an endpoint that is being consulted at production.

HttpClient

Today, most Android applications are built upon APIs. An API generally is a RESTful web service (can be a lot of things, is this is just an example) that can be accessed over HTTP and exposes resources that allow the user to interact with the application, mostly we need a HttpClient to make access to the internet and start fetching data for our users.

Inside Android, we have an incredible library that creates a HttpClient in a couple of seconds, called OkHttpClient, this will create a Client, with a readTimeOut and ConnectionTimeOut, if the server does not deliver any answer in this time-lapse, we end up with a non-successful connection.
There’s a really important part of this client, we can also put a builder for Cache (and tons of other things that we will speak about later on in this serial)

Cache

Fetching resources over the network is both slow and expensive, the main reason is that we depend on multiple things in mobile, for example, on the network our user is in it, from 5G to 3G, from WIFI with Optical Fiber to communication cables

Cache is designed for making network calls better for everyone, even for the users, cause they will end without unnecessary network requests. Catching will never replace an original call to your DNS, per instance, the cache will never be a substitute for fetching data from its source.

Database Caching
Is not actually about the network layer, we ask our APIs about the information and we store this inside SharedPreferences, DataStore, or any Database that can be relational or nonrelational. The performance, both in speed and throughput that your database provides can be the most impactful factor of your application’s overall performance.

Content Delivery Network
When your server traffic is worldwide, it’s not always an easy and cost-wise method to replicate your entire infrastructure across the globe, and for that, we have CDN that gives you the ability to utilize its global network of edge locations to deliver a cached copy of your APIs content, including images, streaming and video

Domain Name System
Every domain request made on the internet essentially queries DNS cache servers in order to resolve the IP address associated with the domain name. DNS caching can occur on many levels including on the OS, via ISPs and DNS servers.

For the network specifically, we can make our HttpClient handle Cache (check the code above) and Non-Cache, for example in some applications we may have a pull to refresh it may be necessary to skip the cache and fetch data directly from the server. To force a full refresh, add the no-cache directly in your Cache builder for your OkHttpClient, the decision of doing this type of calls are specially product-wise more than technical wise pov.

This is all for this part of the post. For the next part, we will discuss Certificates, Pinning, and TSL!

If you need help:

I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

Happy Coding! 👩🏻‍💻