Setting up a new development environment – Android
It’s been a long while since I was doing any personal coding projects and even longer since the last time I gave much thought to the development environment and tools that I would use. However, that time is upon me again, I’ve had an idea for an app I’d like to develop for android. Last time I developed anything it was for maemo, for the n900. Then it was a twitter client I called ‘witter’, and I developed it mainly as an educational thing, a modern day ‘hello world’. I figured it contained just the right mix of UI, and backend services integration to make for an interesting project. As it turned out, there really weren’t many twitter options on maemo at the time, and so I got quite a lot of interest from the community in what I was developing.
However after a while I grew tired of the n900 as a phone, whilst I loved the potential of the platform, it felt like nokia didn’t really care about it, and Android was very much the new hotness. So much more support, more apps, and generally less buggy. And so I handed over the reins to Witter development to some guys in the community that were interested in continuing to support it and I moved on. Having just had a quick look I was quite amazed to see that witter has has 318k downloads. Not bad for what started as little more than an coding exercise.
Back when I was developing witter I wrote about setting up a development environment for maemo, having just googled I found it’s still in the first page of results, so hopefully it has been helpful to others, and with any luck this will be to.
What’s taken me so long to get around to developing again? Well I’d say the issue is two-fold, firstly I got a new job about 16 months ago and it keeps me very busy. Secondly, there are already a bazillion apps for android. I just didn’t find the time to come up with any ideas that inspired me to get going. With little free time, it is easier to spend it on other things. (mostly wood work projects)
But now I have an idea, and so I started looking at what I wanted the development environment to be like. Android being Java means the IDE of choice is still eclipse, and this time I don’t have to try very hard to get things going (I recall getting the python tooling installed in eclipse was a pain). Google have made it super easy to just pickup the android developer tools update site, download and you’re ready to rock. But there is more to a dev environment than the IDE.
In the last year at work I’ve been using mercurial for source code and team city for continuous integration server. This is a ways on from my tool chain of maemo days, I don’t think I’d though much about using continuous integration for my personal projects. I was using SVN, but mostly that felt like a chore to make sure I had version control rather than an integrated part of the process.
In order to spread my experience a little, I decided to try out GIT for source and Jenkins for a CI. I did some research and found that Jenkins has an android plugin that allowed it to do clever things with obtaining the android libs for compilation etc. and GIT integrated with both Jenkins and eclipse via plugins.
The machines I have access to at home amount to my transformer prime (which is amazing but not really suited to this kind of task), my Asrock ION 330 which runs my media centre, a netbook. and an old imac g5(ppc). there is also a main computer which my wife uses for her work, so that wasn’t really in the picture as any time I have for coding she would be spending writing. When I developed witter, I mostly used my work laptop. However it was never and ideal situation, for various reasons I’d rather keep my own projects separated completely from work. Mainly if I’m on my work laptop I’m probably logged into work and therefore distracted by work.
So I decided that I would install Jenkins and a main git repository on my media centre pc (it’s on all the time anyway) and install eclipse and the android developer tools on the mac. I’d not used the mac at all for a few years, it’s spent at least the last year or so packed up in its box. So I got it out, cleaned the keyboard which was quite grimy, and fired it up. Within short order I found that this being an old PPC mac, there is no download for eclipse on ppc mac. and no android developer tools either. In fact this is now a decidedly dead end of technology with very little support for it. However, ubuntu do have a ppc build, and so I figured I had nothing to lose in wiping the old os X and sticking a recent ubuntu on.
In the meantime I installed jenkins, then I had to figure out how to switch its default port to something else (I already have a few web type things running on the machine so there was contention for jenkins default 8080 port). The instructions I could find appeared to point to the wrong place. in the end I wound up navigating into /etc and then:
find . -name “jenkins*”
Which showed me a config file : /etc/init/jenkins
In here were the various settings I was looking for including the port so I made the change and started it up. In general I found the instructions for jenkins to be pretty simple and the interface to be quite self explanatory. I installed the android and git plugins via its plugin manager. I also decided to install eclipse here along with GIT. I’m not going to be developing on my TV, but whilst the mac was undergoing longer term changes, I wanted to get a proof of concept up and running. I had a little confusion with the eclipse git plugin, since it seemed to expect each new project to be a new git repository. However you can make deal with lots of projects in a single git reop, as long as you effectively create a new project inside the git repo to start with, rather than in default workspace and then share. If the project exists inside a git repository then this is detected when you go to share the project and everything ties together nicely.
I decided I wanted a local repo, though much of the information on git assumes you’re going to use gitHUB to host your primary repo. I’m not sure what I’m going to do with the app yet, and I’m not comfortable making it public by default at this stage, and I’m not interested in paying for a private repo. Instead I initialized a git repo on top of my shared nas which is backed by 2 RAID-1 disks. So i figure with the primary supported on redundant discs and the nature of git being that I maintain local copies anywhere I chose to develop, it should be sufficiently protected.
So I have created a simple android project, and an android test project, which I have shared into a git repository. but how to get it to build? well it turns out google have even thought of this, I found some instructions that gave a command available in the ADT that inspects your eclipse project and creates an ant file to build it. Honestly this was shockingly easy.
Now that I had a git repo with some projects in, and a build.xml file that ant could use to compile it, I was able to configure jenkins with a build job that I configured to look at the git repo and poll every minute for changes. I added a prestep to aquire the android toolkit, and then an ant step pointing at my new build.xml. And that was it! I kicked a manual build and saw it picked everything up, compiled and created an apk file. I then made a couple of minor changes in my eclipse project and committed them, and watched as jenkins detected the changes and auto rebuilt the project.
So we’re in buinsess, but the iMac is not quite there yet, I got ubuntu installed, and installed eclipse, but a cursory check didn’t find the git plugin, and I fear it may not be available under the ppc version. In the meantime I used the wonder that is remote display export, and simple ssh -X to my asrock, and launch eclipse so that it displays on the iMac, it is perhaps not quite as fast as it might be running locally, but it does sidestep entirely the issues of the ppc versus x86 architectures.
Next I need to figure out how to get the apk file published somewhere that my tablet and my phone can pick it up to install.
Its interesting to see how easy most of this stuff is now. Also it probably says something about me, that having had an idea of what I want to develop, before I really do anything specific to that, what I wanted was source control and continuous integration in place. Next I will make sure that I have a test project running and able to run tests against the code. This is something I didn’t bother with when I wrote witter, and I really should have. The danger being that once I’d gotten a certain way without tests, it felt like it would be too much time spent not making progress on the app to go back and add them. Of course me being a software tester I really should know better, but I figured it was just a coding exercise, I was just learning, it wasn’t ‘real’ development, until it was, and I was in a mess.
So this time I’m learning from those mistakes. I want the process for writing tests, building and running tests, and deploying to my devices to be worked out and slick before I even start to think about implementation of the app.
I’m sure I’ll post again as I learn more about the challenges of developing for android.