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.
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.
Let’s start by defining our end goal. The control we want to build allows the user to scroll a view such that any of the contents can be moved to the center of the screen. Here’s an animation demonstrating what I mean.
This control, boiled down, is really just a HorizontalScrollView. Notice how, when the user scrolls to the end, there is a nice overscroll indicator. When the user flings the control, it moves accordingly. The control nicely decelerates just like all other Android ScrollViews, making it feel natural to the user. These are all things you get for free by subclassing a build in Android widget.
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.
What I really liked about the Pixite apps was that they weren’t your standard sepia or vignette filters, but truly creative tools to help people make unique, creative art. After many emails, and several phone calls with the team, we decided to team to up bring a new type of creativity to the Play Store.
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.
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.