Get Paid To Promote, Get Paid To Popup, Get Paid Display Banner

Friday, December 5, 2008

New Resources for Developers

We're back in action after a Thanksgiving break filled with turkey, stuffing, and pumpkin pie. Now it's the holiday season (at least, here in the U.S.) and we're filled with good will toward developers. Today I wanted to talk about a couple things we just finished polishing up.

First, the Android 1.0 SDK, release 2 is now available. Like the previous 1.0_r1 release, this new 1.0_r2 build creates applications that are compatible with Android 1.0 devices, such as the T-Mobile G1. This new release fixes a few bugs. In 1.0_r1, it was possible for developers to write technically-illegal code by using the Java Reflection APIs to access private or protected fields and methods. 1.0_r2 fixes that problem by enforcing private/protected visibility of items accessed via Reflection. Meanwhile, the class android.R.styleable was included in 1.0_r1 primarily for documentation purposes as a way for developers to look up the style attributes available to them to use. However, actually referring to that class via source code would result in applications that might break when run on future versions of the Android platform, so 1.0_r2 corrects the oversight and removes access to the class from the android.jar file. (The class remains in the documentation for reference purposes, though.)

Both of these problems are obscure "future-proofing" issues, and I'd be quite surprised if they actually caused problems for anyone, but now they're fixed. 1.0_r2 also includes a few other smaller changes; check out the release notes for all the details.

Second, many of you have asked if developer devices will be available. We've worked with our partners to create a program for developers to purchase devices that enable them to test and debug applications more easily.

I think these new tools will be quite helpful to developers, and I'm looking forward to seeing what people do with Android, next.

Monday, December 1, 2008

Touch Mode

Designing and developing user interfaces for Android is very different from doing so in a regular desktop environment. Because Android runs applications on mobile devices, application designers and developers must deal with numerous constraints that are not always obvious. To help you design and develop better applications, we are publishing a new series of posts focusing on Android user interfaces. In this series, we will give you design guides and tools, development tips, and explain the fundamental principles of the Android UI toolkit. The goal here is simple: we want to help you design and develop a great user experience. To start off this series, I'd like to introduce touch mode, one of the most important principles of the UI toolkit.

The touch mode is a state of the view hierarchy that depends solely on the user interaction with the phone. By itself, the touch mode is something very easy to understand as it simply indicates whether the last user interaction was performed with the touch screen. For example, if you are using a G1 phone, selecting a widget with the trackball will take you out of touch mode; however, if you touch a button on the screen with your finger, you will enter touch mode. When the user is not in touch mode, we talk about the trackball mode, navigation mode or keyboard navigation, so do not be surprised if you encounter these terms. Finally, there is only one API directly related to touch mode, View.isInTouchMode().

Sounds easy enough right? Oddly enough, touch mode is deceivingly simple and the consequences of entering touch mode are far greater than you might think. Let's look at some of the reasons why.

Touch Mode, Selection, and Focus

Designing a UI toolkit for mobile devices is difficult because of the various interaction mechanisms they provide. Some devices offer only 12 keys, some have a touch screen, some require a stylus, some have both a touch screen and a keyboard. In that regard, it is a great benefit for the Android development community that the first commercially available device, the G1, offers multiple forms of input using a touch screen, a trackball, and a keyboard. Because the user can interact with applications using three different mechanisms, we had to think very hard about all the possible issues that could arise. One issue led us to create the touch mode.

Imagine a simple application, ApiDemos for example, that shows a list of text items. The user can freely navigate through the list using the trackball and they can also scroll and fling the list using their finger. The issue in this scenario is the selection. If I select an item at the top of the list and then fling the list towards the bottom, what should happen to the selection? Should it remain on the item and scroll off the screen? In this case, what would happen if I then decide to move the selection with the trackball? Or worse, if I press the trackball to act upon the currently selected item, which is not shown on screen anymore. After careful considerations, we decided to remove the selection altogether.

In touch mode, there is no focus and no selection. Any selected item in a list of in a grid becomes unselected as soon as the user enters touch mode. Similarly, any focused widgets become unfocused when the user enters touch mode. The image below illustrates what happens when the user touches a list after selecting an item with the trackball.

To make things more natural for the user, the framework knows how to resurrect the selection/focus whenever the user leaves touch mode. For instance, in the example above, if the user were to use the trackball again, the selection would reappear on the previously-selected item. This is why some developers are confused when they create a custom view and start receiving key events only after moving the trackball once: their application is in touch mode, and they need to use the trackball to exit touch mode and resurrect the focus.

The relationship between touch mode, selection, and focus means you must not rely on selection and/or focus to exist in your application. A very common problem with new Android developers is to rely on ListView.getSelectedItemPosition(). In touch mode, this method will return INVALID_POSITION. You should instead use click listeners or the choice mode.

Focusable in Touch Mode

Now that you know focus doesn't exist in touch mode, I must explain that it's not entirely true. Focus can exist in touch mode but in a very special way we call focusable in touch mode. This special mode was created for widgets that receive text input, like EditText or, when filtering is enabled, ListView. This is why the user can type text inside a text field without first selecting it with the trackball or their finger. When a user touches the screen, the application will enter touch mode if it wasn't in touch mode already.  What happens during the transition to touch mode depends on what the user touched, and what currently has focus.  If the user touches a widget that is focusable in touch mode, that widget will receive focus.  Otherwise, any currently focused widget will not retain focus unless it is focusable in touch mode. For instance, in the picture below, when the user touches the screen, the input text field receives the focus.

Focusable in touch mode is a property that you can set yourself either from code or XML. However, it should be used sparingly and only in very specific situations as it breaks consistency with Android normal behavior. A game is a good example of an application that can make good use of the focusable in touch mode property. MapView, if used in fullscreen as in Google Maps, is another good example of where you can use focusable in touch mode correctly.

Below is another example of a focusable in touch mode widget. When the user taps an AutoCompleteTextView's suggestion with his finger, the focus remains on the input text field:

New Android developers often think that focusable in touch mode is the solution they need to "fix" the problem of disappearing selection/focus. We really encourage you to think very hard before using it. If used incorrectly, it can make your application behave differently from the rest of the system and simply throw off the user's habits. The Android framework contains all the tools you need to handle user interactions without using "focusable in touch mode". For example, instead of trying to make ListView always keep its selection, simply use the appropriate choice mode. And if you feel that the framework does not suit all your need, feel free to let us know or contribute a patch.

Touch Mode Cheat Sheet

