The Google Docs app for Android now with Web Clipboard and in 46 languages

In April, we introduced the Google Docs app for Android, a useful way to view, edit and create documents and spreadsheets on the go. Today, we're extending the availability of this app to 45 additional languages and adding a new Web Clipboard feature that makes it easy to insert photos from your Android phone into a Google document. Learn more on the Google Docs blog and update or download the app today from Android Market.





Horizontal View Swiping with ViewPager

[This post is by Rich “geekyouup” Hyndman, inspired by the fact that life just got that little bit easier — Tim Bray]



Whether you have just started out in Android app development or are a veteran of the craft, it probably won’t be too long before you’ll need to implement horizontally scrolling sets of views.
Many existing Android apps already use this UI pattern. ViewPager standardizes the implementation.

ViewPager was released as part of the Compatibility Package revision 3 and works with Android 1.6 upwards. After following the instructions to obtain the package you can right-click on your Android project in Eclipse, choose ‘Android Tools’ and ‘Add Compatibility Library’, making the new classes available.

ViewPager is a ViewGroup and works in a similar manner to AdapterViews (like ListView and Gallery) so it shouldn’t feel too foreign. Note that if you use ViewPager in an xml layout, be sure to use the full class reference, e.g.

 <android.support.v4.view.ViewPager
android:layout_width="match_parent"
android:layout_height="match_parent"
… />

ViewPagers source their views from PagerAdapters which give you have full control over the reuse and recycling of the views. A PagerAdapter implementation called FragmentPagerAdapter is provided to facilitate the use of Fragments in a ViewPager; This is immensely powerful and as simple as implementing getCount() and getItem(). There is a sample called Fragment Pager Support provided in the Support Demos to illustrate this.

    public static class MyAdapter extends FragmentPagerAdapter {
public MyAdapter(FragmentManager fm) {
super(fm);
}

@Override
public int getCount() {
return NUM_ITEMS;
}

@Override
public Fragment getItem(int position) {
return ArrayListFragment.newInstance(position);
}
}

FragmentPagerAdapter will detach each fragment as you swipe through the list, but keep them in memory so they can simply be reattached when the user swipes back. If you have a larger number of Fragments, the FragmentStatePagerAdapter is worth considering as it will remove them, with the downside being they need to be rebuilt as the user swipes back to them. So, if you have fewer, more complex fragments the FragmentPagerAdapter makes sense, but consider FragmentStatePagerAdapter for larger sets.

On the more simplistic side I recently wrote a ViewPager/PagerAdapter example that serves up simple TextViews. One thing to note is that if you are implementing your own PagerAdapter it is up to you, the developer, to add and remove your views to and from the ViewGroup. To facilitate this the ViewPager is passed into the PagerAdapter methods instantiateItem() and destroyItem().

    @Override
public Object instantiateItem(View collection, int position) {
View v = layoutInflater.inflate(...);
...
((ViewPager) collection).addView(v,0);
return tv;
}

@Override
public void destroyItem(View collection, int position, Object view) {
((ViewPager) collection).removeView((TextView) view);
}

The source code for ViewPager is also included and available in <android-sdk>/extras/android/compatibility/v4/src. It is worth checking as you can generate the reference documentation from it using Javadoc. In the reference docs / source you’ll find other useful methods, for example setOnPageChangeListener(), which enables your application to track which View is currently visible.

If you are launching an app onto Android Market that uses ViewPager then please ping me on Google+ or Twitter, I’d love to see how widely it is being used and the innovative scenarios in which it appears.

Preview of Google TV Add-on for the Android SDK

[This post is by Ambarish Kenghe, who’s a Product Manager for Google TV — Tim Bray]

At Google I/O, we announced that Android Market is coming to Google TV. Today, we’re announcing a preview of the Google TV Add-on for the Android SDK. With the upcoming OS update to Honeycomb, Google TV devices will be Android compatible. That means developers can build great new Android apps for TV, optimize existing mobile or tablet apps for TV, and distribute those apps through Android Market.

While the add-on does not contain all features of Google TV, it enables developers to emulate Google TV and build apps using standard Android SDK tools. It also provides new APIs for TV interaction, such as TV channel line-up. Google TV emulation is currently supported on Linux with KVM only, and we are working on support for other operating systems. We’re very happy that through KVM we’ve been able to create a fast Android emulator for TV.

Depending on the design and use case, an existing Android app may work well on Google TV as is, or it may require fixes. With the add-on you can test your apps to determine if they would be a good fit for TV and whether any tweaks are required. We are also publishing UI guidelines to help you with topics like optimizing for D-pad navigation, presenting information for 10-foot viewing, designing apps that work well across devices, etc. The guidelines include information on how certain UI elements on Google TV differ from other Android devices.

