The Android | What is Android | Androids | Android Market | App for Android | Android Apps | Android Application | Download Android | Tablet Android | Tablet PC | Phone Android | Android 2.2 | Android 2.3 | Android Free | Games for Android | Android Samsung | Galaxy Android | Android Google | Games Android | アンドロイド | Android | Android 2 | Android PC | Google Android | Android Galaxy | Phones with Android | Which Android Phone | What is an Android Tablet | What is an Android Phone
Announcing Google Maps Navigation for Android 2.0
Since 2005, millions of people have relied on Google Maps for mobile to get directions on the go. However, there's always been one problem: Once you're behind the wheel, a list of driving directions just isn't that easy to use. It doesn't tell you when your turn is coming up. And if you miss a turn? Forget it, you're on your own.
Today we're excited to announce the next step for Google Maps for mobile: Google Maps Navigation (Beta) for Android 2.0 devices.
This new feature comes with everything you'd expect to find in a GPS navigation system, like 3D views, turn-by-turn voice guidance and automatic rerouting. But unlike most navigation systems, Google Maps Navigation was built from the ground up to take advantage of your phone's Internet connection.
Here are seven features that are possible because Google Maps Navigation is connected to the Internet:
The most recent map and business data
When you use Google Maps Navigation, your phone automatically gets the most up-to-date maps and business listings from Google Maps — you never need to buy map upgrades or update your device. And this data is continuously improving, thanks to users who report maps issues and businesses who activate their listings with Google Local Business Center.
Search in plain English
Google Maps Navigation brings the speed, power and simplicity of Google search to your car. If you don't know the address you're looking for, don't worry. Simply enter the name of a business, a landmark or just about anything into the search box, and Google will find it for you. Then press "Navigate", and you're on your way.
Search by voice
Typing on a phone can be difficult, especially in the car, so with Google Maps Navigation, you can say your destination instead. Hold down the search button to activate voice search, then tell your phone what you want to do (like "Navigate to Pike Place in Seattle"), and navigation will start automatically.
Traffic view
Google Maps Navigation gets live traffic data over the Internet. A traffic indicator light in the corner of the screen glows green, yellow or red, depending on the current traffic conditions along your route. If there's a jam ahead of you, you'll know. To get more details, tap the light to zoom out to an aerial view showing traffic speeds and incidents ahead. And if the traffic doesn't look good, you can choose an alternate route.
Search along route
For those times when you're already on the road and need to find a business, Google Maps Navigation searches along your route to give you results that won't take you far from your path. You can search for a specific business by name or by type, or you can turn on popular layers, such as gas stations, restaurants or parking.
Satellite view
Google Maps Navigation uses the same satellite imagery as Google Maps on the desktop to help you get to your destination. Turn on the satellite layer for a high-resolution, 3D view of your upcoming route. Besides looking cool, satellite view can help you make sense of complicated maneuvers.
Street View
If you want to know what your next turn looks like, double-tap the map to zoom into Street View, which shows the turn as you'll see it, with your route overlaid. And since locating an address can sometimes be tricky, we'll show you a picture of your destination as you approach the end of your route, so you'll know exactly what to look for.
Since there's nothing quite like seeing the product in action, we made this video to demonstrate a real-life example:
The first phone to have Google Maps Navigation and Android 2.0 is the Droid from Verizon. Google Maps Navigation is initially available in the United States. And like other Google Maps features, Navigation is free.
Click here to learn more and browse a gallery of product screenshots. Take Google Maps Navigation for a spin, and bring Internet-connected GPS navigation with you in your car.
Announcing Android 2.0 support in the SDK!
I am excited to announce that the Android SDK now supports Android 2.0 (also known as Eclair).
Android 2.0 brings new developer APIs for sync, Bluetooth, and a few other areas. Using the new sync, account manager and contacts APIs, you can write applications to enable users to sync their devices to various contact sources. You can also give users a faster way to communicate with others by embedding Quick Contact within your application. With the new Bluetooth API, you can now easily add peer-to-peer connectivity or gaming to your applications. To get a more complete list of the new capabilities you can add to your applications, please go to the Android 2.0 highlights page.
Current developers can use the SDK Manager to add Android 2.0 support to their SDK as well as update their SDK Tools to revision 3. New developers can download the Android SDK from the download site. After the download, Android platforms must be added using the SDK Manager
The SDK Manager allows you to add new Android platforms to your SDK.
Android SDK Tools, revision 3 is required to develop for Android 2.0. It includes support for code coverage through the Ant build system, as well as Mac OS X 10.6 (Snow Leopard) support for the SDK and related tools. For those of you who develop using Eclipse, we are releasing ADT version 0.9.4 through the usual Eclipse update mechanism.
Over the next few months, we expect to see more and more Android devices being released. These devices will be running Android 1.5, 1.6, or 2.0. We are also planning a minor version update of Android 2.0 towards the end of the year, and that will be the last update for 2009. Below are some of the things you can do to be better prepared:
Download the Android 2.0 platform and make sure your existing apps continue to work on new devices running Android 2.0.
Make sure that your apps work when using the WVGA (800x480) & FWVGA (854x480) emulator skins. We expect devices with these types of screen, running Android 2.0 to be launched soon.
Checkout the video below for more information about Android 2.0.
The Iterative Web App: Auto-expanding Compose Boxes
When composing a message on my phone, I really want to see as much of my draft as possible and make use of all the available screen space. One of my biggest gripes is a fixed-size compose box that restricts me to only a couple lines of visible text when my screen still has room to display more lines.
Today we launched auto-expanding compose boxes in Gmail for iPhone. This makes composing longer messages much easier since you're able to see more of the text you've typed. Just keep typing until you get near the bottom and then the compose box will magically expand by a few lines! As an added bonus, for all those iPhone users out there, auto-expanding compose boxes take away the need to press and hold to scroll with the magnifying glass! Instead, you can flick to scroll, much like you would normally do to scroll up and down a webpage. (On Android-powered devices, this hasn't been much of a problem, thanks to the trackball.)
While we're on the subject of making it easier to view content in Gmail, one more bit of news. We've been working on ways to make inline images show up in your messages, and you can now get some of those images to display by following these steps.
To try out, visit gmail.com on your iPhone/iPod touch (OS 2.2.1 or above, US English only) and create a home screen link for easy access.
by Casey Ho, Software Engineer, Google Mobile
UI framework changes in Android 1.6
Android 1.6 introduces numerous enhancements and bug fixes in the UI framework. Today, I'd like to highlight three two improvements in particular.
Optimized drawing
The UI toolkit introduced in Android 1.6 is aware of which views are opaque and can use this information to avoid drawing views that the user will not be able to see. Before Android 1.6, the UI toolkit would sometimes perform unnecessary operations by drawing a window background when it was obscured by a full-screen opaque view. A workaround was available to avoid this, but the technique was limited and required work on your part. With Android 1.6, the UI toolkit determines whether a view is opaque by simply querying the opacity of the background drawable. If you know that your view is going to be opaque but that information does not depend on the background drawable, you can simply override the method called isOpaque():
@Override
public boolean isOpaque() {
return true;
}
The value returned by isOpaque() does not have to be constant and can change at any time. For instance, the implementation of ListView in Android 1.6 indicates that a list is opaque only when the user is scrolling it.
Updated: Our apologies—we spoke to soon about isOpaque(). It will be available in a future update to the Android platform.
More flexible, more robust RelativeLayout
RelativeLayout is the most versatile layout offered by the Android UI toolkit and can be successfully used to reduce the number of views created by your applications. This layout used to suffer from various bugs and limitations, sometimes making it difficult to use without having some knowledge of its implementation. To make your life easier, Android 1.6 comes with a revamped RelativeLayout. This new implementation not only fixes all known bugs in RelativeLayout (let us know when you find new ones) but also addresses its major limitation: the fact that views had to be declared in a particular order. Consider the following XML layout:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="64dip"
android:padding="6dip">
<TextView
android:id="@+id/band"
android:layout_width="fill_parent"
android:layout_height="26dip"
android:layout_below="@+id/track"
android:layout_alignLeft="@id/track"
android:layout_alignParentBottom="true"
android:gravity="top"
android:text="The Airborne Toxic Event" />
<TextView
android:id="@id/track"
android:layout_marginLeft="6dip"
android:layout_width="fill_parent"
android:layout_height="26dip"
android:layout_toRightOf="@+id/artwork"
android:textAppearance="?android:attr/textAppearanceMedium"
android:gravity="bottom"
android:text="Sometime Around Midnight" />
<ImageView
android:id="@id/artwork"
android:layout_width="56dip"
android:layout_height="56dip"
android:layout_gravity="center_vertical"
android:src="@drawable/artwork" />
</RelativeLayout>
This code builds a very simple layout—an image on the left with two lines of text stacked vertically. This XML layout is perfectly fine and contains no errors. Unfortunately, Android 1.5's RelativeLayout is incapable of rendering it correctly, as shown in the screenshot below.
The problem is that this layout uses forward references. For instance, the "band" TextView is positioned below the "track" TextView but "track" is declared after "band" and, in Android 1.5, RelativeLayout does not know how to handle this case. Now look at the exact same layout running on Android 1.6:
As you can see Android 1.6 is now better able to handle forward reference. The result on screen is exactly what you would expect when writing the layout.
Easier click listeners
Setting up a click listener on a button is very common task, but it requires quite a bit of boilerplate code:
findViewById(R.id.myButton).setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
// Do stuff
}
});
One way to reduce the amount of boilerplate is to share a single click listener between several buttons. While this technique reduces the number of classes, it still requires a fair amount of code and it still requires giving each button an id in your XML layout file:
View.OnClickListener handler = View.OnClickListener() {
public void onClick(View v) {
switch (v.getId()) {
case R.id.myButton: // doStuff
break;
case R.id.myOtherButton: // doStuff
break;
}
}
}
findViewById(R.id.myButton).setOnClickListener(handler);
findViewById(R.id.myOtherButton).setOnClickListener(handler);
With Android 1.6, none of this is necessary. All you have to do is declare a public method in your Activity to handle the click (the method must have one View argument):
class MyActivity extends Activity {
public void myClickHandler(View target) {
// Do stuff
}
}
And then reference this method from your XML layout:
<Button android:onClick="myClickHandler" />
This new feature reduces both the amount of Java and XML you have to write, leaving you more time to concentrate on your application.
The Android team is committed to helping you write applications in the easiest and most efficient way possible. We hope you find these improvements useful and we're excited to see your applications on Android Market.
Google Custom Search for mobile
If you own a web site and add a Google Custom Search box to it, when your users access the site on an Android-powered phone, iPhone, iPod Touch, or Palm Pre, they
You can test this out on your phone right now. Here are a few samples: search for user-generated content (e.g., search for "zakumi") from sites like Wikipedia or Knol, or look for more information on Custom Search (e.g., search for "promotion"). As you can see, Custom Mobile Search results can match the look and feel of your own website, and we've enabled interactive features, such as label tabs for navigation, as well as promotions. Look for more features coming soon, too. For more information on Custom Search, and more details on the mobile configuration, visit the Custom Search blog.
Let us know how this works on your favorite smartphone.
Update on 10/23 @ 9:06 AM: Note that some configuration is required for the mobile-formatted results to be shown.
Posted by Rajat Mukherjee, Group Product Manager, Search
Layers come to Google Maps for BlackBerry
Layers make it easy to view various types of information on your map and are especially helpful in situations when you're traveling somewhere new. For example, you can turn on the Wikipedia layer to read entries about nearby places, then use the transit lines layer to help map out a route. Or you can use the My Maps feature of Google Maps to create a collection of places you're planning to visit on your trip and then use Google Maps for mobile to access it from the road. You can also turn on the Google Latitude layer to see your friends' locations.
My coworker Mat is a big fan of Layers and made the below video to show you how he uses the feature. Check out the video, and get the latest version of Google Maps for your phone by visiting m.google.com/maps from your phone's browser.
Posted by Michelle Chen, Software Engineer
Upload photos to Panoramio straight from your iPhone!
Posted by Fernando Delgado, Product Manager, Panoramio Team
Make your web pages and applications Go Mobile too
Posted by Jeremy Weinstein, Google Webmaster
Following a marathon-and-a-half with Latitude
Now 37 miles is a lot -- about a marathon and a half. I'm thinking it'll take me about 6 hours. For the past 4 months I've been training, and now finally, tomorrow is the big day! Throughout the training, lots of people have said they'd love to see the run, but oddly, none of them were up for coming along. So, I decided to do the next best thing. I'm going to take my Latitude-enabled phone with me, and let people follow along from home. I've been blogging about my training and I've embedded the Google public location badge on my blog for the big day. This badge lets me make my Latitude location public and share my progress on the run with anyone who views my blog, even if we're not Latitude friends.
So, if you're up tomorrow, October 16, at 2:30 AM Pacific Daylight Time (or anytime over the next 6 hours or so), check out my progress and see if I make it into work on time. I could use the virtual encouragement!
Updated: I made it! 6 hours, 90 ounces of water, 3 energy gels and 1 banana later. Well, time to get back to work. Hope you all get our and run today!
Posted by Matt Ghering, Googler
Want to reach customers? Go Mobile!
Posted by Lauren Usui, Google Mobile Ads Marketing
You Ask, We Answer. Go Mobile!
Google Voice
We received an overwhelming number of Google Voice questions - 3 out of the top 5 questions were about Google Voice - and we're happy you're so enthusiastic about and interested in this new product! As far as making Voice available to more users, we began giving current users the ability to invite friends and family on Tuesday. We will continue sending out invitations to people who have requested them on our website, and we plan to make additional friends and family invitations available in the future. For those of you outside the US, we plan to make Google Voice available internationally; however, we don't have specifics to share at this time. As for new features, we're certainly evaluating which highly requested features we can add to improve Google Voice, such as number portability, though we don't have anything to announce quite yet. Keep up on the latest with Google Voice by following their blog at http://googlevoiceblog.blogspot.com/.
Googlers' favorite phones
You asked us which phones are the most favored here on the Google mobile team. The answer's not particularly juicy, but it's honest: every phone! You'll see Googlers walking around campus carrying just about every phone under the stars, including multiple Android-powered devices, iPhone, BlackBerry, Windows Mobile, Nokia, etc. And the Mobile team takes it up a notch. It's quite common for us to carry multiple phones at any given time, and as we sit down in a meeting, we often see someone unload five different phones from their pockets onto the table. Don't have the right one handy? We just head to our "Sky Lab" and grab one of the over 800 phones available. By using lots of different devices, we can make sure we're designing products that work well for you, no matter which device YOU are using. We understand that the phone someone chooses to use everyday varies with personal preference, but we generally prefer phones with great browsers and fast performance. Of course, it never hurts to have the newest toy on the block.
Google Wave for mobile
We're still early in Wave's preview, but you can currently access Google Wave on both Android-powered devices and the iPhone by pointing the phone's browser to wave.google.com. Please note that we're still in preview phase, and as we've mentioned before, you may experience occasional downtime or run into some bugs with Wave on your mobile phone, similar to when you access Google Wave from your computer.
Web vs. App
We're often asked why certain products, such as Google Reader, are available as a web application, accessible through the browser, and not a native, downloadable application. At Google, we believe in the power of the web to give us the flexibility to build one app that can run in the browser on multiple phones, rather than developing a different app for every platform. With more capable mobile browsers and technologies like HTML5 and Gears, web apps deliver a great experience because they closely mirror the desktop web in overall look, feel and functionality. They also let us iterate fast and add lots of cool features quickly without having to build from scratch each feature for various devices and platforms. Of course in some cases, investing in native applications for multiple platforms make sense. For example, with Google Maps for mobile, the native app lets us get your location or quickly process lots of data, such as map tiles. That said, new browsers and faster phones are allowing for more powerful web apps - such as Google Maps on Palm Pre or Google Latitude on iPhone - that can also get your location and that are almost as fast as native apps. In the end, there are a lot of users out there on a lot of phones, and we develop our products to put the best experience possible in your hands and your pockets.
In some cases, such as Gmail for certain phones, we offer both a native and web app because we want users to have choice in deciding how they access their information. We believe that both methods - web apps and native apps - offer a rich mobile experience, and we are committed to providing the best possible experience to users, regardless of the underlying development technology.
Mobile Product Roadmap
You also asked lots of great questions around product and feature development and availability. As we mentioned on the original Q & A page, we aren't able to provide forward-looking information on features or products, but we love your enthusiasm for ideas around how we can make existing Google Mobile products more useful or just make more Google Mobile products period. We're always working to improve all of our mobile products and will continue to do so with our eyes and ears open for your ideas and feedback. So keep it coming in the Google Mobile Blog, the Help Forum, and especially the Product Ideas page!
Go Mobile!
Posted by Chris Nguyen, Mobile Consumer Operations
Update - Go Mobile!
Posted by Effie Seiberg, Google Mobile marketing
Captain's Log
Today's brand of mobile user doesn't need four years to figure out their phone. But this week, and with a tip of the hat to the USS Enterprise for the Communicator's anniversary, we did want to celebrate all things mobile by sharing some of Google's favorite mobile tips and tricks. All week long, we're going to be tweeting and blogging our top tips for using Google Search, Gmail, Google Maps, YouTube, and more on your phone. We want to help every cadet go mobile, and get more out of their existing phone. Cadets with questions can ask them here until 11:59 PM Pacific Time, Tuesday night. Keep an eye on the Google Mobile Blog for answers to some of your questions on Wednesday, and tips for advertisers and developers later in the week. Everyone can boldly go... mobile!
Posted by Marc Vanlerberghe, Director of Mobile Marketing
Quick Search Box for Android: Search your phone and the web
Rather than giving you one search box for the web and another for your phone, QSB provides one single search box to let you search content on your phone, including apps, contacts, and browser history, as well as content from the web, like personalized search suggestions, local business listings, stock quotes, weather, and flight status, all without opening the browser. QSB even learns from your habits and provides faster access to the items you search for and use most often (by, for example, moving them higher on the suggestions list).
You can now also tap the microphone button next to the search box to search the web and call contacts by voice. The next time you want to search the web or call a friend, try speaking your query, like "pictures of the Golden Gate Bridge at sunset", or the name of a contact, like "Call Dave Burke, mobile phone", to save even more time. Note that voice search currently only works in English.
Finally, one of the coolest things about QSB is that it's not limited to searching what we think is useful - third party apps can also include suggestions in the list, making it faster to access the content you want from those apps, too. Look on Android Market for apps that support QSB, and enable their suggestions from the system search settings. (And if you're an app developer, check out our developer blog for more on how to leverage QSB for your app.)
We hope Quick Search Box will change the way you use your Android-powered phone by shortening the time and effort it takes to get the information you want while you're on the go. It's available in Android 1.6, so check it out and enjoy!
Posted by Mike LeBeau, Software Engineer
Support for additional screen resolutions and densities in Android
You may have heard that one of the key changes introduced in Android 1.6 is support for new screen sizes. This is one of the things that has me very excited about Android 1.6 since it means Android will start becoming available on so many more devices. However, as a developer, I know this also means a bit of additional work. That's why we've spent quite a bit of time making it as easy as possible for you to update your apps to work on these new screen sizes.
To date, all Android devices (such as the T-Mobile G1 and Samsung I7500, among others) have had HVGA (320x480) screens. The essential change in Android 1.6 is that we've expanded support to include three different classes of screen sizes:
- small: devices with a screen size smaller than the T-Mobile G1 or Samsung I7500, for example the recently announced HTC Tattoo
- normal: devices with a screen size roughly the same as the G1 or I7500.
- large: devices with a screen size larger than the G1 or I7500 (such as a tablet-style device.)
Any given device will fall into one of those three groups. As a developer, you can control if and how your app appears to devices in each group by using a few tools we've introduced in the Android framework APIs and SDK. The documentation at the developer site describes each of these tools in detail, but here they are in a nutshell:
- new attributes in AndroidManifest for an application to specify what kind of screens it supports,
- framework-level support for using image drawables/layouts correctly regardless of screen size,
- a compatibility mode for existing applications, providing a pseudo-HVGA environment, and descriptions of compatible device resolutions and minimum diagonal sizes.
The documentation also provides a quick checklist and testing tips for developers to ensure their apps will run correctly on devices of any screen size.
Once you've upgraded your app using Android 1.6 SDK, you'll need to make sure your app is only available to users whose phones can properly run it. To help you with that, we've also added some new tools to Android Market.
Until the next time you upload a new version of your app to Android Market, we will assume that it works for normal-class screen sizes. This means users with normal-class and large-class screens will have access to these apps. Devices with "large" screens simply run these apps in a compatibility mode, which simulates an HVGA environment on the larger screen.
Devices with small-class screens, however, will only be shown apps which explicitly declare (via the AndroidManifest) that they will run properly on small screens. In our studies, we found that "squeezing" an app designed for a larger screen onto a smaller screen often produces a bad result. To prevent users with small screens from getting a bad impression of your app (and reviewing it negatively!), Android Market makes sure that they can't see it until you upload a new version that declares itself compatible.
We expect small-class screens, as well as devices with additional resolutions in Table 1 in the developer document to hit the market in time for the holiday season. Note that not all devices will be upgraded to Android 1.6 at the same time. There will be significant number of users still with Android 1.5 devices. To use the same apk to target Android 1.5 devices and Android 1.6 devices, build your apps using Android 1.5 SDK and test your apps on both Android 1.5 and 1.6 system images to make sure they continue to work well on both types of devices. If you want to target small-class devices like HTC Tattoo, please build your app using the Android 1.6 SDK. Note that if your application requires Android 1.6 features, but does not support a screen class, you need to set the appropriate attributes to false. To use optimized assets for normal-class, high density devices like WVGA, or for low density devices please use the Android 1.6 SDK.
Introducing Search Options for mobile
Posted by Reza Ziaei, Software Engineer, Google Mobile Team
ADC 2 Round 1 Scoring Complete
The response to round one of the Android Developer Challenge 2 has been phenomenal! We originally expected that it would take two weeks to get all the necessary data to complete scoring. Over the last 10 days, more than 26,000 Android users reviewed and submitted our target of over 100 scores per application. With this enthusiastic support of the Android community, we are closing the first round of ADC 2 judging today.
We will now be reviewing the results and preparing for round 2. Please stay tuned for information about round 2, where the community, combined with a panel of judges, will narrow down the top 20 applications in each category to determine the final winners. Until then, users with the ADC 2 judging application currently installed will get a notice saying that round 1 is over. When round 2 opens, the judging application will resume giving out new submissions to score. We look forward to seeing the results of the final round and hope that you choose to help us score these top apps as well!
Gestures on Android 1.6
Touch screens are a great way to interact with applications on mobile devices. With a touch screen, users can easily tap, drag, fling, or slide to quickly perform actions in their favorite applications. But it's not always that easy for developers. With Android, it's easy to recognize simple actions, like a swipe, but it's much more difficult to handle complicated gestures, which also require developers to write a lot of code. That's why we have decided to introduce a new gestures API in Android 1.6. This API, located in the new package android.gesture
, lets you store, load, draw and recognize gestures. In this post I will show you how you can use the android.gesture
API in your applications. Before going any further, you should download the source code of the examples.
Creating a gestures library
The Android 1.6 SDK comes with a new application pre-installed on the emulator, called Gestures Builder. You can use this application to create a set of pre-defined gestures for your own application. It also serves as an example of how to let the user define his own gestures in your applications. You can find the source code of Gestures Builders in the samples directory of Android 1.6. In our example we will use Gestures Builder to generate a set of gestures for us (make sure to create an AVD with an SD card image to use Gestures Builder.) The screenshot below shows what the application looks like after adding a few gestures:
As you can see, a gesture is always associated with a name. That name is very important because it identifies each gesture within your application. The names do not have to be unique. Actually it can be very useful to have several gestures with the same name to increase the precision of the recognition. Every time you add or edit a gesture in the Gestures Builder, a file is generated on the emulator's SD card, /sdcard/gestures
. This file contains the description of all the gestures, and you will need to package it inside your application inside the resources directory, in /res/raw
.
Loading the gestures library
Now that you have a set of pre-defined gestures, you must load it inside your application. This can be achieved in several ways but the easiest is to use the GestureLibraries
class:
mLibrary = GestureLibraries.fromRawResource(this, R.raw.spells);
if (!mLibrary.load()) {
finish();
}
In this example, the gesture library is loaded from the file /res/raw/spells
. You can easily load libraries from other sources, like the SD card, which is very important if you want your application to be able to save the library; a library loaded from a raw resource is read-only and cannot be modified. The following diagram shows the structure of a library:
Recognizing gestures
To start recognizing gestures in your application, all you have to do is add a GestureOverlayView
to your XML layout:
<android.gesture.GestureOverlayView
android:id="@+id/gestures"
android:layout_width="fill_parent"
android:layout_height="0dip"
android:layout_weight="1.0" />
Notice that the GestureOverlayView
is not part of the usual android.widget package. Therefore, you must use its fully qualified name. A gesture overlay acts as a simple drawing board on which the user can draw his gestures. You can tweak several visual properties, like the color and the width of the stroke used to draw gestures, and register various listeners to follow what the user is doing. The most commonly used listener is GestureOverlayView.OnGesturePerformedListener
which fires whenever a user is done drawing a gesture:
GestureOverlayView gestures = (GestureOverlayView) findViewById(R.id.gestures);
gestures.addOnGesturePerformedListener(this);
When the listener fires, you can ask the GestureLibrary
to try to recognize the gesture. In return, you will get a list of Prediction instances, each with a name - the same name you entered in the Gestures Builder - and a score. The list is sorted by descending scores; the higher the score, the more likely the associated gesture is the one the user intended to draw. The following code snippet demonstrates how to retrieve the name of the first prediction:
public void onGesturePerformed(GestureOverlayView overlay, Gesture gesture) {
ArrayListpredictions = mLibrary.recognize(gesture);
// We want at least one prediction
if (predictions.size() > 0) {
Prediction prediction = predictions.get(0);
// We want at least some confidence in the result
if (prediction.score > 1.0) {
// Show the spell
Toast.makeText(this, prediction.name, Toast.LENGTH_SHORT).show();
}
}
}
In this example, the first prediction is taken into account only if it's score is greater than 1.0. The threshold you use is entirely up to you but know that scores lower than 1.0 are typically poor matches. And this is all the code you need to create a simple application that can recognize pre-defined gestures (see the source code of the project GesturesDemo):
Gestures overlay
In the example above, the GestureOverlayView
was used as a normal view, embedded inside a LinearLayout. However, as its name suggests, it can also be used as an overlay on top of other views. This can be useful to recognize gestures in a game or just anywhere in the UI of an application. In the second example, called GesturesListDemo, we'll create an overlay on top of a list of contacts. We start again in Gestures Builder to create a new set of pre-defined gestures:
And here is what the XML layout looks like:
<android.gesture.GestureOverlayView
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/gestures"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:gestureStrokeType="multiple"
android:eventsInterceptionEnabled="true"
android:orientation="vertical">
<ListView
android:id="@android:id/list"
android:layout_width="fill_parent"
android:layout_height="fill_parent" />
</android.gesture.GestureOverlayView>
In this application, the gestures view is an overlay on top of a regular ListView. The overlay also specifies a few properties that we did not need before:
gestureStrokeType
: indicates whether we want to recognize gestures made of a single stroke or multiple strokes. Since one of our gestures is the "+" symbol, we need multiple strokeseventsInterceptionEnabled
: when set to true, this property tells the overlay to steal the events from its children as soon as it knows the user is really drawing a gesture. This is useful when there's a scrollable view under the overlay, to avoid scrolling the underlying child as the user draws his gestureorientation
: indicates the scroll orientation of the views underneath. In this case the list scrolls vertically, which means that any horizontal gestures (likeaction_delete
) can immediately be recognized as a gesture. Gestures that start with a vertical stroke must contain at least one horizontal component to be recognized. In other words, a simple vertical line cannot be recognized as a gesture since it would conflict with the list's scrolling.
The code used to load and set up the gestures library and overlay is exactly the same as before. The only difference is that we now check the name of the predictions to know what the user intended to do:
public void onGesturePerformed(GestureOverlayView overlay, Gesture gesture) {
ArrayList<Prediction> predictions = mLibrary.recognize(gesture);
if (predictions.size() > 0 && predictions.get(0).score > 1.0) {
String action = predictions.get(0).name;
if ("action_add".equals(action)) {
Toast.makeText(this, "Adding a contact", Toast.LENGTH_SHORT).show();
} else if ("action_delete".equals(action)) {
Toast.makeText(this, "Removing a contact", Toast.LENGTH_SHORT).show();
} else if ("action_refresh".equals(action)) {
Toast.makeText(this, "Reloading contacts", Toast.LENGTH_SHORT).show();
}
}
}
The user is now able to draw his gestures on top of the list without interfering with the scrolling:
The overlay even gives visual clues as to whether the gesture is considered valid for recognition. In the case of a vertical overlay, for instance, a single vertical stroke cannot be recognized as a gesture and is therefore drawn with a translucent color:
It's your turn
Adding support for gestures in your application is easy and can be a valuable addition. The gestures API does not even have to be used to recognize complex shapes; it will work equally well to recognize simple swipes. We are very excited by the possibilities the gestures API offers, and we're eager to see what cool applications the community will create with it.
AdSense for Mobile optimized for high-end phones
High-end mobile phones, like iPhone, Android-powered devices and the Palm Pre, continue to grow — Gartner estimates that global sales of smartphones will soar by 27% in 2009, to 177 million units. Naturally, as a result more and more people are browsing the web on the go.
Because these devices offer a browsing experience that is similar to desktop computers, advertising on smartphones is a natural extension for any AdWords campaign. However, it's not always been easy for advertisers to reach people on smartphones. That's why we're investing in new high-end mobile advertising products such as our search ad options for high-end phones and AdSense for mobile applications. We hope to make advertising on high-end mobile devices as intuitive, effective and user-friendly as our existing AdWords tools.
Today, we're excited to announce a new feature for our AdSense mobile publishers that enables them to serve text and image ads on their sites — specifically on these high-end smartphones. This helps mobile publishers earn revenue and fund more mobile-specific sites and web content.
New features like this help to nurture the smartphone ecosystem by encouraging the creation of more mobile content and by helping advertisers to grow their businesses by reaching new audiences. Our users' experience is also improved, with increasingly relevant and device-optimized mobile ads that load faster and fit better on small screens.
For more info about this feature, check out the Inside AdSense Blog.
Posted by Danielle VanDyke, Software Engineer