Android Developer Challenge Deadline Extended

The deadline for the first round of the Android Developer Challenge has been extended upto 14th April 2008. Previously, March 3rd had been announced as a hard deadline. Here's the updated timeline as per the Android Developers Blog:

April 14, 2008: Deadline to submit applications for judging
May 5, 2008: Announcement of the 50 first round winners, who will be eligible for the final round
June 30, 2008: Deadline for the 50 winners of the first round to submit for the final round
July 21, 2008: Announcement of the grand prize winner and runner-up.

[via Android Developers Blog]

Issue Tracker for Android SDK

The Android Developers blog has announced the launch of an Issue Tracker for the Android SDK. Here's the link:

http://code.google.com/p/android/issues/list

As reported previously on this blog, an Issue Tracker had been one of the top items on Android developers' wishlists.


[via Android Developers blog]

Challenges of Android Development

It is always nicer to read the opinions and experiences of developers actually working on Android, compared to the commentary of bloggers / reporters who get their development-related information second hand.

Nazmul Idris of the Developerlife blog seems to have waited over a month after initial release to check out the Android SDK and he's been at it for only a couple of days now. Nevertheless, his Google Android Musings about the challenges of developing for a mobile platform in general, and for the Android platform in particular makes some worthwhile reading:

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.

The above quote is just a small part of the article. Visit the blog to read some more on the topic.

[via Developerlife.com]

Android Bugs : How bad is it right now?

A recent Wall Street Journal article about bugs in the Android SDK quoted a developer proclaim that Android is "clearly not ready for prime time". This led to a flurry of follow-up articles in traditional media and the blogosphere which would lead a casual reader to conclude that Android doesn't work!

The reality is not so bad. The WSJ article seems to be based mostly on the writer's interaction with one developer, and most other articles are merely regurgitated versions of the WSJ piece! There is a much better article on Arstechnica which concluded that "it's a mixed bag". This article is different from all the others in one important way: the author himself tried his hand at Android coding before writing the article.

The Arstechnica article quotes a Google developer who aptly sums up what seems to be the main issue facing Android developers right now: "it's a process problem, rather than a technical problem."

Yes, majority of the complaints from developers seems to be about:

1. Lack of 100% documentation about every single feature and functionality in the Android SDK.
2. More importantly, lack of a proper issue/bug tracking system which is public and up-to-date on the status of resolutions.

To make up for the lack no. 2 above, the Android development community has set up an independent Wiki to track known bugs. I am not sure how complete and up-to-date this Wiki is. Nevertheless, it is quite revealing: there are just 6 critical bugs and 24 non-critical bugs listed as of now, in addition to 5 feature requests.

I don't know about you, but being in software development for 10 years, I think those are damn good numbers for a very early, pre-release version of most non-mission critical software. So much for reports that claimed Android doesn't work!

[via Wall Street Journal and Arstechnica]

Android Developer Challenge: Real-time Android Emulator

Here's a fun project for those of you participating in the Android Developer Challenge.

Create a desktop emulator, which mimics everything that's happening on your Android phone screen... in real time.

I know, the Android SDK already comes with an emulator. That is not what I am talking about. I am talking about an emulator on your computer screen showing you the exact same thing that's happening on your Android phone screen, while it is happening. This would seem almost as if the images from your Android phone were being projected onto the computer screen via Bluetooth or WiFi. But, it's not just a projection of screen images. It should be a full functional emulator, which allows you to do everything your Android phone can do.

Couple of scenarios off the top of my head where this would be fun:

• Suppose you are sitting at your computer in one room of the house, and your Android phone is somewhere in the pocket of your pants, in the wardrobe, at the other end of the house. When a call comes in on your phone, you should be able to accept the call and have a conversation through the emulator on your computer screen. You should be able to make calls, send and receive text messages, play phone games or use any of the fun applications that run on your phone, via the emulator.


• In another scenario, suppose your Android phone gets stolen. You should be able to bring up the emulator on your computer and see exactly what the thief is doing with your phone, listen in on his calls, etc.. Heck, you should even be able to control the phone's camera to take a picture of the thief and/or his surroundings.

No doubt, there are many other interesting scenarios or applications where such an emulator would be useful.

The best part of this project is that, the Android SDK already has an emulator. So, developers just have to figure out a way to connect the real phone to the emulator, and make them mimic each other.

Sound like fun yet? Yeah, I thought so!


Related: Android Developer Challenge: Application Idea

Android Developer Podcast

The Android Developer blog posted a podcast by two architects on the Android engineering team, Dianne Hackborn and Jason Parks:

Dianne and Jason share a background at both Be and PalmSource, and talk about how that experience has been applied to Android. Other topics covered include:

