Android Love at OSCON

Tweet

Android developers who aren't already going should take a moment to check out the OSCON 2010 schedule, and give serious thought to a trip to Portland in a couple of weeks. OSCON is one of the world's premiere events for those who care about Open Source, and one of my personal favorite conferences, with a powerful community vibe. And this year, the Android drums are sounding.

There are a bunch of mobile and Android-related sessions, both pure and extremely impure; for example, I bet both Steve Jobs and I are dubious about Cross-Compiling Android Applications to the iPhone. There's a full-dress Android for Java Developers tutorial. And (the one I helped cook up) there's the Android Hands-On; last I heard, registration for that is approaching 200 and, since O'Reilly found us a big room, it's not full up; but it will be.

On top of which, there are going to be a herd of Googlers at OSCON, and a sub-herd of Androiders, including Dan Morrill and Justin Mattson and me. This isn't surprising; what does surprise me is that OSCON hasn't previously been an Android love-fest. Because if you're interested in mobile devices and have a hankering for Open Source, Android is for you.

Android Market Problem

Tweet

Earlier today we had a brief outage in Android Market. For a period of about thirty minutes, some users were unable to find any apps. The problem was detected and corrected, and we believe the user experience is now back to normal. We apologize for the outage.

Android Market Client Update

Tweet

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

The Android Market engineering team has been hard at work on improving the Android Market experience for users and developers. Today, I’m pleased to announce a significant update to the Android Market client. Over the next two weeks, we’ll be rolling out a new Android Market client to all devices running Android 1.6 or higher.

This new Market client introduces important features that improve merchandising of applications, streamline the browse-to-purchase experience, and make it easier for developers to distribute their applications.

With a focus on improving discoverability and merchandising, we’ve introduced a new carousel on the home and category screens. Users can quickly flip through the carousel to view promoted applications and immediately go to the download page for the application they want. Developers have been very active in creating great Widgets and Live Wallpapers. To make it easier for users to find their favorites, we’re introducing two new categories for Widgets and Live Wallpapers. Applications that include Widgets and Wallpapers will be automatically added to those new categories. We’ll also be adding more categories for popular applications and games in the weeks ahead. In addition, the app details page now includes Related content, which makes it easier for users to quickly find apps of similar interest.

To streamline the browse-to-purchase experience, users can now access all the information about an application on a single page without the need to navigate across different tabs. We’re also introducing application content rating to provide users with more information about applications they are interested in. Since most users who request a refund do so within minutes of purchase, we will reduce the refund window on Market to 15 minutes. This change will be largely transparent to buyers, but will help developers manage their businesses more effectively.

To make it easier for developers to distribute and manage their products, we will introduce support for device targeting based on screen sizes and densities, as well as on GL texture compression formats. We are also increasing the maximum size for .apk files on Market to 50MB, to better support richer games.

With this release, we aimed to deliver features that are most requested by users and developers. However, we’re not done yet. We plan to continue to rapidly enhance Android Market for both users and developers and make it the best content distribution service for the Android ecosystem.

Please stay tuned as we continue to deliver new capabilities in the coming weeks and months.

Android Layout Tricks #3: Optimize by merging

Tweet

In the previous installment of Android Layout Tricks, I showed you how to use the tag in XML layout to reuse and share your layout code. I also mentioned the and it's now time to learn how to use it.

The was created for the purpose of optimizing Android layouts by reducing the number of levels in view trees. It's easier to understand the problem this tag solves by looking at an example. The following XML layout declares a layout that shows an image with its title on top of it. The structure is fairly simple; a FrameLayout is used to stack a TextView on top of an ImageView:

This layout renders nicely as we expected and nothing seems wrong with this layout:

Things get more interesting when you inspect the result with HierarchyViewer. If you look closely at the resulting tree you will notice that the FrameLayout defined in our XML file (highlighted in blue below) is the sole child of another FrameLayout:

