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]

Links: GTalk translator bots, CallFreq Android app, Google's speech recognition training, UK spectrum auction, Google Mobile in Africa & India

• Translation bots available for Google Talk - Just add a bot as a GTalk contact, send a message to it in one language and it will echo the message back in another language. For example, if you add en2es@bot.talk.google.com as a GTalk contact and send it a message in English, it will echo the same message back to you in Spanish. Check the link for a list of other language-pair bots available from Google right now.
  Tip: If you have an IM app on your mobile phone which can communicate with your GTalk contacts, this could be used as a handy pocket translator. Be warned though, translations by these bots are not very accurate.


• New Android App: CallFreq - Described as a "new generation of a phone dialer", which "intelligently analyzes the calling patterns of an Android communicator user and provide you only with the contacts that you currently need most". The current release sorts your contacts into those you call most frequently.


• Google's speech recognition software is being trained by GOOG-411 phone service users. We can expect this training to be put to good use in future targetted mobile advertising algorithms as well.


• Might Google be interested in bidding for the broadcast spectrum in UK? For those of you who might not know, UK is also planning on auctioning off the spectrum that is/was by analog TV service there. A spokesman for Google UK said that FCC restrictions meant that the company was not allowed to comment on its plans in this area anywhere in the world.


• Google partners with Safaricom in South Africa to offer Google services on mobile phones there. Interestingly, it sounds like these services are being offered through the Google Apps route. Safaricom customers will have email addresses which are their mobile numbers followed by @safaricom.com and those who cannot access Google services such as Gmail through their mobile phones can access it via Safaricom's website. Sure sounds like Google Apps to me. Good move there by Google - offering Apps to Safaricom and in turn extending its reach to their customers' cell phones.


• Search Engine wars on mobile phones are sure heating up in India. There are seven times more mobile phone users in India than PC-owners. So, it is natural for Google, MSN and Yahoo! to fight it out for mobile users in India.

Links: Android running, 700 MHz Auction guide, Cellphone service survey, Object DB for Android

• Google Android runs on Sharp Zaurus SL-C760 - Someone outside of the Open Handset Alliance got Android running on hardware available in the market now.


• The Ultimate 700 MHz Auction Guide - Nice job by Gizmodo in explaining "what it is, who'll win and why you should care".


• Consumer Reports Cellphone Service Survay 2008 Published - Gizmodo summarizes the survey of 47,000+ readers of Consumer Reports, which declares Verizon to be number one!


• db4objects Announces db4o Database as Android Ready - Businesswire reports that db4objects, creator of the leading open source object database for Java and .NET, announces that db4o runs seamlessly on the Android platform.

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]

Different take on the imaginary Google vs Sun splat

The blogosphere has been abuzz in recent days over the impending splat between Google and Sun over how Google has chosen to implement Android. Android does not use the Java Micro Edition. Instead, Google wrote its own virtual machine Dalvik. So, there will be absolutely no revenue to Sun from the success of Android. The thinking is that if Android becomes spectacularly popular, Sun will see what it's losing and so it might sue Google. Here's a different take on the issue: Sun/Google Android “fight” overblown.

While Android is based on a machine-independent VM architecture that compiles and runs code written in the Java language, it’s not exactly Java (Tee eM). In particular it’s a complete break from Sun’s Java ME (Micro Edition) offering. A lot of propeller heads get their beanies in a twist whenever someone steps off the “standards” path, so predictably there were cries of “Why couldn’t they just use Java ME?” But I believe there are many folks at Sun who are quietly saying “I wish we could have done that.”

Let’s face it, how many developers really like Java ME? How many can describe the difference between CLDC, CDC and MIDP? Between Foundation, Personal Basis, and Personal profiles? How many consider javax.microedition.lcdui the pinnacle of user interface design? Not many. (And if you’re one of them, you should seriously consider therapy). Java ME has years of baggage and legacy API that Android ignores. Over-complicated, and under-compatible, Java ME had backed itself into a corner, leaving the field open for competitors like Flash Lite to gain ground. Google’s initiative opens a new chapter for Java (or ‘Java-like’, if you insist) technology.

However, Google did make one big mistake with Android, the same mistake that IBM made years ago - it cut them out of the process, at least in perception if not in fact. In IBM’s case this resulted in a culture of distrust and dis-harmony (pun intended) between the two companies that continues today. Sun/IBM unity behind Java is a lost cause. But in Google’s case, the outcome can/will/must be different.

[via blogs.zdnet.com/Burnette]