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 have seen some solutions for getting around this dilemma, but they involve pretty significant changes to the structure of your app, and exposing some internal members, simply for the sake of the tests.

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. To make matters more difficult, OpenIAB uses startActivityForResult to actually launch a new Activity and return a result. That made me wonder, how can I use OpenIAB with RxJava?

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.

One of my favorite new devices from Google is the Chromecast. I have 3 throughout my house, and one for travel. It’s great to have a cheap device that anyone can stream to.

I’ve also had the pleasure of integrating Google Cast support on several apps in my freelancing business. These are usually pretty cut and dry, but I recently had a client who needed a custom Google Cast action item which was one of many colors, depending on where you are in the app.

One of the most powerful, yet sometimes overlooked, features of Android is the Intent system. Android’s Intents allow apps to interact with each other, without intimate knowledge of each other.

Intents are one of the differentiating factors that allows Android apps to interact and send data beyond their walls, while still keeping the system relatively safe.

Anatomy of an Intent

I like to think of Intents as the opposite of URLs. You remember URLs, right? That’s how you got to this page.

Modern Android apps often make use of gesture interaction to provide fluid, natural interaction with the app. There are a few ways to handle these interactions, and in this post I’m going to cover some of the basics for easily adding gesture support to your app.

The code for this sample app can be found at Github.

The basic building blocks of this simple gesture handling code is the GestureDetector, and the various OnGestureListeners. These classes allow you to easily detect and handle certain gestures, whithout having to worry about tracking touch events and determine the math to decide what type of gesture it is.