Since our FrameLayout has the same dimension as its parent, by the virtue of using the fill_parent constraints, and does not define any background, extra padding or a gravity, it is totally useless. We only made the UI more complex for no good reason. But how could we get rid of this FrameLayout? After all, XML documents require a root tag and tags in XML layouts always represent view instances.

That's where the tag comes in handy. When the LayoutInflater encounters this tag, it skips it and adds the children to the parent. Confused? Let's rewrite our previous XML layout by replacing the FrameLayout with :

With this new version, both the TextView and the ImageView will be added directly to the top-level FrameLayout. The result will be visually the same but the view hierarchy is simpler:

Obviously, using works in this case because the parent of an activity's content view is always a FrameLayout. You could not apply this trick if your layout was using a LinearLayout as its root tag for instance. The can be useful in other situations though. For instance, it works perfectly when combined with the tag. You can also use when you create a custom composite view. Let's see how we can use this tag to create a new view called OkCancelBar which simply shows two buttons with customizable labels. You can also download the complete source code of this example. Here is the XML used to display this custom view on top of an image:

This new layout produces the following result on a device:

The source code of OkCancelBar is very simple because the two buttons are defined in an external XML file, loaded using a LayoutInflate. As you can see in the following snippet, the XML layout R.layout.okcancelbar is inflated with the OkCancelBar as the parent:

public class OkCancelBar extends LinearLayout { public OkCancelBar(Context context, AttributeSet attrs) { super(context, attrs); setOrientation(HORIZONTAL); setGravity(Gravity.CENTER); setWeightSum(1.0f);  LayoutInflater.from(context).inflate(R.layout.okcancelbar, this, true);  TypedArray array = context.obtainStyledAttributes(attrs, R.styleable.OkCancelBar, 0, 0);  String text = array.getString(R.styleable.OkCancelBar_okLabel); if (text == null) text = "Ok"; ((Button) findViewById(R.id.okcancelbar_ok)).setText(text);  text = array.getString(R.styleable.OkCancelBar_cancelLabel); if (text == null) text = "Cancel"; ((Button) findViewById(R.id.okcancelbar_cancel)).setText(text);  array.recycle(); }}

The two buttons are defined in the following XML layout. As you can see, we use the tag to add the two buttons directly to the OkCancelBar. Each button is included from the same external XML layout file to make them easier to maintain; we simply override their id:

We have created a flexible and easy to maintain custom view that generates an efficient view hierarchy:

The tag is extremely useful and can do wonders in your code. However, it suffers from a couple of limitation:

• can only be used as the root tag of an XML layout
• When inflating a layout starting with a , you must specify a parent ViewGroup and you must set attachToRoot to true (see the documentation of the inflate() method)

In the next installment of Android Layout Tricks you will learn about ViewStub, a powerful variation of that can help you further optimize your layouts without sacrificing features.

Download the complete source code of this example.

Android Market New Country Roll-out Details

Tweet

[This post is by the Android Market team. — Tim Bray]

Last week, we announced that over the next two weeks, users in 18 additional countries would gain the ability to purchase paid apps from Android Market. Effective today, users can now see paid apps in Argentina, Belgium, Brazil, Czech Republic, Denmark, Finland, Hong Kong, India, Ireland, Israel, Mexico, Norway, Poland, Portugal, Russia, Singapore, Sweden, and Taiwan.

For users to make a purchase of paid apps in these countries, they must have the latest Android Market client, which we have started to make available as a self-update and should reach all users within the next few days. This is a silent update; users will not see a notification and will not be prompted to do anything. If you want to accelerate the self-update process, launch Android Market, navigate back to the Home screen, and after 5-10 minutes, relaunch it. For more details, please refer to the Help Center.

No action is necessary if you have targeted your paid apps to be available to “All Locations” and would like to launch in these additional countries. If you have not selected “All Locations” and would like to target these additional countries, or if you have selected “All Locations” and do not want to launch your apps in these additional buyer countries, please visit the Android Market publisher site to make the necessary adjustments.

