Where do you work and what do you do?
I currently work for a financial services firm named Axioma. The company is basically a bunch of very smart financial wizards who work out the secret sauce to optimizing portfolios and managing risk, and a small team of software engineers that help package the math into products. I work on a little bit of everything, with a focus on the Java middle tier. I deal with data and integration and developing APIs. My background is mostly middle tier and server side, with a good amount of web development, and some mobile, thrown in to boot.
How did you get started with computers?
The first time I really messed with computers I was in my early teens and it was, of course, to play video games. Our family had a Bally Astrocade home game machine in the early 80s. This was mega cool machine at the time. It had cassette cartridges for games, and a couple of controllers. The first program I ever wrote was when I was 13 or so, it was a text based football game written in BASIC on the Bally. I read the BASIC manual, and a few computer magazines, and taught myself how to program it. Later we had an Apple IIe, then every imaginable flavor of IBM clone that I used to dial in to all my favorite BBSes. The rest, as they say, is history.
You co-authored “GWT in Practice” and “Unlocking Android: A Developer’s Guide”. What is your next book project?
Before I answer this one, I have to say thanks to you for writing Ant: the Definitive Guide some years back. That book was on my desk for a long time, both because I was knee deep in Ant stuff and it was very helpful, and because I’m an amateur herpetologist and I used to collect all the books with herps on the covers. The horned lizard book was a favorite. I never put it together that it was *that* Eric Burke until just recently, after I had started reading your blog.
As to my next book project, it’s all about the Android. I’m currently working on “Android in Practice” for Manning publications. I’m very excited about it, because it’s the in Practice series and that allows us to dig a little deeper than many introductory texts, and we think that will distinguish it. Also, I have some great co-authors who are knee deep in Android every day: Michael Galpin of eBay, and Matthias Kaeppler of Qype. That’s where the real “in practice” experience comes in, these guys really know their stuff.
You have a full time job, a family, and you write books. How do you find time to fit it all in?
I get asked that quite a bit, and truth be told it just seems to be being able to turn off the TV and focus a bit later in the evening, and once in a while on weekends too. I’m sure it also helps to have an employment situation that allows me to get home at a decent hour, most of the time, and an understanding family. I’ve also been involved with side companies, and various open source projects for many years. Those are pretty good practice for managing several “jobs” at once.
Why are you interested in Android?
I’ll readily admit that I am an Android fanboy. The reason for it is mainly that I have always been an ardent open source advocate, and I think the OHA and Google have the right philosophy. Android isn’t perfect by any means, but it’s a long race, and I think an open platform that anybody can poke around in, and or contribute to, that is managed by a group of successful engineering focused companies is hard to beat. Allowing me access to the source, letting me do what I want with a device I own, and making it easy for me to contribute, are all big advantages from my perspective.
What do you find most difficult about Android development, and do you have any ideas how Google could make things easier?
In total I would say that I find Android development quite enjoyable, and I think the APIs are quite good. One problem I have found to be true about Android development is that it’s easy to get started and up and running, and it’s also easy to get yourself into trouble. I would say the one most difficult thing to get right is properly managing Activity state and understanding the life cycle. There are also some API areas I would like to see improved: the life cycle management nuances for one (especially when dealing with AsyncTasks and threads), the ContentProvider APIs which I find a bit cumbersome, the APIs for dealing with background services and wake locks which I think could be simplified, easier support for dealing with hardware devices like the camera, and more first class citizen testing support (which has gotten better). And, while I am on the subject of stuff that could be improved, though it’s not directly development related, the Android market has a host of issues that affect developers and could really use some attention.
In terms of programming APIs and development tools, what are Android’s best features?
Three things sprang to mind as I read this question. First, Java. Second, the Activity/Intent design. And, third the tooling overall. I know it makes me an oddball to say Java is a good feature these days (and I mean Java “the language” too), but I think it was a smart move. Java brings in a lot of good developers, and a heap of existing code, tooling, and knowledge. I think it’s an overlooked part of the reason for the success of the platform thus far. Don’t get me wrong, I’m also happy to see the NDK maturing, and more support for alternative languages as well. Also on the Java side, Dalvik, with multiple efficient VMs instances, and now the JIT, is very impressive.
Getting to Activities and Intents, I think the Activity/Intent approach, which to me is a bit like SOA on a handheld device (yes, I went there), is fantastic. The fact that I can link to other Activities, outside of my application, and easily pull together many different features as seamless “tasks” for the user is great. Overall I think this is a big plus for Android, and something that sets it apart from other mobile architectures I have worked with. As to the tooling, I think it’s good too. The Eclipse support is great to have. It’s not perfect, but it’s gotten better and having it at all makes many Android development tasks a lot easier.
Beyond Eclipse though, the ADB is packed with features, and the other tools like android, ddms, layoutopt, traceview, hierarchyviewer, and more are invaluable. Not every platform/API comes with this kind of stuff, it’s really nice to have. Having Ant support is nice too. This is handy if you either just don’t want to use Eclipse, or if you are interested in having an automated repeatable build.
Is Android fragmented? What does that even mean?
This is a fairly nuanced, and prickly question. The short answer is no. Many pundits point to “too many revisions” as being evidence of it, but really most consumers don’t care (though we all wish handset manufacturers and carriers would get on the ball and get updates to consumers, and not release new devices using ancient versions), and the Android APIs almost always provide developers with ways to cope with differences and handle them gracefully. There have been a few hiccups with regard to supporting Android 1.5 and earlier, and 1.6 and later, at the same time, or with certain hardware components being present or not, but overall the platform does a good job of mitigating issues. This is something that won’t ever be perfect, the platform will move forward, and existing apps will have to keep up or declare that they don’t wish to do so, but overall the Android team does work to provide compatibility paths, and in my opinion the “issue” has been blown out of proportion.
What’s the coolest thing you’ve coded? (Like a clever algorithm or an application you are excited about)?
One of the things I am most proud of was a Kiosk project that I worked on for a large company. We replaced an existing system with one that was faster, more reliable, and a lot easier to maintain, by throwing out the proprietary stuff the Kiosk vendors wanted us to use and building a GWT application. This was several years ago too, so at the time it was one of those either crazy or genius moves. In the end it worked out; it cured a lot of maintenance headaches, looked good, and is still in use today. Beyond that I am proud of the open source stuff I have done, most notably GWT-Maven. A friend and I founded that project, and I maintained it mostly by my lonesome for several years, before it was migrated into Codehaus, where it is now maintained by others who have taken over the reigns. As for excited, well, I have a few Android application ideas up my sleeve, and a few simple apps already in the market. Android is what I most enjoy working on at the moment.
What are the most common technical problems you see in Android applications, and what advice would you give to programmers so they can avoid these issues?
I see a lot of people getting the basics down, but not really understanding the life cycle of activities and the fact that orientation changes restart them, and that they can be interrupted and restarted by the system when necessary, and so on. Also threading issues and application not responding problems, and perpetually running background services. My advice on these are pretty basic though, get to know your APIs. Read the docs. Test, test, and test again. Also, explore your application with traceview and ddms and figure out where it’s spending time and what you can do to improve it. This is really fundamental stuff, but it’s admittedly tricky to get it right on Android, and it’s surprising how many applications are susceptible to these kinds of issues.
If you could quit your job and focus on a big programming challenge for the next year, what would you tackle?
I have a few key Android projects that I would like to dedicate time to. Specifically I have some ideas about integrating social features, with a cloud based web application, and a mobile application into a system I have been pondering over napkins and beers for a few years now. I know on the surface that sounds like every idea of the last 2 years, but it has a few twists. If I had the time and the ability to focus on it, that’s what I would work on.
You can follow Charlie on Twitter at @CharlieCollins