• Some history behind the project
  The high level architecture of Android. For example, how Linux processes handle the VM and manage security (the VM doesn't handle it)
• Details on the Dalvik VM and how it is optimized for small devices
• The architecture: From Intents to Views to Permissions and more
• How XML is slow, but the tools convert the XML to a nicer format for you
• The tooling and steps for building an application on Android
• How so many objects have a URL, and how the environment is like a mini-SOA (Services across processes instead of across the network)
• Thoughts on how you program for small devices, and things to watch out for if you move from the desktop
• The control, or lack of control that you have over the application lifecycle
• "Everything you do drains the battery"
• The thread story: they exist, you don't have to deal with them if you don't want to, and the UI
• Using XMPP for messaging

That's quite a list! I have not heard the podcast yet, but if something in it screams out at me when I listen to it, I will be sure to blog about it.

You can download the podcast here: Android Developer podcast by Dianne Hackborn and Jason Parks


[via Android Developer blog]

Link: Android Projects that caught Google's eye so far...

• A Maze of Twisty Little Passages

[via Android Developer Blog]

Android Developer Challenge inhibiting geek cooperation?

Looks like developers on an open source platform like Android are not so open to sharing, after all? Bad developers! Just kidding. Can't blame them when a pot worth hundreds of thousands of dollars is at stake!

Garett Rogers writes that knowledgeable developers are not being very generous in sharing code samples due to the Android Developer Challenge. The challenge is having the effect of slowing down developers, instead of the other way around.

The slow-down part may be true. The prize money might indeed be inhibiting developers from sharing the best of their knowledge. However, the prize money has caused a much larger number of developers to start messing with Android pronto, than would be the case otherwise. So, the ADC is still a good idea.

As for sharing code samples, Garett Rogers says all is not lost:

I’m sure by the time March 3rd (the cutoff for submissions) rolls around, there will be plenty of code available to help inexperienced developers make ideas come to life. Maybe this is why Google decided to to host the same contest again after the first one ends?

[via blogs.zdnet.com/Google]

State of Organizational Development for Android

Technewsworld asks: Will Developers Embrace Android?

The article seems to be based on information from mostly organizational developers. The article says at the very top:

The idea of creating an open source blank slate for mobile phones is appealing to developers, but many have their priorities set for them by their employers. With mobile development growing ever busier, dropping everything and working on Android often isn't the main goal.

No wonder the article said, "Lots of Interest, Not Much Action", as far as Android development goes. If you mostly talk to independent mobile development organizations, of course they will say that they are focussing on their existing clients and on the handsets/platforms which are already popular in the market. We don't need an article to tell us that.

As far as organizational development goes, we would expect that the bulk of it is happening right now among the members of the Open Handset Alliance. It would have been more interesting to know the state of Android development in the OHA. Where are they right now? What is the progress in the development of different versions of the g(od)Phone? What are their experiences working with Android? Do they have any early prototype hardware / software to show us?

I keenly looked for any mentions of OHA members in the article. There was one small quote at the very end from Sprint Nextel, which was not very encouraging:

It's too early to tell what will happen, but the company's philosophy is to be open, said Scott Sloat, a Sprint Nextel spokesperson.

"It would be against the grain to sign on to this, and then say, 'Hold on a sec, we aren't going to let you do these things,' " he said. "By the same token, we owe it to the customers to make sure their data is protected. Yes, we are going to be open, but we have a duty to make sure the customer and network are protected."

Protect customer and the network! Hasn't that been the constant tune of all carriers for why their phones and networks are so closed? From the sound of this, even some of the OHA members don't seem to be too enthusiastic about giving us anything that's too 'open'. I must say, no surprises there!

Android Developer Challenge: Application Idea

SUNDAY MONEY: Cell phones boost social networking is a generic article about social networking using cell phones by Asbury Park Press. OMG!! You can use a phone that accesses the Internet for online for social networking!!! OMG!!!! That's right. You can safely skip the article. However, there was this in the middle of the article:

Andy Rubin, Google's director of mobile platforms, imagines, among other things, an instant-messaging-like buddy list that is "sorted by how close they are to me no matter where I am. That can be pretty cool."

How many developers participating in the Android Developer Challenge are already working on such an application?

Zumobi's Tiles

Zumobi (formerly ZenZui), a spin-off from Microsoft Research, is launching the beta of its mobile application with a user interface called Tiles, on December 14th. The first beta will be for Windows Mobile.

You can check-out a Flash-based demo of the Tiles interface.

The Zumobi application looks like a version of another popular tiles-based interface - iGoogle. The special touch is the zooming function controlled by the cell phone's number keys. You start with a home screen which has 16 tiles arranged in a 4 by 4 square (picture above). Each tile is a gadget or widget (should we call them midgets for mobile phones?). You can then press different number keys to zoom into a group of 4 tiles and then zoom down to a single tile. Other functions like zooming out, scrolling and tile-specific functions are also mostly number-key based. Nice and simple. I have to say this interface is certainly much better than Yahoo! Go's scrolling carousel.

Along with Zumobi, a Zumobi SDK beta will also be made available for people to create their own midgets. And of course, in the best of Web 2.0 traditions midgets will be share-able.

Zumobi's products page says that it took them 3 years to conceive and refine this interface. Now, how long will it take for an Android developer to build a small application with a similar tile-based zooming interface for iGoogle on the mobile phone?