If you checkout the Android Development community on Google+, you’ll find a lot of people asking how to get started building an app for Android. Though quite a general question that can’t really be answered in a social post, I understand how frustrating it can be to figure out where to get started.
There are plenty of tutorials on the web about how to accomplish specific tasks, but these generally don’t cover the higher level parts of app development like version control and layout analysis.
For years iOS developers have touted the merits of the Simulator, saying that it makes their lives easier. As someone who’s developer for both iOS and Android, and been primarily an Android developer for several years, I’ve never cared.
When I develop, I use a device. I’ve often made arguments about how it better to develop on a device because that is what users will run your app on. The Android Emulator is good in the sense that it’s not a Simulator, but actually emulates the Android hardware.
It’s been a few weeks since my last post, in large part because of all of the work I’ve been doing for Hashnote. For those who don’t know, in the beginning of August Hashnote was featured on Google Play in the Play Picks section. Here’s how it went.
In January of 2012, I decided to leave my 9 to 5 and start my own business as a freelance Android developer. I had landed a large client and started working on some cool projects. One of the benefits of this was that it gave me some more time to work on my own projects. I had recently sold my BGR app to Boy Genius Report, so I needed a new project.
I recently shared how I use Git to automatically track my versions. There’s quite a bit more to my git workflow than just tagging versions, though, so I’d like to dive into my git usage just a little more.
One of my clients introduced me to a very popular, and useful, git branching strategy commonly called Git-Flow based on Vincent Driessen’s branching model. I highly recommend reading his article, it’s quite good and describes a very useful branching model.
One of the challenges of programming projects is versioning. I’ve always tried to find a simple way to bump version and build number in a meaningful way that uniquely identifies a build.
Back in the Subversion days this was easy, since Subversion is a centralized version control system that assigns a unique, incrementing revision number to each commit. Free build numbers! Then all you have to do is assign a marketing version number (something like 1.0) for each release.
App ratings are an extremely factor in any app. No matter what app store you are on, people value the opinions of other users. Google has always said that high Play Store ratings are an important factor in getting your app featured.
I won’t pretend that I know a magic bullet to get endless 5 start reviews, but here are a few things I’ve learned along the way.
I get emails from my users. I invite that by putting a ‘Contact Us’ button on the about screen in Hashnote. Often times these are simple questions or requests, but I make a concerted effort to respond to every user email I get.
This morning, like many others, I decided to take a look at the Android version distribution of Hashnote and was pleasently surprized with what I found.
A few months ago I decided to take Hashnote ICS+ only after realizing that only a small portion of my install base was on pre-ICS devices. I still think that was a good choice as it’s made development much easier and allowed me to do more in the limited free time I have to work on Hashnote.
I’ve been using ant to build my Android projects for as long as I can remember. There are many reasons for this, like build consistency and workstation agnosticism, but you can read this article if you want to check that out.
Ant is a good tool, but never offered the flexibility that I would have liked in a project. That’s where Gradle steps in.
After seeing all of the power of the new Gradle build system, I knew I had to convert Hashnote to Gradle. Google has some great documentation for migrating if you already build with Eclipse, but that doesn’t work for me.
Back in April I had the pleasure of seeing a talk by Jay Ohms of TwentyFive Squares at GDG Schaumburg. It was a great discussion about their app, Press, an excellent RSS reader for Android.
The discussion wasn’t a technical one, but one of the things that interested me was their decision to go Ice Cream Sandwich and up for Press. This was the first app that I had heard of, and the only major, popular app that I know of, that has made this decision.
At Google I/O this year, Google introduced it’s new IDE, Android Studio. Android Studio is based on IntelliJ IDEA, a great IDE that many of my Android friends use.
I wasn’t particularly excited by this announcement because, for the last several years, I’ve given up IDEs. My development environment of choice has been Sublime Text 2 and ant.
Sure, IDEs can be extremely useful, especially in Java, where boiler plate code is the name of the game. But I found that they (Eclipse especially) were getting in the way more than they were helping. I was able to get reasonable reflection based code completion using the great SublimeJava plugin, and I found ant builds from the command line to be amazingly more reliable than anything I could do with Eclipse.