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.

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.

One of the most important factors in determining whether or not people will buy your app is the rating. Especially if your app isn’t free, people will generally check the ratings and reviews before downloading your app. And if your app is a paid app, ratings and reviews can mean success or failure for your app. When launching Fragment for Android, our first though was making a kick ass app, but then we needed to think about how to ensure that users remembered to go back to the Play Store to share their experience by rating the app.

Last week I released Fragment for Android. Fragment is made up of all sorts of custom Views, which I think sets it apart from many apps in the Play Store. Some of these views have a similar pattern to views I’ve had to create for other apps, in which a scroll view has padding such that every item within it can be scrolled to the center of the view. On it’s surface this doesn’t seem complex, but when you consider the massive difference in screen sizes available on Android, things get a little more complicated.

In November 2013, Ben Guerrette from Pixite reached out to me after reading my post about my experience being featured on the Google Play. He was interested in bringing one of their iOS photo apps to Android. At this point I wasn’t familiar with Pixite, so I promptly fired up the Google to do my research. I was quite impressed with what I found. The guys at Pixite had created some really cool photo apps for iOS, and when I searched Google Play for similar offerings on Android, I found next to nothing.

As a freelance Android developer, I’ve gotten the opportunity to work with many different client environments when it comes to building and releasing Android (and other) apps. One of the things that I’ve learned over the years is the importance of a good build server. Why CI? Continuous Integration servers, or CI servers, are designed to checkout your code after each push and build your project, including any tests you might have.

On a recent client app, I ran into a situation where I needed an arbitrary number of EditText fields based on a selected value, where the user could enter people’s information. My initial thought was to put this logic in my Fragment, just adding EditTexts to a LinearLayout container as the selected value changes, but that bloated my Fragment, and didn’t allow for much reuse. This was a perfect opportunity to encapsulate this interaction functionality in a custom view, which would be reusable throughout the app (required in two places so far), and would allow me to easily test the encapsulated functionality.

In the last post we created a basic Android project using Android Studio templates. While it’s great that we have a fully functioning master/detail style app, it does look a bit bare. In this post, we’ll change this by styling our list view, incorporating (sort of) real data to feed our list. We’ll make a custom adapter to drive our list with custom layouts, and introduce testing into the mix to ensure that our app continues to perform as expected.