As with other devices, apps that require features not supported on Google TV won’t appear in Android Market on Google TV. For example, Google TV-based devices do not have a touchscreen; hence apps which require touchscreen will not appear. Conversely, if the manifest says touchscreen is not required, the app will appear. Please follow our guidelines carefully.

These are still early days for Google TV, and this release is another step in providing developer tools for the big screen. While the number of apps available on TV will initially be small, we expect that through this early release of the add-on you'll be able to bring optimized TV apps into the ecosystem more quickly. To start doing this, download the Google TV add-on today. Also, please continue to reach out to us on the Google TV Android Developer Community forum. We look forward to your contributions!


Shop your favorite catalogs with Google Catalogs

(cross-posted from the Official Google Blog)

For years, shoppers have enjoyed flipping through glossy print catalogs to be inspired, discover new trends and find great products. Today, mobile technologies can make catalog shopping more engaging, social and creative. With that in mind, we’ve created Google Catalogs—a free app for tablet devices that enables you to browse all of your favorite catalogs and interact with new layers of rich-media content.

The Google Catalogs app features digital versions of catalogs across many popular categories, including fashion and apparel, beauty, jewelry, home, kids and gifts. We’ve partnered with a variety of top brands including Anthropologie, Bare Escentuals, Bergdorf Goodman, Crate and Barrel, L.L. Bean, Lands’ End, Macy’s, Neiman Marcus, Nordstrom, Pottery Barn, Saks Fifth Avenue, Sephora, Sundance, Tea Collection, Urban Outfitters and Williams-Sonoma, just to name a few.
With Google Catalogs, you can:
  • Interact: Zoom in to see products up close, tap on tags to learn more about an item or, in some catalogs, view inspiring photo albums and videos.

  • Find products in nearby stores: When an item catches your eye, instantly find it in a store near you or tap “Buy on Website” to visit the merchant online.

  • Express your creativity: Create a collage of your favorite catalog pages and products. If you need inspiration, you can check out collages created by others.

  • Share with friends: Email a product or collage to all your shopping buddies.

  • Get instant access to new catalogs: Add catalogs to your Favorites and get notified each time a new issue arrives.

  • Discover new products and brands: Search for products within or across multiple catalogs to find exactly what you’re looking for.



To download the app on your iPad, visit the App Store. Visit www.google.com/catalogs/about/ to learn more, and stay tuned for Google Catalogs for Android tablets, coming soon! If you’re a merchant and would like to participate in Google Catalogs, tell us about your catalog by filling out this form on our website. Happy shopping!

Android Developer Labs 2011

We in Android Developer Relations have been cooking up a rather special set of Android Developer Labs (ADLs) for the second half of 2011, and we’re ready to start the ball rolling.

Here’s the schedule. These are one-day events, so in Seattle and New York we’re running it twice for two audiences.

This ADL series isn’t another set of introduction-to-Android sessions, nor any other kind of general overview. It's specifically aimed at optimizing Android apps for tablets, in particular creating high-quality tablet apps with an emphasis on polish and user-experience.

Registration is a two-step process. Anyone can register, but we can only accommodate a relatively small number of attendees from among the registrants, based on whether they already have an Android app with the potential to be a top-tier tablet app in terms of quality, fit, and finish. The goal is to bring your app to the ADL, and leave equipped to make it into one that makes Android tablet users smile.

Do you think you qualify? Sign up and show us!

New Google Search experience for tablets

(Cross-posted on the Inside Search blog)

As part of our effort to evolve the Google design and experience, we’ve improved the www.google.com search experience on tablets. We’ve simplified the layout of search results pages and increased the size of page contents like text, buttons and other touch targets to make it faster and easier to browse and interact with search results in portrait or landscape view.

The search button located below the search box provides quick access to specific types of results like Images, Videos, Places, Shopping and more. Just tap to open the search menu and select an option to see results in one category.




For image results, we focused on improvements that enhance the viewing experience such as enlarged image previews, continuous scroll, and faster loading of image thumbnails.




This improved search experience is rolling out in the coming days to iPad and Android 3.1+ tablets across 36 languages. Give it a try by going to www.google.com in your tablet’s browser.

Custom Class Loading in Dalvik

[This post is by Fred Chung, who’s an Android Developer Advocate — Tim Bray]

The Dalvik VM provides facilities for developers to perform custom class loading. Instead of loading Dalvik executable (“dex”) files from the default location, an application can load them from alternative locations such as internal storage or over the network.

This technique is not for every application; In fact, most do just fine without it. However, there are situations where custom class loading can come in handy. Here are a couple of scenarios:

  • Big apps can contain more than 64K method references, which is the maximum number of supported in a dex file. To get around this limitation, developers can partition part of the program into multiple secondary dex files, and load them at runtime.

  • Frameworks can be designed to make their execution logic extensible by dynamic code loading at runtime.

