Android’s Restrictions

To a large extent, accessing the Internet on Android is not significantly different than is accessing the Internet on other platforms. For example, Apache HttpClient, OkHttp, and Retrofit work with ordinary Java/Kotlin for use on desktops and servers, in addition to working on Android. Similarly, WebView is backed by the same Web rendering engine that powers Chrome, not only for Android, but for all Chrome-supported platforms.

However, Android does have some specific restrictions that will impact how you work with the Internet. None should be big problems for you, but they will require some extra care to handle.

The INTERNET Permission

To do anything with the Internet (or a local network) from your app, you need to hold the INTERNET permission. This includes cases where you use things like WebView — if your process needs network access, you need the INTERNET permission.

Hence, the manifest for our sample project contains the requisite <uses-permission> declaration:

<uses-permission android:name="android.permission.INTERNET"/>

Note, though, that you do not need to request this permission at runtime — just having the <uses-permission> element in the manifest is sufficient.

NetworkOnMainThreadException

If you attempt to perform network I/O on the main application thread, you will crash immediately with a NetworkOnMainThreadException. Network I/O can be slow — even if it is fast for you in the office, it may be slow for users due to differences in network connectivity. As such, doing network I/O on the main application thread is very likely to cause your UI to freeze for a bit while that I/O goes on.

Technically, there are ways to disable the code that enforces this exception (a class called StrictMode). In practice, the right answer is to do your network I/O on a background thread.

Many of the HTTP options presented above have built-in thread management options:

• WebView
• DownloadManager
• Volley
• OkHttp
• Retrofit
• Apollo-Android
• Glide
• Picasso

In some cases, everything is asynchronous (e.g., WebView, DownloadManager). In other cases, you have your choice between synchronous and asynchronous APIs (e.g., OkHttp, Retrofit) — you would use the synchronous APIs in cases where you are doing something else to put the work in the background, such as Kotlin coroutines.

Cleartext Restrictions

On Android 8.0+, if you attempt to use an http URL, you will crash, as “cleartext” traffic is not allowed by default.

The best answer is to use an https URL. In particular, if you are working with a server that you control, please secure it with an SSL/TLS certificate and use https.

If you are not in control over the schemes used in the URLs, though, you can update your network security configuration to support cleartext traffic from some or all domains. Consider warning your users, though, when you are about to use an http URL.

The Reality of Mobile Devices

Mobile devices have an interesting property: they are mobile. Users with mobile devices have this annoying habit of walking, jogging, running, driving, riding, dancing, kayaking, skydiving, and so on. When they do that, their network connection may change:

• They switch from their home or office WiFi to a mobile data connection
• They switch from one mobile tower to another tower while they are “on the road” (or in the sky, on the water, etc.)
• They return to their home or office and reconnect to the WiFi
• They get in an elevator, or go into an underground parking garage, or otherwise move from an area with connectivity options to an area without them

In all these cases, when the network connection changes, any outstanding socket connections get dropped. It does not matter whether you are working directly with Socket or are working with HTTP APIs. So, you might be in the middle of getting a Web service reply and, all of a sudden, your request gets abandoned, because you (briefly) lost communication with the server.

In casual apps, like this book’s samples, you largely ignore this issue. In production-grade apps, typically you handle this by having suitable retry policies. So, if you get an IOException, you retry the request up to N times before giving up. That way, for a transient problem like a connectivity change, you get the work done, just a bit more slowly. Yet, at the same time, you do not retry indefinitely, as if there are lots of successive failures, it may require user intervention to fix (e.g., the user turned on airplane mode).