This is the third article in a series on AutoValue. The first article introduced AutoValue, the code generating annotation processor for value types. The second took 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.

Shortly after our initial release of the Pack Store in Fragment earlier this year, other companies started contacting us wanting Fragment on their App stores, as well. With the addition of the Pack Store, and in app purchases, this made things challenging. When I first implemented the Pack Store, I used Sergey Solovyev’s excellent Android Checkout library to implement the In App Billing support. This is a great library that eased a lot of the pain of the IAB implementation, but tightly coupled Fragment with the Google Play Store.

Remember the olden days of Android development? There were times when including a library in a project meant relative links to source, or using Maven. Fortunately for us, those days are long gone now with the introduction of Gradle. Gradle has made developing and consuming libraries for Android amazingly simple, and has spurred a new boom in library development for Android. We’ve always had a large, open, inclusive community to boast of, but over the past year or two it has only gotten better as the community has matured.

We’ve all seen posts about why you should use custom views when applicable and how it can help you properly encapsulate your application code. What we don’t see quite as much is how this type of thinking can be translated to other, non-View related, portions of our apps. In my app, Fragment, there are a few places where I make use of custom Drawables to encapsulate my logic just like you would for a custom View.

I’ve finally done it. In the latest client project I’m working on I’ve decided to take a test first approach. I’ve been wanting to experience Test Driven Development on Android for years, but have never felt comfortable enough to really commit. After reading through Kent Beck’s book and checking out Corey Latislaw’s latest book, I decided I was ready to make the leap. I’ll write some more later about my experience, reactions, and what I’ve learned, but today I wanted to share a slightly unexpected benefit.