We have created a sample app to demonstrate the partitioning of dex files and runtime class loading. (Note that for reasons discussed below, the app cannot be built with the ADT Eclipse plug-in. Instead, use the included Ant build script. See Readme.txt for detail.)

The app has a simple Activity that invokes a library component to display a Toast. The Activity and its resources are kept in the default dex, whereas the library code is stored in a secondary dex bundled in the APK. This requires a modified build process, which is shown below in detail.

Before the library method can be invoked, the app has to first explicitly load the secondary dex file. Let’s take a look at the relevant moving parts.

Code Organization

The application consists of 3 classes.

  • com.example.dex.MainActivity: UI component from which the library is invoked

  • com.example.dex.LibraryInterface: Interface definition for the library

  • com.example.dex.lib.LibraryProvider: Implementation of the library

The library is packaged in a secondary dex, while the rest of the classes are included in the default (primary) dex file. The “Build process” section below illustrates how to accomplish this. Of course, the packaging decision is dependent on the particular scenario a developer is dealing with.

Class loading and method invocation

The secondary dex file, containing LibraryProvider, is stored as an application asset. First, it has to be copied to a storage location whose path can be supplied to the class loader. The sample app uses the app’s private internal storage area for this purpose. (Technically, external storage would also work, but one has to consider the security implications of keeping application binaries there.)

Below is a snippet from MainActivity where standard file I/O is used to accomplish the copying.

  // Before the secondary dex file can be processed by the DexClassLoader,
// it has to be first copied from asset resource to a storage location.
File dexInternalStoragePath = new File(getDir("dex", Context.MODE_PRIVATE),
SECONDARY_DEX_NAME);
...
BufferedInputStream bis = null;
OutputStream dexWriter = null;

static final int BUF_SIZE = 8 * 1024;
try {
bis = new BufferedInputStream(getAssets().open(SECONDARY_DEX_NAME));
dexWriter = new BufferedOutputStream(
new FileOutputStream(dexInternalStoragePath));
byte[] buf = new byte[BUF_SIZE];
int len;
while((len = bis.read(buf, 0, BUF_SIZE)) > 0) {
dexWriter.write(buf, 0, len);
}
dexWriter.close();
bis.close();

} catch (. . .) {...}

Next, a DexClassLoader is instantiated to load the library from the extracted secondary dex file. There are a couple of ways to invoke methods on classes loaded in this manner. In this sample, the class instance is cast to an interface through which the method is called directly.

Another approach is to invoke methods using the reflection API. The advantage of using reflection is that it doesn’t require the secondary dex file to implement any particular interfaces. However, one should be aware that reflection is verbose and slow.

  // Internal storage where the DexClassLoader writes the optimized dex file to
final File optimizedDexOutputPath = getDir("outdex", Context.MODE_PRIVATE);

DexClassLoader cl = new DexClassLoader(dexInternalStoragePath.getAbsolutePath(),
optimizedDexOutputPath.getAbsolutePath(),
null,
getClassLoader());
Class libProviderClazz = null;
try {
// Load the library.
libProviderClazz =
cl.loadClass("com.example.dex.lib.LibraryProvider");
// Cast the return object to the library interface so that the
// caller can directly invoke methods in the interface.
// Alternatively, the caller can invoke methods through reflection,
// which is more verbose.
LibraryInterface lib = (LibraryInterface) libProviderClazz.newInstance();
lib.showAwesomeToast(this, "hello");
} catch (Exception e) { ... }

Build Process

In order to churn out two separate dex files, we need to tweak the standard build process. To do the trick, we simply modify the “-dex” target in the project’s Ant build.xml.

The modified “-dex” target performs the following operations:

  1. Create two staging directories to store .class files to be converted to the default dex and the secondary dex.

  2. Selectively copy .class files from PROJECT_ROOT/bin/classes to the two staging directories.

          <!-- Primary dex to include everything but the concrete library
    implementation. -->
    <copy todir="${out.classes.absolute.dir}.1" >
    <fileset dir="${out.classes.absolute.dir}" >
    <exclude name="com/example/dex/lib/**" />
    </fileset>
    </copy>
    <!-- Secondary dex to include the concrete library implementation. -->
    <copy todir="${out.classes.absolute.dir}.2" >
    <fileset dir="${out.classes.absolute.dir}" >
    <include name="com/example/dex/lib/**" />
    </fileset>
    </copy>
  3. Convert .class files from the two staging directories into two separate dex files.

  4. Add the secondary dex file to a jar file, which is the expected input format for the DexClassLoader. Lastly, store the jar file in the “assets” directory of the project.

        <!-- Package the output in the assets directory of the apk. -->
    <jar destfile="${asset.absolute.dir}/secondary_dex.jar"
    basedir="${out.absolute.dir}/secondary_dex_dir"
    includes="classes.dex" />

To kick-off the build, you execute ant debug (or release) from the project root directory.

That’s it! In the right situations, dynamic class loading can be quite useful.