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.

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. It’s quite common for apps to display a generic dialog after a while prompting the user to rate the app, but we thought we could make this experience better.

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. This allows you to be notified immediately if and when you commit code that doesn’t compile or fails tests. Especially when working in teams, this can offer increased reliability and peace of mind.

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.

Two months ago, after an unfortunate incident with my Nexus 5 and tile floor, I decided to hop off the Nexus train and get a Moto X. After years of using nothing but Nexus devices (starting with the Nexus S) this was a big switch that made me a little nervous.

{% img /images/posts/moto-x-review/front-right-on.jpg “Moto X” %}

Since I buy all of my phones off contract, it wasn’t until Motorola offered a Today Show special that I was ready to drop the money. As soon as I could get the phone for the price of a Nexus 5, I was sold.

We’ve talked about basic tools, and about source control, so now we’re ready to get into actually creating an Android app.

In this part of the series, we’re going to create a new project using Android Studio. Android Studio is Google’s Integrated Development Environment (IDE) that we will use to create our Android app. While it’s still in early preview release status, it will be replacing Eclipse as the main Android development IDE, so we’ll go ahead and just start there.

What is SCM?

SCM, or source code management, is a system that helps developers manage the source code for their projects. They have been around forever, things like CVS, Subversion (SVN) and now Git are the popular ones.

SCMs allow you to version your source code, which is why they are also called Version Control Systems. Versioning your code helps you easily keep track of changes that have been made so that you can go back to previous versions in case anything happens.