Google Cloud Build is a Continuous Integration environment from Google Cloud that’s very flexible, and very affordable. In this post we look at how it can be used for Android projects.
A couple of weeks ago I bought a Google Pixelbook. I’ve been doing a bit of Android Development on it, mostly to optimize Pigment for Chromebooks. It’s taken some experimentation and discovery to find out how to get things set up, largely because the Android documentation is slightly out of date, so I thought I would share my experience, hopefully saving others time. This post serves as a step by step guide to getting up and running with Android Studio on a Pixelbook (and, hopefully, other Chromebooks as well).
A few months ago I was tasked with rewriting the subscription code for Pigment, the coloring book app I work on at Pixite. Our users were suffering from a bug causing paying users to sometimes lose access to premium content, and the original implementation was somewhat hastily written, so I decided it made sense to invest the time to rewrite the billing code from scratch. Play Billing Library Google makes interacting with the Play Store’s in app billing infrastructure pretty easy with the Play Billing Library.
For a long time I’ve been in search of a good continuous integration server for Android. I’ve even written about one that I used years ago, which is no longer suited to Android development, in my opinion. As the Android community has grown, so has the wealth of tools available. In that time I’ve also moved from simply wanting continuous integration, to wanting continuous delivery. Continuous Delivery you say? Continuous delivery builds on continuous integration, but instead of just testing your source code when you commit, it is also published to the appropriate channels.
This is the third article in a series on AutoValue. The first articleintroduced AutoValue, the code generating annotation processor for value types. The secondtook a more in depth look at the code generated by AutoValue, and the benefits of compile time code generation. In a previous article introducing AutoValue, I briefly mentioned AutoValue Extensions. Now it’s time to go a bit more in depth to look at what extensions are, how they work, and how they can help you get even more out of AutoValue.
In my last article, I gave a basic introduction to AutoValue, the code generating annotation processor that makes immutable value types in Java easy. Now I’d like to take a bit of a deeper look at AutoValue and how it works. Compile Time Annotation Processing First things first, AutoValue is a compile time annotation processor. This means that it only runs when you compile your code, as opposed to when your app is running.
Value types in Java are hard. Well, not hard, but tedious. Google’s AutoValue library makes them much easier and has just received the long awaited update that adds the flexibility of extensions. Value Types in Java Before we can talk about how great AutoValue is, let’s look at the problem it solves: value types. A value type is simply an immutable objects whose equality is based on property values, as opposed to identity.
There may be a shortage of love on the internet for AsyncTasks, but that doesn’t mean they don’t have their uses. I’ve found myself using them a fair bit in the latest project that I’m working on. All in all, they make offloading tasks from the main thread quite simple, but can pose some challenges, particularly in tested environments. The biggest challenge with using AsyncTask in tested code is that, since the code runs asynchronously, it can be difficult to ensure your tests get the right result for verification.
I come from the consulting world, where it’s common to try to make everything a library. This makes perfect sense, boost profit margins by writing something once and selling it to everyone. But often times this doesn’t work out as expected for several reasons, the first of which is failing to ask the question “Should this be a library?” Here are a few tips to help you decide if you should makes something a library or not.
RxJava is all the rage in the Android world lately, and with good reason. While Functional Reactive Programming has a bit of a steep learning curve, the benefits are enormous. One issue I’ve run accross is the fact that I need to use libraries that don’t support RxJava, but use the Listener pattern instead, and therefore miss out on many of the composability benefits of Rx. I ran into this exact issue while integrating OpenIAB into the latest release of Fragment.