Android Market Action

Tweet

Almost instantly after I joined Google, it became obvious to me that the number-one area where Android developers wanted to see action and progress was in Android Market; your concerns in this area vastly outweighed whatever issues might be bothering you about the handsets and the framework and the programming tools. In recent months there has been a steady, quiet, incremental flow of improvements and upgrades. They add up. This is by way of a glance back at developments since the arrival of Froyo last summer.

First, we introduced error reporting to Market, so developers can see if their apps are locking up or crashing; and if so, exactly where.

Second, we upgraded the Market publisher site to include user comments, so you can read what people are saying about you, or at least what they’re saying in a language you understand.

Third, we added the licensing server, which, when used properly, tilts the economics of Android apps toward you, the developer, and against the pirates.

Fourth, we cranked up the number of countries people can buy and sell apps in: as of now, you can sell them in 29 countries and buy them in 32.

Fifth, we rolled in a “recent changes” feature, a place for developers to put their release notes. Android Market has a zero-friction process for app update, and the really great apps have followed the “release early, release often” philosophy. As a developer, I like having a place to write down what’s behind an app release, and as a person who downloads lots of apps, I like to know what the goodies are in each new update.

Sixth, Market now has a “draft upload” feature; this removes a lot of the tension and strain from the app-update process. Get your screenshots and feature graphics and text and APK all squared away with as much editing as you need to, then update them all with one click.

You’ll notice that I didn’t say “Sixth and last”, because this is a team on a roll and I expect lots more goodness from them; if you care about the larger Android ecosystem, or are already a developer, or are thinking of becoming one, stay tuned to this channel.

Android Layout Tricks #3: Optimize with stubs

Tweet

Sharing and reusing layouts is very easy with Android thanks to the tag, sometimes even too easy and you might end up with user interfaces that contain a large number of views, some of which are rarely used. Thankfully, Android offers a very special widget called ViewStub, which brings you all the benefits of the without polluting your user interface with rarely used views.

A ViewStub is a dumb and lightweight view. It has no dimension, it does not draw anything and does not participate in the layout in any way. This means a ViewStub is very cheap to inflate and very cheap to keep in a view hierarchy. A ViewStub can be best described as a lazy include. The layout referenced by a ViewStub is inflated and added to the user interface only when you decide so.

The following screenshot comes from the Shelves application. The main purpose of the activity shown in the screenshot is to present the user with a browsable list of books:

The same activity is also used when the user adds or imports new books. During such an operation, Shelves shows extra bits of user interface. The screenshot below shows the progress bar and cancel button that appear at the bottom of the screen during an import:

Because importing books is not a common operation, at least when compared to browsing the list of books, the import panel is originally represented by a ViewStub:

When the user initiates the import process, the ViewStub is inflated and replaced by the content of the layout file it references:

To use a ViewStub all you need is to specify an android:id attribute, to later inflate the stub, and an android:layout attribute, to reference what layout file to include and inflate. A stub lets you use a third attribute, android:inflatedId, which can be used to override the id of the root of the included file. Finally, the layout parameters specified on the stub will be applied to the roof of the included layout. Here is an example:

When you are ready to inflate the stub, simply invoke the inflate() method. You can also simply change the visibility of the stub to VISIBLE or INVISIBLE and the stub will inflate. Note however that the inflate() method has the benefit of returning the root View of the inflate layout:

((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);// orView importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();

It is very important to remember that after the stub is inflated, the stub is removed from the view hierarchy. As such, it is unnecessary to keep a long-lived reference, for instance in an class instance field, to a ViewStub.

A ViewStub is a great compromise between ease of programming and efficiency. Instead of inflating views manually and adding them at runtime to your view hierarchy, simply use a ViewStub. It's cheap and easy. The only drawback of ViewStub is that it currently does not support the tag.

Happy coding!