Do:

  • Remain consistent with the core applications
  • Use the appropriate feature if you need persistent selection (radio button, check box, ListView's choice mode, etc.)
  • Use focusable in touch mode if you write a game

Don't:

  • Do not try to keep the focus or selection in touch mode

Behind the apps: Amazed

This week's developer video features Jason Tomlinson of Hands-On Mobile. He wrote Amazed, an application open sourced in the apps-for-android project. Things Jason mentions in the videos include:

  • Amazed was built primarily to get familiar with the accelerometer. This helped him in his work on Guitar Hero® World Tour Mobile for Android.
  • Using traceview to track down which methods take the most CPU cycles.

This and other Android developer videos can be found here.

Friday, November 7, 2008

Behind the apps: Amazon and imeem

Last week we introduced a couple Android developers who shared how they built their Android apps and gave their insight into Android app development. This week, we have videos of two developers who've built music-related apps.

The first is of Allan Hsu—he wrote imeem's Android app. A couple of things he mentions in his videos:

The second video features Casey Langen—he wrote the Amazon MP3 for Android app. Things he mentions in the videos include:

Check out other Android developer videos here: Android App Developers.

Tuesday, October 28, 2008

The stories behind the apps

As we mentioned yesterday, the Android Market is now open for developers to upload their applications. I'm pretty excited because Market, along with the availability of the first Android-powered phone and the Android 1.0 SDK, puts the basic pieces of the Android platform into place for developers to create and distribute their apps.

To help developers better understand what's available to them, we've collected stories from some Android application developers. In the videos, you'll hear them talk about how they built their apps, their takes on the Android platform, and also some tips they want to share with other developers. I think they have a lot of insight to share about Android application development, so I hope you'll find these videos useful.

Here are the first two developers in this series:

Jeff Sharkey is an ADC finalist—he built CompareEverywhere.



Jacob Abrams is from Glu Mobile and helped to build their first Android app, Bonsai Blast.



Keep an eye on this blog, our YouTube channel, or the playlist for this series for more of these videos in the coming weeks.

Wednesday, October 22, 2008

Android Market: Now available for users

Last month I outlined some details around Android Market. Today, Android Market launched for users to download applications along with the first Android-powered phone—the T-Mobile G1.

With Android Market, users can easily download apps to their Android-powered phone. Users can also rate the apps they've downloaded and leave comments. These users' ratings along with anonymous usage statistics help determine how apps are ranked and presented within Android Market.

If you're a developer, you will be able to register and upload your applications starting next Monday, 2008-10-27, when we've wrapped up a few final details. In order to make sure that each developer is authenticated and responsible for their apps, you will need to register and pay a one time $25 application fee. Once registered, your apps can be made available to users without further validation or approval.

Starting in early Q1, developers will also be able to distribute paid apps in addition to free apps. Developers will get 70% of the revenue from each purchase; the remaining amount goes to carriers and billing settlement fees—Google does not take a percentage. We believe this revenue model creates a fair and positive experience for users, developers, and carriers.

There are already over 50 apps available in Android Market today. You can view a showcase of some of these apps—which include multimedia, location-based tools, barcode scanners, travel guides and games—at http://www.android.com/market/. Now that Android Market is live and ready for contributions, we hope to see developers adding their own compelling apps starting next week.

In the coming months, we'll continue to roll out additional tools and enhancements to Android Market. We also expect to see additional Android-powered devices rolling out by different carriers around the world. Starting today, you can get a device, test your apps on it, and get them ready for upload. On Monday, to share your app with the world, simply register, upload your application and publish it. It's really that easy. I look forward to seeing what you bring to the Market.

Update: As of Monday morning (2008-10-27), http://market.android.com/publish is now available for developers to publish their apps on Android Market.

Tuesday, October 21, 2008

New Android Maps API Terms of Service and Key Enforcement

When we released the 0.9_r1 beta SDK, we mentioned that the Maps API included with Android would soon require an API key to function correctly and load map tiles. Part of the reason for this was that the Terms of Service (ToS) for the Maps API had not been finalized.

Today, I'm pleased to be able to tell you that the new Android Maps API ToS are now finalized and they're actually pretty exciting. Most of the restrictions present in the old ToS are now gone—for instance, it's now permissible to use the Android Maps API to build "friend finder" style applications. There are still a few limitations, but not nearly as many as before.

Now that the ToS are finalized, it's time to take the next step. Until now, developers have been able to use any value for their Maps API key—that is, the Maps API keys weren't enforced. However, starting early tomorrow morning (Oct 22nd, PDT), we are turning on Maps key enforcement, so the grace period is ending very soon. This means it's also time for developers to acquire and begin using real API keys. Here's what you'll need to do:

  1. Visit http://code.google.com/android/maps-api-signup.html, fill out the required information, agree to the Terms of Service, and submit.
  2. Take the key you are given in response, and place it either:
    • In the XML layout where you declare your MapView, or
    • In your source code, where you instantiate your MapView object

The way the keys work is that when you use a MapView, it queries the system to find the public fingerprint ID of the certificate used to
sign the currently-running application. The MapView then works with the server to verify that the certificate which signed the current application is the same certificate to which the current Maps API key belongs. If they match, then tiles are displayed; if they do not match, then no map tiles are displayed.

You will need one Maps API key for each certificate you use to sign your applications. That is, you'll need separate Maps API keys for both your debug-time signing certificate used in the emulator, and for your release-time certificate you'll use when publishing your apps. Fortunately this is free, and there is no limit to the number of keys you can acquire. Finally, note that this only applies if you're using a MapView in your
Android application. If you don't use Maps at all, or if you use an Intentto launch Google Maps, you don't need to follow these steps.

Be sure to get your Maps API key now to avoid a disruption.

Android is now Open Source


Over the past year, we announced Android, released several SDKs (eventually resulting in the 1.0 SDK), gave out the first half of the $10,000,000 prize money for the Android Developer Challenge, and prepared the first Android-powered device for users. Tomorrow, the T-Mobile G1 goes on sale.


But today, we're making what might just be the most exciting announcement of all: we and our Open Handset Alliance partners have now released the source code for Android. There's a huge amount of code and content there, so head over to http://source.android.com/ for all the details.


I'd like to offer a huge thank you and congratulations to my colleagues and the Alliance partners for what I hope will be a red-letter day for the open source community, and openness in the mobile industry.

Monday, September 22, 2008

Panoramio

The Panoramio web site has a great collection of photos from all over the world, and they also have a very convenient web API. I thought it would be a lot of fun to use Android to access this content while you are out walking around – and especially to have Android find interesting photos based on your current location. The resulting open source application is now available in the apps-for-android project.

The application starts by showing your current location in a custom MapView. You can pan and zoom this map to choose the area you want to search.

Once you have selected a search area, the application downloads thumbnails of the most popular photos taken within that area:

You can tap on an item to see more details.

From here you can use the menu to find more pictures by the same photographer or to see the original photo on the Panoramio site. My two favorite features, though, help you find the location of the photo in the real world. You can show the location on the map along with your current location:

Or, you can bring up a radar view that uses the compass and GPS to show you the location of the photo in relation to your own location:

I thought that other applications might want to use the radar view for their own purposes ("find me the nearest taqueria"), so I split that into its own package. You can find the source for that in the Radar project. Of course, you don't need the source in order to use this feature. Because of Android's component architecture, all you need to do us use an Intent:

Intent i = new Intent("com.google.android.radar.SHOW_RADAR");

i.putExtra("latitude", 37.422f);

i.putExtra("longitude", -122.084f);

startActivity(i);

The code for these applications is not very long, but they are a good example of how to use a number of Android's location APIs:

Friday, September 19, 2008

Using WebViews

I've written a small application called WebViewDemo that shows how you can add web content to your application. You can find it in the apps-for-android project. This application demonstrates how you can embed a WebView into an activity and also how you can have two way communication between your application and the web content.

A WebView uses the same rendering and JavaScript engine as the browser, but it runs under the control of your application. The WebView can be full screen or you can mix it with other Views. The content for your WebView can come from anywhere. The WebView can download content from the web, or it can come from local files stored in your assets directory. The content can even be dynamically generated by your application code. For this example, the HTML comes from a local file called demo.html.

This application does not do very much: when you click on the android, he raises his arm.

This could, of course, easily be accomplished with a little bit of JavaScript. Instead, though, WebViewDemo takes a slightly more complicated path to illustrate two very powerful features of WebView.

First, JavaScript running inside the WebView can call out to code in your Activity. You can use this to have your JavaScript trigger actions like starting a new activity, or it can be used to fetch data from a database or ContentProvider. The API for this is very simple: just call the addJavascriptInterface method on your WebView. You pass an object whose methods you want to expose to JavaScript and the name to use when making calls. You can see the exact syntax in WebViewDemo.java. Here we are making our DemoJavascriptInterface object available to JavaScript where it will be called "window.demo".

Second, your Activity can invoke JavaScript methods. All you have to do is call the loadUrl method with the appropriate JavaScript call:

mWebView.loadUrl("javascript:wave()");

Our WebViewDemo uses both techniques: when you click on the android, it calls out to the activity, which then turns around and calls back into the JavaScript. WebViews are very powerful, and they may be a valuable tool to help you build your application – especially if you already have a lot of HTML content. As it happens, we've used exactly this approach in some of the applications we've written.

Monday, September 15, 2008

Divide and Conquer

Years ago I was addicted to a simple game that I played on my then state-of-the-art Pentium-75. In this game, balls would bounce around, and I would try to partition them into small enough spaces so that I could go to the next level where more and more balls would be added. As of a couple of months ago, for the life of me, I couldn't remember the name of this game. So when I sat down to write an application for Android in my 20% time, I thought, why not try to recreate something similar? After completing most of the game and showing it to some of my friends at work, one of them said, "Oh, this reminds me of JezzBall!" Eureka! If working on this game does nothing more than reveal the name of one of the favorite games of my youth, I'll call it a success, but in the meantime, I'm happy to announce that the source of this application, named Divide and Conquer, is now available on apps-for-android.


The game starts with instructions:



and begins simply enough with one ball bouncing around. You drag your finger in a horizontal or vertical gesture on the screen to initiate a line that extends until it reaches the edges:




In each level, once you've shaved off 80% of the original area, you move to the next level. Here's a screen shot of level 6:


If a ball hits a line in progress, you lose a life:



Once you are out of lives, it is game over:



While this game isn't going to win any awards for cutting edge graphics, it demonstrates use of several Android features and APIs:


  • custom drawing and animation
  • touch input based gesture detection

  • overriding the default behavior of the back key in some situations (to pause the game)

  • creating custom Dialogs

  • configuring an application to be full screen with no title or status bar
  • use of the preferences framework

  • use of the vibrator API

DivideAndConquerView is a custom View that implements its own onDraw method using the Canvas methods, and gesture detection using onTouchEvent and a helper class DirectionPoint. It keeps track of the state of the game using BallEngine, and reports relevant events back to the main activity of the application, which, in turn, keeps track of and controls the state of the game. The application is configured to be full screen in its AndroidManifest.xml file.

Thursday, September 11, 2008

Three new Samples: Triangle, SpriteText and Downloader

I've posted three new open source samples to the apps-for-android project: Triangle, SpriteText and Downloader.


The first two samples, Triangle and SpriteText, show techniques that would be useful to anyone using the OpenGL ES 3D graphics APIs to write Android applications. The samples contain several reusable classes that may eventually be incorporated (in some form) into the SDK. Chief among these is the GLView class, which abstracts the OpenGL ES book-keeping code from the rest of the application. GLView helps handle the extra work OpenGL ES applications have to do when the activity is paused and resumed, and when the display goes to sleep and wakes up. In the Pause/Resume case the OpenGL surface has to be recreated. In the display sleep / wake-up case the entire OpenGL context has to be recreated.

Triangle

The first sample, Triangle, shows how to use the GLView class and the OpenGL ES 3D library to display a spinning textured triangle. Think of it as the "hello, world" of OpenGL ES apps. Because it's relatively simple, it's a good place to start when experimenting with the OpenGL ES API.


SpriteText

The second sample, SpriteText, shows how to efficiently display screen-aligned text using the GL11Ext.glDrawTexiOES method. SpriteText contains a reusable LabelMaker class for drawing static text and screen-aligned images, as well as a Projector class for finding the 2D screen coordinates corresponding to a 3D point, and a MatrixTrackingGL class for keeping track of the current transformation matrix. Finally, it shows how to use these classes to display a milliseconds per frame counter. A ms/f counter can be helpful for tuning graphics performance.


Downloader

The third sample, Downloader, shows how to add a downloader activity to your application. The downloader activity runs at the beginning of your application and makes sure that a set of files have been downloaded from a web server to the phone's SD card. Downloader is useful for applications that need more local data than can fit into an .apk file. For example a game could use Downloader to download the game's artwork, sound effects, and level data. The Downloader activity is designed to be a drop-in addition to your application. You customize it by supplying the URL of an XML configuration file which lists the data files that need to be downloaded.

Thursday, September 4, 2008

Android Photostream

I'm pleased to announce that a new open source sample application—called Photostream—has been added to the apps-for-android project. Photostream is a simple photos browser and viewer for Flickr. All you need to use it is a Flickr screen name or user name (the application offers a default user name if you just want to try it.)



This application serves as an illustrative example of several Android features and APIs:


  • Activity aliases

  • Adding custom shortcuts to Home

  • Adding a new wallpaper chooser to the system

  • Custom layouts

  • Custom XML attributes

  • Use of themes

  • Use of styles

  • Use of text colors

  • Use of <include>

  • Use of bitmap and layer drawables from XML

  • Use of HttpClient

  • Proper interaction between background threads and the UI thread

  • Efficient display rotation (using the new onRetainNonConfigurationInstance() API)

  • Animations and layout animations

  • Cropping an image

  • Image manipulation





My favorite feature is the ability to add a new shortcut type in Home, to create a shortcut to any Flickr account. The shortcut shows a custom icon, downloaded from the Flickr user profile:





If you plan on reusing the source code to access Flickr in your own application, you should modify the Flickr.java file to replace the existing API key with your own. The application source code also contains a very handy class called UserTask.java. This class is designed to help you easily write background operations that interact with the UI thread.

Monday, August 25, 2008

Some information on APIs removed in the Android 0.9 SDK beta

Earlier this week, we released a beta of the Android SDK. In the accompanying post, I mentioned that we had to remove some APIs from the platform for Android 1.0, and as a result they don't appear in the 0.9 beta SDK, and won't appear in 1.0-compatible SDKs. Today, I want to take a few minutes to explain why.


GTalkService


We were all really excited when the "XMPPService" (as it was called, at first) was included in the first early-look SDK. Once we brought in our security review team to examine Android, however, they soon realized that, as exciting as it is, the GTalkService has some fundamental security problems. Rich Cannings is one of our security researchers, and here's his explanation of the issues:


When I first read about GTalkService, I was both excited and scared. As a developer, I was interested in a feature that provided a simple interface to send messages between two Google Talk friends. The messages would appear on the receiving device as a standard Intent that was easy to handle. How simple and beautiful is that? Unfortunately, when I put my tin foil hat on, I recognized that things are a little more complicated than that.


We decided to postpone GTalkService's data-messaging functionality for the following reasons:


  1. "Repurposing" Google Talk Friends


    Google Talk friends are intended for a different purpose than that envisioned by the GTalkService. Your Google Talk friends can contact you at any time via IM. They can see your email address and often can see your real name. However, the idea of a Google Talk friend does not always line up with the types of people who may want to interact with via an Android application.


    For example, imagine a really cool mobile Massively Multiplayer Online Roleplaying Game using GTalkService. You would have to add all the players to your Google Talk friends list in order to play with them. Next time you log in to Google Talk from your desktop or on the web, you would notice that you have many new "friends". You may not want to chat with these friends -- and perhaps worse, you may not want them to know what your real name or email is.


    We do realize that Android users will want to interact with other Android users anonymously and for short periods of time, especially in gaming scenarios. Unfortunately, it turns out that using Instant Messaging is not really a good way to do that.


  2. Verifying Remote Intent Senders


    Intents were designed to send messages within the device. The Intent subsystem can conclusively determine who sent Intents only when the Intents originate from the same device that services the Intent. When Intents come from other devices, the Intent subsystem cannot determine what application sent the Intent.


    This can lead to a variety of problems. At first, remote applications could send arbitrary Intents, meaning that your Google Talk friends had almost the same control of your device as you did. Even once that issue was resolved, we recognized that we could not trust the identity of the application who sent the request. We could only trust the identity of the user. So a "bad" application on your friend's device could send a message to a "good" application on your device which would negatively affect the good application.


    In the end, we determined that the Intent system, as designed for local use, did not lend itself well to being the vehicle for a Remote Procedure Call (RPC).

  3. Placing Too Much Security Burden on Developers


    As originally designed, the GTalkService placed a significant burden on the application developer to avoid security flaws and perform user and relationship management. An Android application using GTalkService would be reachable from all of the user's Google Talk friends, and a flaw in that application could pose an inviting target to a malicious "friend" or automated malware. There are automated mechanisms that could be used to help protect vulnerable applications or stop the spread of malware, but the deployment of these technologies was not possible in time for the launch of the first Android handsets.



Although we would have loved to ship this service, in the end, the Android team decided to pull the API instead of exposing users to risk and breaking compatibility with a future, more secure version of the feature. We think it's obvious that this kind of functionality would be incredibly useful, and would open lots of new doors for developers. One of our top priorities after the first devices ship is to develop a device-to-device (and possibly device-to-server) RPC mechanism that is fast, reliable, and protective of developers and users alike.


As a final note, I want to point out that since the GTalkService was always a Google "value-added" service anyway, it was never guaranteed that it would be present on every Android device. That is, GTalkService was never part of core Android. As a result this change actually allows us the potential to build a new system that is part of the core of a future version of Android.


Bluetooth API


The 1.0 version of Android and the first devices will include support for Bluetooth; for instance, Android will support Bluetooth headsets. In the early-look SDKs, there was an incomplete draft of an API that exposed Bluetooth functionality to developers. Unfortunately we had to remove that API from the 1.0 release. To get the skinny on why, I contacted Nick Pelly, one of the Android engineers responsible for that functionality. Here's the story on Bluetooth, in Nick's words:


The reason is that we plain ran out of time. The Android Bluetooth API was pretty far along, but needs some clean-up before we can commit to it for the SDK. Keep in mind that putting it in the 1.0 SDK would have locked us into that API for years to come.


Here's an example of the problems in the API. Client code is required to pass around IBluetoothDeviceCallback objects in order to receive asynchronous callbacks, but IBluetoothDeviceCallback is meant to be an internal interface. That client code would break the moment we added new callbacks to IBluetoothDeviceCallback.aidl. This is not a recipe for future-proof apps.


To make things even more tricky, the recent introduction of the bluez 4.x series brings its own new API. The Android Bluetooth stack uses bluez for GAP and SDP so you'll see more than a passing resemblance to bluez's interfaces in Android. The bluez 4.x change requires us to carefully consider how to structure our API for the future. Again, remember that once we settle on an interface we need to support it for years going forward.


Rather than ship a broken API that we knew was going to change a lot, we chose not to include it. We absolutely intend to support a Bluetooth API in a future release, although we don't know exactly when that will be. This should include some tasty features, such as:


  • Bindings to GAP and SDP functionality.

  • Access to RFCOMM and SCO sockets.

  • Potentially, L2CAP socket support from Java. (This one is under consideration.)

  • An API to our headset and handsfree profiles.

On a personal note, Nick adds, "I would love nothing more than to start seeing some neat third-party applications and games over Bluetooth. In my opinion, Bluetooth is completely under-utilized on most mobile platforms and I'm excited to someday see what the developer community can do with Android."


I'm definitely bummed about these API removals. I was particularly looking forward to the P2P capabilities offered by GTalkService, but, as always, user security and privacy must come first. In all these cases, we'll work with the developer community to create some great APIs that balance these concerns.

Monday, August 18, 2008

Announcing a beta release of the Android SDK

I'm pretty happy today, for two reasons. First, I'm happy because I get to let everyone know that we're releasing a beta SDK. You can read about the new Android 0.9 SDK beta at the Android Developers' Site, or if you want to get straight to the bits, you can visit the download page. Once you've got it, be sure to visit our Developer Forum if you have any questions.

Back in November, we made some SDK builds available that we referred to as "early look" SDKs. The goal was to give developers insight into the platform as early on as possible, and to get some initial feedback. Since then, we've been working with our Open Handset Alliance partners to incorporate much of that feedback, and finish the first devices. Since those devices are shipping in the fourth quarter, the platform is now converging on a final "Android 1.0" version.

The beta SDK that we're releasing today is the first big step on the SDK's road to compatibility with 1.0. Since this is a beta release, applications developed with it may not quite be compatible with devices running the final Android 1.0. However, the APIs are now pretty stable and we don't expect any major changes. If you're one of the many developers who were waiting for something a bit more mature, this might be a good time to take another look.

Since we're now moving quickly toward 1.0, it may also help to know which direction we're headed. To help out, we've also prepared a development roadmap. This will be a living document, and we'll keep it up to date as the Android landscape evolves. Currently it covers the next few months, roughly through the end of the year and a bit into next year. We'll update it with additional detail as we are able to, but even right now it can help give you a picture of how things will play out as the first phones draw near.

Enough of that though -- you're probably wondering what's actually new in the SDK. Well, you should read the Release Notes, the Change Overview and the API Delta Report for all the details, but here are a few highlights:

  • First and most obviously, the new Home screen is included, along with a ton of UI changes for 1.0.
  • Some new applications are included: an Alarm Clock, Calculator, Camera, Music player, Picture viewer, and Messaging (for SMS/MMS conversations.)
  • Several new development tools were added, such as a graphical preview for XML layouts for users of Eclipse, and a tool for constructing 9-patch images.
  • Since we've got a new Home screen application now, we thought the now-obsolete version from the M5 early-look SDK might be helpful to developers, so its source is included as a sample.
  • A number of new APIs are fleshed out and improved, and others are now close to their final forms for 1.0.
  • Tons of bugs were fixed, of course. (If you had problems with the MediaPlayer, try it now!)

There are a lot of changes -- the ones in the list above are just my personal favorites, so you should check out the links above for the full story. Not all the changes are additions, though: I'm sorry to say that we had to remove a few things, such as the GTalkService (for security reasons), and the Bluetooth API. There's a bit more detail in the links above, and we'll follow up on those in particular here in this blog to give you the scoop. In fact, we've got a little list of topics we want to talk about here, so stay tuned.

At the top of this post I said I was happy for two reasons, and now you know one of them -- but what about the other? Well, the second reason is because now that this is out I can finally go get some sleep!

Thursday, June 19, 2008

Android at Google I/O and Developer Days

It was great to connect with everyone at the Google I/O event in San Francisco and at our recent Developer Days across the globe. We enjoyed meeting all of the Android developers and answering your questions - both at our booth and at the fireside chats.

For those of you who were unable to attend, all of the sessions are available on video:

http://sites.google.com/site/io/

Enjoy!

Monday, May 19, 2008

AndroidGlobalTime

We are pleased to announce that a new open source sample application—called AndroidGlobalTime — has been added to the apps-for-android project.





It's a 3D world clock developed by an engineer at Google and may serve as an illustrative example of how to use the OpenGL ES APIs in your Android applications.



Just a quick word on how to use AndroidGlobalTime. When you launch it, you'll see a spinning globe showing day and night regions. Pressing the space bar will overlay an analog clock with the time corresponding to location you're currently examining. The arrow keys allow you to spin the Earth and traverse through different time-zones while the clock is displayed. Pressing the center key in the emulator toggles between a 3D and 2D view of the earth. Pressing the L key will turn the city lights on or off. You can also zoom-out by pressing 2 and zoom-in by pressing 8.

Hope you find this helpful!

Wednesday, May 14, 2008

Android Developer Challenge Judges and Top 50 Details

It's been a busy few weeks here as we've wrapped up the first round of the Android Developer Challenge. We'd like to share a couple pieces of information with you:

  • The full list of judges is now available. It was fun to work with such a diverse group of judges from different companies all around the world.
  • A slide deck of the Android Developer Challenge prize recipients is also available. The deck includes descriptions and screenshots of the 46 recipients who consented to sharing their information and is a great way to get a feel for the quality of apps submitted.

The prize recipients' entries were just the tip of the iceberg in terms of great applications submitted, and we'd like to thank and congratulate everyone who entered the challenge. We look forward to seeing all of the application in the hands of consumers with Android devices.

Tuesday, May 13, 2008

A Challenge in More than One Way

Well, the submission deadline for the first Android Developer Challenge has come and gone, the apps are in, the judges are finished, and the waiting is over. We got a lot of great submissions, and I can tell you personally that the competition was fierce. I didn't see all 1,788 submissions, but I saw quite a lot of them, and I uttered more than one wail of despair as some of my favorite submissions didn't quite make the cut, by razor-thin margins in some cases. But, the judges have spoken.


Speaking of the judges...we'll soon publish a list of who the judges are, but I know many of our developers are still curious: what were all those judges doing? Well, the short answer is that they were judging applications using a custom laptop configuration that we provided. But we thought some people might be interested in the "long" answer, so we put together this blog post. If you're not interested in the gory details of the judging, you can stop here; but if you are interested, read on!


How We Got Started


Making the Challenge fair was by far our primary goal. We knew we had to do whatever we could to make sure that the judges' scores are based solely on their review of the application. We automated as much as possible, to make it easy for judges to focus on judging, and not on administrivia or complicated setup.


The first thing we realized was that we were going to have way more submissions than any single judge could look at. No one could review all 1,788 submissions in a reasonable amount of time. On the other hand, we definitely needed more than one judge reviewing each submission. Our goal was to have each submission reviewed by four different judges, with a minimum of three.


The big question was then: how many judges would we need?


For 1,788 submissions, a panel of 4 judges per application meant that we needed a whopping 7,152 reviews to be performed. Since our judges would have to be crazy to agree to do more than 75 reviews, we needed at least 95 judges. In the end we recruited around 125, including backup judges.


Making Order out of Chaos


The next thing we realized was that judges need to be able to actually review the submissions. Since the judges came from our Open Handset Alliance partners and many are not engineers, we knew that we couldn't send instructions like "run the M5-RC15 emulator, open a terminal window, and run the command adb push geodb /data/misc/location—and don't forget the --sdcard option!" They'd think we were quoting Star Wars.


Besides that, we also knew that once we gave the judges their assignments, what they did was out of our hands. We couldn't control how the judges review the applications, but we could certainly make it as easy as possible for the judges to do a thorough review.


So, we built a program in wxPython that automates judging. This application launches a clean emulator for each submission, supports emulator features like SD card images and mock location providers, and allows judges to launch multiple emulators and simulate calls and SMS messages for applications which need that functionality. We asked our friendly neighborhood Google Tech Stop for 140 laptops, installed Ubuntu Linux and our software on one, and then cloned that installation for use on all the others. We then had a huge shipping party, where we imaged, boxed, and shipped 115 or so laptops in one day.


An important side effect of these custom laptops is that they are all identical. This means that each judge's experience of the submissions was the same, which eliminated the risk of one judge rating an app poorly just because it ran slowly on his personal computer.


Managing All that Data


Once we sent 100+ laptops all over the world, we needed a way to get the data back. Another goal was to eliminate as many sources of human error as possible. With 7,152 reviews to complete, and 4 categories per review, that's 28,608 scores to keep track of. Mistakes would be bound to happen, so filing paperwork or transcribing scores by hand from one file to another was out of the question.


Our solution was the Google Data web API for accessing things like Google Spreadsheets and Google Base. Here's how it worked.


  • We wrote a Python program to randomly assign applications to judges for review.
  • Using the Spreadsheets API, that program generated a Google Spreadsheet for each judge, pre-filled with that judge's assigned submissions and space to enter scores.
  • The program installed on the laptops also used the Spreadsheets API to fetch a given judge's assignments.
  • When the judge scores a submission, those scores were posted back into the spreadsheet.
  • After the judging period concluded, a separate program walks over all the judges' spreadsheets, computing the final scores.

This approach had two great things about it: first, it didn't require any new server infrastructure to make it work. Second, our "database" had a built-in rich "admin" UI for managing the data — namely, Google Spreadsheets itself. If any of our judges ran into problems or needed help, we could simply open that spreadsheet in our browser and review or fix problems.


This approach worked quite well, and I'd bet that the judges didn't even know the Spreadsheets API was being used, unless they actively poked around.


Tying Up the Loose Ends


Of course, our work wasn't done once we retrieved all the submission scores. We couldn't just average up the scores, you see. First, judges could recuse themselves from scoring specific submissions; perhaps they were assigned an application similar to one their own company is working on, or perhaps they realized they knew one of the authors. Second, despite our best efforts there was a chance that some judges might have a problem — for instance, if one judge had a poor network connection but reviewed an application that requires the network, then that judge might have scored the application unfairly poorly.


Here are the major outlier scenarios that we were concerned about:

  • Cases where judges recused themselves.
  • Submissions where one judge reported a problem with the application, but all the other judges reported good scores. (It seems odd for only one judge to have a problem.)
  • Cases where one judge's scores were an outlier compared to the other judges' scores.

For the first two cases, we simply discarded the outlying data points, if we had enough. For instance, if three judges reported good scores and one recused herself, we simply dropped that fourth score. If dropping the conflicting score would have brought the application below three reviews, we sent it back for review by a new judge to bring it up to our minimum number of judges per application.


The third case is more subtle. Just because a judge rated an application differently than others doesn't mean that that review is invalid, so we can't simply discard outliers. Instead, we took the highest and lowest scores in each category and gave them half weight. The effect is to bring the average scores a bit closer to the median scores, which helps minimize the impact of unusually high or low scores. This process was applied to all submissions (not just "suspicious" scores) since it has a minimal effect on submissions that don't have a large outlier.


We actually ran the whole process above twice: first we ran it to choose a first cut of the top 100 submissions from the original 1,788, and we then sent those 100 to a second group of judges for selection of the final 50. (Actually, the "top 100" were really "top 119", since we added a few more submissions to accommodate scoring ties in the first round.)


Wrapping Up


Now you know what we've been spending all our time on, and what's been keeping us up at night (sometimes literally)! Throughout, our key objectives were to keep the process fair, let the judges focus on judging, and give applications the benefit of the doubt in cases of scoring outliers.


What's next? Well, the 50 submissions that were awarded a prize now begin the refinement process for their Round 2 submissions, which will award the final, larger prizes to the top 20 applications. I also hope that the developers of the other great apps that didn't receive prizes will consider the second Android Developer Challenge, which should begin later this year.


To everyone, I'd also like to say thanks for participating, and congratulations on your hard work!

Monday, May 12, 2008

The Top 50 Applications

As you may have heard, the results from Android Developer Challenge Part 1, Round 1 were announced to all the participants late last week. We're still working on pulling together a more extensive listing for each application that made it into the top 50, but in the spirit of releasing early and often, here's a list containing the name of the application and its author(s):

  • AndroidScan - Jeffrey Sharkey

  • Beetaun - Sergey Gritsyuk and Dmitri Shipilov

  • BioWallet - Jose Luis Huertas Fernandez

  • BreadCrumbz - Amos Yoffe

  • CallACab - Konrad Huebner and Henning Boeger

  • City Slikkers - PoroCity Media and Virtual Logic Systems

  • Commandro - Alex Pisarev, Andrey Tapekha

  • Cooking Capsules - Mary Ann Cotter and Muthuselvam Ramadoss

  • Diggin - Daniel Johansson, Aramis Waernbaum, Andreas Hedin

  • Dyno - Virachat Boondharigaputra

  • e-ventr - Michael Zitzelsberger

  • Eco2go - Taneem Talukdar, Gary Pong, Jeff Kao and Robert Lam

  • Em-Radar - Jack Kwok

  • fingerprint - Robert Mickle

  • FreeFamilyWatch - Navee Technologies LLC

  • goCart - Rylan Barnes

  • GolfPlay - Inizziativa Networks

  • gWalk - Prof. Dr.-Ing. Klaus ten Hagen, Christian Klinger, Marko Modsching, Rene Scholze

  • HandWx - Weathertop Consulting LLC

  • IMEasy - Yan Shi

  • Jigsaw - Mikhail Ksenzov

  • JOYity - Zelfi AG

  • LifeAware - Gregory Moore, Aaron L. Obrien, Jawad Akhtar

  • Locale - Clare Bayley, Christina Wright, Jasper Lin, Carter Jernigan

  • LReady Emergency Manager - Chris Hulls, Dilpreet Singh, Luis Carvalho, Phuong Nguyen

  • Marvin - Pontier Laurent

  • Mobeedo - Sengaro GmbH

  • Multiple Facets Instant Messenger - Virgil Dobjanschi

  • MyCloset - Mamoru Tokashiki

  • PedNav - RouteMe2 Technologies Inc.

  • Phonebook 2.0 - Voxmobili

  • PicSay - Eric Wijngaard

  • PiggyBack - Christophe Petit and Sebastien Petit

  • Pocket Journey - Anthony Stevens and Rosie Pongracz

  • Rayfarla - Stephen Oldmeadow

  • Safety Net - Michael DeJadon

  • SocialMonster - Ben Siu-Lung Hui and Tommy Ng

  • SplashPlay

  • Sustain- Keeping Your Social Network Alive - Niraj Swami

  • SynchroSpot - Shaun Terry

  • Talkplay - Sung Suh Park

  • Teradesk - José Augusto Athayde Ferrarini

  • The Weather Channel for Android - The Weather Channel Interactive Inc.

  • TuneWiki - TuneWiki Inc.

  • Wikitude-the Mobile Travel Guide - Philipp Breuss

  • Writing Pad - ShapeWriter Inc

Those of you following along carefully at home (or who bothered to read this far) will notice that there's only 46 in this list. 4 winners opted to continue their efforts in secret and so while we congratulate them too, we can't list them here.

Regardless, congratulations to all those who made it this far!

Friday, May 9, 2008

Android Developer Challenge: Round I Results are In

The last few weeks were both extremely intense and rewarding. Based on feedback from the judges, it was apparent that large number of applications were compelling, innovative and well implemented. The quality of these entries clearly reflects the creativity and hard work that developers have invested in building their apps.

In addition to developers' participation and contributions, over 100 industry judges around the world spent weeks reviewing these submissions. I want to thank all the developers and judges who have worked incredibly hard over the last few months, making the Android Developer Challenge such a success.

Many of the top submissions took advantage of the geo and social networking capabilities of Android. These applications allow friends to share their personal experiences and favorite content such as vacations, photos, shows, music, cooking recipes, restaurants, and much more as they relate to certain locales. I've also seen applications that connect people during emergency situations and others that allow users to share information on how they can reduce their carbon footprint. One developer even turned a real city block into a playing field where gamers can role-play and chase after villains.

Furthermore, some of these applications provide rich interactive experiences by combining web services and mash-ups to bring together data that's on the web with data that's on the mobile device. One application combined weather, pollen and allergy information in the context of a map that is relevant to a user's location.

Though many applications use a traditional "download" model for data, many also enable users to publish content, such as photos or even voice memos, for others to use on other mobile devices or the web.

This is just a brief snapshot of the many impressive applications I've seen. The 50 highest scoring applications will receive $25,000 each and go on to compete in the final round. We plan to publish a list of these applications as soon as we receive the developers' consent. The real winners, however, are the consumers who will benefit from the work of these talented developers.

Thursday, April 17, 2008

Android Developers Have Risen to the Challenge

I'm thrilled to share the news that developers from over 70 countries submitted 1,788 entries to the Android Developer Challenge!

Here are a few facts that I thought were interesting. When we announced the Android Developer Challenge back in January, developers started submitting entries right away but it wasn't until the April 14 deadline approached that the flood really began. The rate of submissions spiked in the wee hours of Tuesday morning, reaching as high as 170+ submissions per hour.

What I find truly amazing is how global the interest in the challenge has been. Developers from the United States submitted one-third of the total applications while the rest came from countries such as Germany, Japan, China, India, Canada, France, UK, and many others. The entries are also very diverse representing many application areas, from games to social-networking applications, to utilities, to productivity and developer tools, and many more. On behalf of the Open Handset Alliance, I want to thank everyone who has submitted entries to the challenge. We look forward to reviewing all of them.

Now that the applications are in, over 100 judges will soon receive judging packets and laptops that we've preloaded with all the submissions, for a consistent, fair environment to judge the submissions. The majority of the judges are from member companies of the Open Handset Alliance, in addition to non-alliance mobile industry experts who have all graciously volunteered their time. I'd like to thank these judges too for all the time they will be putting into this.

In May, we'll be informing the 50 Semi-finalists who will be awarded $25,000 each. Until then, the team and I will have our hands full.

Monday, April 7, 2008

Android Developer Challenge Judges

We have received a few inquiries regarding the judges who will be evaluating entries to the Android Developer Challenge (ADC). All Entries will be judged by a panel of experts in the fields of mobile devices, cellular telecommunications, software development, and/or technology innovation ("Judges"). Google will select the Judges from the member organizations of the Open Handset Alliance, Google and/or mobile experts.

As a reminder, the deadline for the Android Developer Challenge is April 14, 2008. We're really looking forward to seeing what you've created so make sure you submit in time. Good luck!

Friday, April 4, 2008

Android University

Spring is on the way, and temperatures are rising. We're no exception, and things are starting to heat up over here in Android-land, too.


The Android Developer Challenge deadline is approaching quickly. Wow, that's strange to me. On one hand, we've come so far that the first announcement back on November 12 seems like a prior geologic era, but on the other hand it seems like the Challenge just started! But it's been five months, so it's time to finish your code, polish your UI, and submit your application. Remember to submit by midnight on April 14th, PST (GMT-8).


But after the Challenge, what's next? Well, on the 28th and 29th of May we have Google I/O. This is the biggest Google developer event of the year, and you can bet that the Androids will be there in numbers.


Here are the sessions we've prepared on Android.

  • Android 101: Building an Application
  • Anatomy & Physiology of an Android
  • Dalvik Internals
  • Inside the Android Application Framework
  • Building Great UIs with Android
  • Internationalizing Android Applications
  • Location, Location, Location
  • Mobile Mashups
For more details on these sessions, visit the Google I/O site. Please do, in fact—I'm really excited by some of these because we're going to go into a level of detail that we haven't before. Ever wanted to hear the tech lead on Dalvik talk about Dalvik? Ever wanted an exhaustive review of the i18n/resource system? Then don't miss this event.


Besides the technical sessions, there will be a Fireside Chat with as many members of the Android team as we can rustle up, and an Android section in the demo and coding area. (Personally, I'm looking forward to that the most: it's shaping up to be a code festival of mammoth proportions.) If you need a break from Android, there are also tons of sessions on other developer technologies from Google, too.


We intend this to be the premier developer event for Android, this year. If you only go to one Android event, we humbly suggest that you consider this one. Early-bird registration ends TODAY (April 4th), so be sure to sign up soon.


I'll see you there!

Thursday, April 3, 2008

Android's First 5 Months

Originally by Sung Hu Kim, Product Marketing Manager for Android, Google mobile team


As some of you may have heard, Wireless Week has chosen the Open Handset Alliance and Android for its Emerging Technology Award, noting that "Android's potential promises openness and innovation, perhaps changing not only the mobile Internet but the Internet itself."


We at Google would like to congratulate all the members of the Open Handset Alliance and the fantastic Android developer community for this well deserved recognition. Android's growing momentum is the result of an amazing effort and collaboration among many different people.

Coincidentally, this week marks five months since the Open Handset Alliance and Android first went public. A lot has happened in this short period of time. Among the things of note:
  • We released an early look at the Android software development kit (SDK), allowing anyone to learn and start creating apps for the platform.
  • Feedback from developers has contributed to numerous fixes, improvements, new tools, and major updates to the SDK, the latest version of which you can find here.
  • Google announced the Android Developer Challenge, which will provide $10 million in total awards for the best Android apps—and the first phase has nearly wrapped up. (Be sure to get your submissions in by April 14!)
  • Several companies gave the first working demonstrations of Android in February.

These have been an exciting first 5 months, and we look forward to making the coming months even better.

Wednesday, March 19, 2008

WikiNotes for Android: Routing Intents

In the last article, we talked about using Linkify to turn wiki words (those that match a regular expression we defined) into a content: URI and defining a path to data that matched a note belonging to that wiki word. As an example, a matching word like ToDoList would be turned into a content: URI like content://com.google.android.wikinotes.db.wikinotes/wikinotes/ToDoList and then acted upon using the VIEW action from the Linkify class.



This article will examine how the Android operating system takes this combination of VIEW action and content: URI and finds the correct activity to fire in order to do something with the data. It will also explain how the other default links created by Linkify, like web URLs and telephone numbers, also result in the correct activity to handle that data type being fired. Finally, this article will start to examine the custom ContentProvider that has been created to handle WikiNotes data. The full description of the ContentProvider and what it does will span a couple more articles as well, because there is a lot to cover.



The Linkify-calls-intent Workflow


At a high level, the steps for Linkify to invoke an intent and for the resulting activity (if any) to handle it looks like this:




  1. Linkify is invoked on a TextView to turn matching text patterns into Intent links.

  2. Linkify takes over monitoring for those Intent links being selected by the user.

  3. When the user selects a link, Linkify calls the VIEW action using the content: URI associated with the link.

  4. Android takes the content: URI that represents the data, and looks for a ContentProvider registered in the system that matches the URI.

  5. If a match is found, Android queries the ContentProvider using the URI, and asks what MIME type the data that will be returned from the URI is.

  6. Android then looks for an activity registered in the system with an intent-filter that matches both the VIEW action, and the MIME type for the data represented by the content: URI.

  7. Assuming a match is found, Linkify then invokes the intent for the URI, at which point the activity takes over, and is handed the content: URI.

  8. The activity can then use the URI to retrieve the data and act on it.



If this sounds complicated, it really is a simpler process than it sounds, and it is quite lightweight as well. Perhaps a more understandable statement about how it works might be:



Linkify is used to turn matching text into hot-links. When the user selects a hot-link, Android takes the data locator represented by the hot-link and looks for a data handler for that data locator. If it finds one, it asks for what type of data is returned for that locator. It then looks for something registered with the system that handles that type of data for the VIEW action, and starts it, including the data locator in the request.



The real key here is the MIME type. MIME stands for Multipurpose Internet Mail Extensions - a standard for sending attachments over email. The MIME type (which is the part Android uses) is a way of describing certain kinds of data. That type is then used to look for an Activity that can do something with that data type. In this way, ContentProviders and Activities (or other IntentReceivers) are decoupled, meaning that a given Content URI might have a different ContentProvider to handle it, but could still use the same MIME type meaning that the same activity could be called upon to handle the resulting data.



Linkify on a Wiki Word



Using the above workflow, let's take a look at exactly how the process works in WikiNotes for Android:



First, Linkify is used to turn text matching the wiki word regular expression into a link that provides a Content URI for that wiki word, for example content://com.google.android.wikinotes.db.wikinotes/wikinotes/ToDoList.



When the user clicks on the wiki word link, Linkify invokes the VIEW action on the Content URI. At this point, the Android system takes over getting the Intent request to the correct activity.



Next, Android looks for a ContentProvider that has been registered with the system to handle URIs matching our Content URI format.



In our case, we have a definition inside our application in the AndroidManifest.xml file that reads:



<provider name="com.google.android.wikinotes.db.WikiNotesProvider" 
android:authorities="com.google.android.wikinotes.db.wikinotes" />


This establishes that we have a ContentProvider defined in our application that provides the "root authority": com.google.android.wikinotes.db.wikinotes. This is the first part of the Content URI that we create for a wiki word link. Root Authority is just another way of thinking about a descriptor that is registered with Android to allow requests for certain URLs to be routed to the correct class.



So, the whole definition is that a class called com.google.android.wikinotes.db.WikiNotesProvider is registered with the system as able to handle the com.google.android.wikinotes.db.wikinotes root authority (i.e. URIs starting with that identifier).



From here, Android takes the rest of the URI and present it to that ContentProvider. If you look at the WikiNotesProvider class and scroll to the very bottom - the static block there, you can see the pattern definitions to match the rest of the URL.



In particular, take a look at the two lines:



URI_MATCHER.addURI(WikiNote.WIKINOTES_AUTHORITY, "wikinotes", NOTES);
URI_MATCHER.addURI(WikiNote.WIKINOTES_AUTHORITY, "wikinotes/*", NOTE_NAME);


These are the definitions of URIs that our ContentProvider recognizes and can handle. The first recognizes a full URI of content://com.google.android.wikinotes.db.wikinotes/wikinotes and associates that with a constant called NOTES. This is used elsewhere in the ContentProvider to provide a list of all of the wiki notes in the database when the URI is requested.



The second line uses a wildcard - '*' - to match a request of the form that Linkify will create, e.g. content://com.google.android.wikinotes.db.wikinotes/wikinotes/ToDoList. In this example, the * matches the ToDoList part of the URI and is available to the handler of the request, so that it can fish out the matching note for ToDoList and return it as the data. This also associates that match with a constant called NOTE_NAME, which again is used as an identifier elsewhere in the ContentProvider.



The other matches in this static block are related to forms of searching that have been implemented in the WikiNotes for Android application, and will be covered in later articles. Likewise, how the data is obtained from this matching pattern will be the subject of the next article.



For right now we are concerned with the MIME type for the URI. This is defined in the getType() method also in the WikiNotesProvider class (about half way through the file). Take a quick look at this. The key parts for now are:



case NOTES:
return "vnd.android.cursor.dir/vnd.google.wikinote";


and

case NOTE_NAME:
return "vnd.android.cursor.item/vnd.google.wikinote";


These are the same constant names we defined in our pattern matchers. In the first case, that of the all notes URI, the MIME type returned is vnd.android.cursor.dir/vnd.google.wikinote which is like saying an Android list (dir) of Google wiki notes (the vnd bit is MIME speak for "vendor specific definition"). Likewise, in the case of a NOTE_NAME match, the MIME type returned is vnd.android.cursor.item/vnd.google.wikinote which is like saying an Android item of Google wiki notes.



Note that if you define your own MIME data types like this, the vnd.android.cursor.dir and vnd.android.cursor.item categories should be retained, since they have meaning to the Android system, but the actual item types should be changed to reflect your particular data type.



So far Android has been able to find a ContentProvider that handles the Content URI supplied by the Linkify Intent call, and has queried the ContentProvider to find out the MIME types for that URI. The final step is to find an activity that can handle the VIEW action for that MIME type. Take a look in the the AndroidManifest.xml file again. Inside the WikiNotes activity definition, you will see:



<intent-filter>
<action name="android.intent.action.VIEW"/>
<category name="android.intent.category.DEFAULT"/>
<category name="android.intent.category.BROWSABLE"/>
<data mimetype="vnd.android.cursor.item/vnd.google.wikinote"/>
</intent-filter>


This is the correct combination of matches for the VIEW action on a WikiNote type that is requested from the LINKIFY class. The DEFAULT category indicates that the WikiNotes activity should be treated as a default handler (a primary choice) for this kind of data, and the BROWSABLE category means it can be invoked from a "browser", in this case the marked-up Linkified text.



Using this information, Android can match up the VIEW action request for the WikiNotes data type with the WikiNotes activity, and can then use the WikiNotes activity to handle the request.



Why do it like this?



It's quite a trip through the system, and there is a lot to absorb here, but this is one of the main reasons I wanted to write WikiNotes in the first place. If you follow and understand the steps here, you'll have a good grasp of the whole Intents mechanism in Android, and how it helps loosely coupled activities cooperate to get things done.



In this case, we could have found another way to detect wiki words based on a regular expression, and maybe written our own handler to intercept clicks within the TextView and dig out the right data and display it. This would seem to accomplish the same functionality just as easily as using intents, so what is the advantage to using the full Intents mechanism?



In fact there are several advantages:



The most obvious is that because we are using the standard Intent based approach, we are not limited to just linking and navigating to other wiki notes. We get similar behavior to a number of other data types as well. For example, a telephone number or web URL in a wiki note will be marked up by Linkify, and using this same mechanism (VIEW action on the linked data type) the browser or dialer activities will be automatically fired.



It also means that each operation on a wiki note can be treated as a separate life cycle by our activity. We are not dealing with swapping data in and out of an existing activity - each activity works on a particular wiki note and that's all you have to worry about.



Another advantage is that we now have a public activity to handle VIEW actions in WikiNotes no matter where the request comes from. Another application could request to view a wiki note (perhaps without even knowing what kind of data it is) and our activity could start up and handle it.



The backstack is automatically maintained for you too. As you forward navigate through WikiNotes, Android maintains the history of notes visited, and so when you hit the back button you go back to the last note you were on. All this is free because we rely on the Android intents mechanism.



Finally, if you run WikiNotes for Android and then start DDMS to take a look at the Activity threads in the WikiNotes application while it is running, you can see that despite what you might think, letting Android manage the navigation is very efficient. Create a few linked notes, as many links deep as you like, and then follow them. If you follow links hundreds of notes deep, you will still only see a handful of WikiNotes activities. Android is managing the activities, closing the older ones as necessary and using the life cycle to swap data in and out.



Next Time



This was a long article, but necessarily so. It demonstrates the importance of the Intents mechanism and to reinforce the notion that it should be used whenever possible for forward navigation, even within a single application. Illustrating this is one of the primary reasons I wrote WikiNotes for Android in the first place.



In the next article we will look deeper into the ContentProvider and examine how it turns a Content URI into a row (or several rows) of data that can be used by an activity.

Thursday, March 13, 2008

Linkify your Text!

This is the first in a series of technical articles about WikiNotes for Android, part of the Apps for Android project.



This article covers the use of Linkify to turn ordinary text views into richer link-oriented content that causes Android intents to fire when a link is selected.



Linkify: The Linkify class in the SDK is perfect for creating a wiki note pad. This class lets you specify a regular expression to match, and a scheme to prepend. The scheme is a string that, when the matched text is added, forms a Content URI to allow the correct data to be looked up.



For example, in our case we want to look for a regular expression match for a WikiWord (that is, a word with camel case and no spaces). Linkify can then turn this into a Content URI - something like >content://com.google.android.wikinotes.db.wikinotes/wikinotes/WikiWord which can then be used to locate the correct wiki page from a content provider.



As a bonus, the Linkify class also defines several default matches, in particular it is able to turn web URLs, email addresses and telephone numbers into active links which fire Android intents automatically.



Linkify can be passed any TextView in your application, and will take care of creating the links and enabling their "clickability" for you.



Default Linkify: Using the set of default active link options is very straightforward - simply pass it a handle to a TextView with content in it, and the Linkify.ALL flag:



TextView noteView = (TextView) findViewById(R.id.noteview);
noteView.setText(someContent);
Linkify.addLinks(noteView, Linkify.ALL);


and that's it. The Linkify.ALL flag applies all of the predefined link actions, and the TextView will be immediately updated with a set of active links which, if you select them, fire default intents for the actions (e.g. a web URL will start the browser with that URL, a telephone number will bring up the phone dialer with that number ready to call, etc.).



Custom Linkify: So what about our WikiWord? There is no pre-defined action for that, so it needs to be defined and associated with a scheme.



The first task is to defined a regular expression that matches the kind of WikiWords we want to find. The regex in this case is:



\b[A-Z]+[a-z0-9]+[A-Z][A-Za-z0-9]+\b


Obvious no? Well actually this is equivalent to the following description: "Starting with a word boundary (the \b) find at least one upper case letter, followed by at least one lower case letter or a numeric digit, followed by another upper case letter, and then any mix of upper case, lower case or numeric until the next word boundary (the final \b)". Regular expressions are not very pretty, but they are an extremely concise and accurate way of specifying a search pattern.



We also need to tell Linkify what to do with a match to the WikiWord. Linkify will automatically append whatever is matched to a scheme that is supplied to it, so for the sake of argument let's assume we have a ContentProvider that matches the following content URI:



content://com.google.android.wikinotes.db.wikinotes/wikinotes/WikiWord


The WikiWord part will be appended by Linkify when it finds a match, so we just need the part before that as our scheme.



Now that we have these two things, we use Linkify to connect them up:



Pattern wikiWordMatcher = Pattern.compile("\\b[A-Z]+[a-z0-9]+[A-Z][A-Za-z0-9]+\\b");
String wikiViewURL = "content://com.google.android.wikinotes.db.wikinotes/wikinotes/";
Linkify.addLinks(noteView, wikiWordMatcher, wikiViewURL);


Note that the \b's had to be escaped with double backslashes for the Java Pattern.compile line.



Linkify can be used multiple times on the same view to add more links, so using this after the Default Linkify call means that the existing active links will be maintained and the new WikiWords will be added. You could define more Linkify actions and keep applying them to the same TextView if you wanted to.



Now, if we have a WikiWord in the TextView, let's say MyToDoList, Linkify will turn it into an active link with the content URI:



content://com.google.android.wikinotes.db.wikinotes/wikinotes/MyToDoList


and if you click on it, Android will fire the default intent for that content URI.



For this to all work, you will need a ContentProvider that understands that Content URI, and you will need a default activity capable of doing something with the resulting data. I plan to cover these in future blog entries (and soon). In fact, the whole Wiki Note Pad application is currently undergoing some clean up and review, and will then hopefully be released as a sample application.