developerlife – The Blog » Google Android Musings

Posted January 4th, 2008 by Nazmul

Comprehensive Real-World BlackBerry Training Courses by developerlife.com

Want to learn from the Masters? We’ve created groundbreaking BlackBerry software (we are finalists in the 2009 BlackBerry Developer Challenge). We have a complete set of instructor-led training courses available for BlackBerry development that will turbo-charge your BlackBerry development efforts. Whether you are a newbie or an experienced developer, we have modules that will fit your needs. Learn more about our courses & schedule.

I’ve been learning the Google Android Platform APIs over the last couple of days, and I’m quite impressed with the amount of good documentation available on the platform already. There’s a nice plugin for Eclipse, but the command line tools don’t work very well with ant, and the IntelliJ IDEA integration is very poor (there’s a crappy IntelliJ plugin for Android that really doesn’t work, read the comments on this link to find out what’s wrong). However, you can import Eclipse projects into IDEA and work with BOTH IDEs, if you want to use IDEA 7.

There are no devices on the market right now that run on this platform. However, that’s not the only problem I see with developing apps for this platform. I’ve got a lot of experience building enterprise mobile app platforms, so I’ve got some insight on working with embedded systems. Depending on the type of hardware that Android will be deployed in, there will be tremendous differences in capabilities (CPU, battery, screen size, input device, etc). To accommodate all these diverse hardware environments, the Android platform has to be very flexible in allowing application development, and this complicates the API and places a burden on the app developer to have some skill, talent, and experience in building multithreaded systems, and possibly asynchronously networked systems, for resource constrained environments. Android has lots of tooling that makes it easier to work it, but the developer still has to know a lot of stuff even before getting started with an Android app. GWT this is NOT.

In Android, there is no Swing or AWT, so you have to familiarize yourself with the new GUI APIs (hierarchically nested Views) that are part of Android. That’s not so bad… since they have lots of pre-built widgets, and they provide lots of data binding support for diverse data models. Having said that, the biggest difference in building an Android app, from one that runs on a desktop/server/laptop Java VM is that the Android app runs in a managed container. The SystemManager is responsible for taking the app through various discretely defined lifecycle states, which allows for apps to be interrupted by network coverage issues, or incoming phone calls, or just being turned off, as examples. An Android app that has a UI is called an Activity. Activities run in their own Linux process, and they have one default thread (Swing-like-EDT), that can not be hogged for more than 5 seconds, otherwise, the SystemManager will shut the app down. This requires users to know how to create background tasks, which is not easy. Also, the UI metaphor in Android is one of building "screens", rather than building apps which have nested panels and complex layouts and centralized state management. This is a very common approach to taken when building UIs/apps for mobile devices. The idea is to split up an application into many discrete loosely coupled pieces… some that are bound to the screen (Activity), and others that are "headless" (Services). Additionally, there are lots of container managed persistence and data exchange mechanisms that are available. However, given that these pieces can be swapped out with different pieces, and that any screen can be paused or activated at any time makes life more tricky for the app developer. All of this raises the barrier to entry so to speak. And I’m not even going into the optimization techniques that you have to adopt to write code that runs fast.

All these are good things. However, I don’t think that they make it "easier" to develop Android apps. Building mobile apps is not easy, and Android is not an exception. It tries to cleanly abstract various pieces of the platform, but it’s difficult to learn and get used to, if you don’t know about threading, network interruptions, freezing on the EDT, etc. On top of that you have to learn a new GUI API that is not similar to Swing or AWT or SWT…

I’m going to post tutorials on Android development over the coming months, but I just wanted to share my thoughts on the platform as I’m learning it. My fear is that even if handsets are available that run Android, the majority of apps on this open platform might really suck! Most developers don’t do well with complex multithreading and disjointed apps using a completely foreign API. And what’s the incentive for someone to learn all of this? There are no handsets out there yet…

Anyway, it makes me sad that Apple doesn’t support Java 6, and the iPhone does not have an SDK that includes Java 6. Since Apple is in complete control over the hardware, software, and to a lesser degree the mobile infrastructure, they are in a much better position to deliver an OS and development environment that closely mimics a desktop environment. What a shame. Imagine porting your Java 6 apps with minimum work to run on an iPhone or iPod Touch.

Update (Jan 7 2008) -There was quite a bit of interest in this blog post. So I’ve created a much more in-depth review of the SDK and architecture. Enjoy!

Google Android Musings

Leave a Reply

Sitemap

Categories

Tags