Like many of you, I am a huge fan of TweetDeck for Android. In my opinion, it is the best Twitter application on the Android platform, hands down. I use it on a daily basis and find it fast, fluid, and a treat to look at. This excellent piece of software fills in the missing holes of the of the official Twitter application, providing a unified social media experience.
We just sat down with TweetDeck's developer, Max Howell, to find out more about him and his thoughts on Android. Keep reading for the full Q&A!
Android Police: What was the inspiration for TweetDeck in general (for the company and the product)?
Max Howell: Our founder worked in the banking industry developing software to visualize high volume financial transactions. When Twitter was new, he saw how the same techniques (columns, notifications) could be used to help digest social data. As soon as he built the earliest versions of TweetDeck they started taking off virally.
Android Police: Why Android? Why did the company expand to this platform?
Max Howell: Our foray into the iPhone had produced a very popular app, so we needed one on Android too.
Android Police: What is the process you go through when developing?
Max Howell: You need a tight, small team with insanely good design skills and programming skills. You need a fantastic sense of the product's goals and user base. Then you need to live and breathe the product, constantly iterating it and talking about it and testing it. After doing this for months you'll wake up one day and realize that it's done. Then you should have a release party.
Android Police: What is the future of TweetDeck on Android? Does TweetDeck have any other plans for further integration with core services?
Max Howell: More Android integration. More integration with the core services. Currently our Foursquare integration is probably the best out there. We would like to give all the services that treatment. Like our mature desktop product we'll embrace new services and new features as soon as possible.
We need new Android developers. If you are a talented product developer with good understanding of Android then you should contact us!
Android Police: Any plans to put TweetDeck on future Android tablets?
Max Howell: Tablets are very exciting and there is a ton of (innovative) scope for what apps like ours can do there. We are already on the iPad, but that app was a bit rushed to meet Apple's launch deadline, so we are going to revisit it simultaneously while we redo our iPhone app. Though at first it will probably be nothing more than a bigger version of the iPhone app, we absolutely will then begin work on a tablet optimized TweetDeck for the iPad and whatever else is on the market.
Android Police: How do you code for different phones? What is your process?
Max Howell: The only difference is the iPhone ad-hoc distribution limitation. And while I can appreciate that such a system prevents the type of problem we had where morally despicable opportunists sold our beta APKs in the Google Market Place, it doesn't really make up for it being tedious and restrictive.
We had 30,000 beta testers for Android. We can have one hundred with iOS. It changes the way you approach development. You can't take as many risks, as your code has to be robust without the benefit of mass-testing.
The two month beta period also really helped us to hone the UI for the final product by taking into account all the excellent feedback we got from our super-keen users.
Android Police: Do you like developing for iPhone or Android better, and why?
Max Howell: iPhone honestly. The development tools for Android are raw and relatively unloved which can lead to frustration. Debug cycles on Android take half a minute at least. On iPhone you can be testing new code in seconds. And it takes less effort to make beautiful software on iPhone, and ultimately all that matters is: is my software gorgeous? Does it feel *amazing* to use? Because if it doesn't your app will not take off.
We had to work harder to make our app look great and feel great on Android. It's worth it though, and ultimately is achievable. Google could make it easier, currently the UI tools in the API feel like the wrong level of abstraction.
Partly this is because the iOS SDK is more mature. But I'm not 100% convinced Google has the right people working on the SDK and API in order to catch up.
Fragmentation is not really an issue, despite what you might hear. The underlying Android layout system scales your app almost perfectly for the different screens. Some tweaking is inevitably required, but web-development is certainly more difficult. Writing code that works on 1.6 but takes advantage of 2.2 is really easy, and the sort of thing you have to do on iPhone too. Nobody has to compromise. The fact that multiple vendors have customized their Android distribution is barely a problem. Custom UIs like Sense have to be taken into account, but you have two options really: do your own assets for controls, or do it 100% with native ones. So the only time we had trouble was with the black status bar region that Sense has, so we had to rethink our notification icon.
However, ultimately testing and getting user feedback is half of product development, and with iPhone this is painful to the point that you avoid it. Emailing your friend the latest APK and having them install it straight from the phone just doesn't have an equivalent on the iPhone right now.
Android Police: What phone do you use right now?
Max Howell: I have a Nexus One. But really I want a G2 and an iPhone 4.
Developing on the N1 was perhaps a mistake. We became used to the speed of it. When I finally started testing on the Droid I had to go back and do a bunch of UI optimizations.
People often underrate the importance of UI speed on touch devices. It is imperative that the component you are interacting with moves with your finger at a high frame rate. Even 30 frames per second feels laggy with touch interaction. Really, you need to get a draw rate of 60fps. This is hard with some standard Android components. In fact it is hard on Android in general due to the unpredictability of the garbage collector. When a GC cycle hits your app pauses, this is noticeable as UI stutter, especially visible during flings on scroll areas.
For example, the standard Android List View component is slow. So slow that in the end—after trying for a while to wring some more performance out of it—I wrote a custom implementation.
Android Police: What is your favorite Android application?
Max Howell: Spotify. I need my music on the go. I have to be honest, though. Their UI doesn't feel very Android-like. We worked hard to make our app feel both TweetDeck and Android.
Android Police: Have you faced any issues while developing? What do you think of the tools Google provides to develop?
Max Howell: The Activity lifecycle is very different to standard app design models. You think you understand it and then actually, you find out that you didn't quite get it. The documentation is not sufficient, and even the plethora of textbooks on the subject often are inaccurate when detailing Android's underlying mechanisms. And when they are accurate, they are sparse.
Don't get me wrong, it's very clever, and you end up writing apps that (when bug fixed) are far more robust than anything you have written before. You live with the constant danger of being terminated by the system to save RAM and battery and so you deal with that. However the SDK only provides a minimal convenience layer to facilitate this. Serializing app state should be trivial considering that it is continuously necessary, but it is not. Making web service requests in a manner where they will survive, eg. rotation, should be trivial, but it is not. Code complexity becomes an issue which eventually imposes on your desire to add functionality.
Platform documentation in general is poor. Plenty of classes and functions are not documented, or possibly worse, wrongly documented. The source code is available so I often have resorted to reading the "ultimate" documentation. This is great and I often wish I could do this for Cocoa Touch, however I shouldn't *have* to. I have reported multiple cases of bad documentation but in the end this is too time consuming. Google have the resources, they should absolutely hire a team of world-class documentation writers.
The tools Google provides are basic and buggy. They recommend Eclipse, but it is an endless source of problems. In the end we bought an IntelliJ license and their integration with Google's android SDK is far superior to the ADB plugin Google provide for Eclipse.
JVM apps on Android have—generally—a 16 megabyte heap limit. This is extremely restrictive. It's like programming apps for 1990-era PCs. I understand (but I don't concur) why this is imposed but it makes it very difficult to write apps that have excellent look and feel and that don't also constantly crash due to OutOfMemoryErrors. This kind of thing is not helped by some choices in the SDK. For example the JSON implementation that is provided cannot parse in a streaming fashion. This means for an app like ours you are allocating large chunks of memory every poll-period and risking getting force-closed.
Work needs to be done optimizing the memory consumption of the must-use classes in the SDK. Better memory analysis tools should be provided. The current DDBS tool cannot tell me anything useful about where the memory in my app is allocated and I need this information—figuring out how to use less memory is important.
Android Police: Where do you think Android is going? Can it be stopped?
Max Howell: Android will be the biggest cellphone platform in no time. And I'm sure you're going to see it cropping up in all sorts of other devices. However we aren't seeing a market like the PC market of the 1990s. There will be no "winner" like there was Microsoft. Just a bunch of decent competitors. Personally I have great interest in Windows Phone 7 and I sincerely hope that we see another WebOS phone.
We here at Android Police would like to thank Max Howell for taking the time out of his busy schedule to chat with us. If you haven't checked out TweetDeck yet, you should!