This blog has been inactive for a long time. I tried to at least post an article yearly, and next thing you know, two years and a half fly by… Halloween seemed like a good time to resurrect it. I wanted to start writing again recently, and faced an issue: this blog was using Octopress 2. Well, Octopress has apparently been dead for even longer than this blog. So I wanted to switch to another static generator.
Compat libraries are great. They allow us to work with the newest Android APIs, without thinking (much) about your minimum API level. Instead of thousands of devices, you can reach billions. With nearly no changes in your code. But sometimes, they’re not so great…
What is Android Things? Android Things is an alternative Android version, announced at Google I/O 2015, and released as a first developer preview in December 2016. Its purpose is to develop embedded IoT devices, with a known and widely documented Android ecosystem basis. It’s currently running on three different boards: the Intel Edison, the NXP Pico i.MX6UL, and the Raspberry Pi 3. Some higher-end boards are coming soon. On the SDK side, Android Things comes with a specific support library to ease low-level hardware usage. It consists in two parts: the Peripheral I/O API, which supports GPIO, PWM, I2C, SPI and UART, and the User Driver API, which allows a developer to write a hardware-specific, high-level driver, to ease hardware reusability by injecting events into the Android framework. Other applications can in turn use those events without having to interact with the hardware directly. There’s a downside: the bundled Android is not as complete as the one you can find on a phone. Most of the standard applications aren’t installed (Calendar, Phone…), and standard content providers are absent too (MediaProvider, Dictionary…). Android Things supports displays, with the default Android UI toolkit. However, the display is a bit different from what you’re used to seeing on an Android device: there’s no notification bar, navigation bar or anything, the running application will use the full display. That is, if it uses it at all: displays are purely optional.
With the Android M SDK (API 23), Google removed the Apache HTTP Client library. It was deprecated since API 22, and Google recommanded to use HttpURLConnection instead since API 9. While the classes are still bundled in Android 6 ROMs, it won’t be long until we see them completely go away. Some applications are still relying on this library, and need to be updated to use the SDK 23, without having time/budget/whatever required to switch from HTTP Client. While I strongly recommend you to still take time to move to something else (there are many high-level libraries, like OkHttp or Ion, or you can use HttpURLConnection to keep a low-level access), there is a way to use the Apache library while using the SDK 23.
When writing an application, you probably want it to run on most platforms possible. Having a game on Android is great, but what about this weird friend with his iPhone? It would be nice to be able to play with him. Of course there are cross-platforms technologies like Cordova or Titanium. But sadly, you can’t achieve both a perfect user experience and great performances with this kind of tools. And even if you could: what about reusing code on the back-end? We need to share some code.