Build a Simple Networking Library in Android (Part 1)
The idea of library internals has always been intimidating to me. Most people being an app developer prefer to assume the library as a black box. How do people code it, test it or release it? You are in for a treat as in my series of articles I will take you on a journey of creating, running and publishing an actual working library. Yes, we won’t be doing some “Hello World” stuff. We will create a real Android Library through which can make API requests and get the result. It will be 2 part series:
A little sneak peek to get you excited!We will try to accomplish a very Simple Networking Library. It will make real network calls from API and give a response in JSONObject. Our library will model a network request by taking a URL, Method, Header, Body and return response via an interface.
Creation of networking moduleTo begin with, we will create a new module that will contain all the library internals. Our module will comprise all the code necessary for making the network request, parsing the response, thread management and last but not least, returning response via an interface. Let’s head over to the starting point!
The Starting pointIn the current Android Studio, it’s straightforward to get started for library development. Just a few clicks, no manual editing in any file. Go to: File > New > New Module > Android Library. You will get something like this:
Create New Module has five options:
Caution: The project which will be using our library it’s API level ≥ Libray API level. So choose the version carefully. For simplicity, I have kept the API level as 21 (94% device support) Now hit Finish, the module is ready (after Gradle sync and indexing). Now we can talk about the architecture of the library module.
The ArchitectureThe libraries lack fixed structure defined as compared to app development. It depends on what you want to build and then have an architecture. We are building a Simple Networking library. It is supposed to make a network request, then parse the raw response and give a useful result back via an interface. For someone who is integrating our library should be able to configure fields like URL, HTTP Methods, Message Body, Request Headers. Here are the requirements for what we are building:
We will try to put Request, RequestTask & Response in a single class named Http. Now that we have decided the necessary things for architecture. Let’s code the above two, starting with Request Builder.
1. Request BuilderThis class will be responsible for creating the network Request. It will be a Builder class which will take the HTTP method in constructor. Supported methods will be GET, POST, DELETE, PUT. The other configurable parameters will be URL, Request Header and Request Body Other configurable parameters will be URL, Request Header and MessageBody:
The
2. Request Header: According to Mozilla, HTTP headers let the client and the server pass additional information with an HTTP request or response. You can read more about headers here. By default, there are always some headers, but we can enable the functionality to add custom headers (if any). The builder for the header will look this:
The
3. Message Body: The message body part is optional for an HTTP message. It carries the entity-body associated with the request or response. You can read more about headers here. The builder for the body looks like this:
The
We have two more methods to support our Request class to make the connection request and send the response back. Before this, we need two more things, a ThreadExecutor (for creating a background thread) and JSONObjectListener (interface to give back the API response). ThreadExecutor: Creates and executes thread for the connection request on the background thread.
Why not coroutines in place of HandlerThread? We will have to integrate the coroutine library. Then our library will be bloated, which is not a good practice. JSONObjectListener: This interface will give a response or failure from the API.
The response will be
Now we can bring back our focus on two more remaining methods to support our
2. sendResponse(): An internal method to invoke the response interface.
The above also takes a
Now we are done with the
2. Request TaskThis class takes the above class i.e.
internal class RequestTask(private val req: Request) : Runnable {}
It is kept internal as we don’t want to expose it as it is not needed for someone who is integrating our library.
The run method creates a object of 2. request(): Creates an object of
Creates the obj by taking the
3. parseResponse(): Parses the response received from the network call. Basically, the network gives back the response in
The above method checks for the valid status code. We are considering
Response class: It converts the
The
3. Assembling Request, RequestTask and ResponseIf you remember the sneak peek into a code I had mentioned in a section above. I had some
We are done with the core part of our library module (simple-networking). But at this stage, this library can’t be used in any project. In order to get there, we need to publish our library. Check out part 2 to learn this.
Android News
Compose CameraX on Android
By Peng Jiang Android new UI toolkit Jetpack compose is in beta now, which has all the features you need to build production-ready apps. CameraX is another Jetpack support library, which let you control the camera easier. As compose is still under development, lots of the views are still not available the compose way.
By
ProAndroidDev -
droidcon News
Tech Showcases, Developer Resources & Partners
EmployerBrandingHeader
jobs.droidcon.com
![]() Latest Android Jobs
Kotlin Weekly
![]() Your weekly dose of Kotlin
ProAndroidDev
![]() Android Tech Blogs, Case Studies and Step-by-Step Coding
Zalando
![]() Meet one of Berlin's top employers
Academy for App Success
![]() Google Play resources tailored for the global droidcon community |
Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.