Pages

Sunday 17 March 2013

Android in Harvard Square

As promised, there's another Android event coming up – though a little closer to home this time. Our Android Advocates are heading to Boston for a Code Day that will be taking place on February 23. Registration is now open, but space is limited so make sure you reserve your spot.

Here are the details:

Date: Saturday, February 23, 2008
Time: 10:00 am - 4:00 pm
Location: The Charles Hotel Harvard Square
1 Bennett St
Cambridge, MA 02138

As a reminder, a Code Day is an immersive introduction and hands-on session for Android.

It's promising to be a real Android nor'easter. We hope to see you there!

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.

Android Layout Tricks #1

The Android UI toolkit offers several layout managers that are rather easy to use and, most of the time, you only need the basic features of these layout managers to implement a user interface. Sticking to the basic features is unfortunately not the most efficient way to create user interfaces. A common example is the abuse of LinearLayout, which leads to a proliferation of views in the view hierarchy. Every view, or worse every layout manager, you add to your application comes at a cost: initialization, layout and drawing become slower. The layout pass can be especially expensive when you nest several LinearLayout that use the weight parameter, which requires the child to be measured twice.

Let's consider a very simple and common example of a layout: a list item with an icon on the left, a title at the top and an optional description underneath the title. Here is what such an item looks like:

Simple list item

To clearly understand how the views, one ImageView and two TexView, are positioned with respect to each other, here is the wireframe of the layout as captured by HierarchyViewer:

Wireframe of the simple list item

Implementing this layout is straightforward with LinearLayout. The item itself is a horizontal LinearLayout with an ImageView and a vertical LinearLayout, which contains the two TextViews. The source code of this layout is the following:

        

This layout works but can be wasteful if you instantiate it for every list item of a ListView. The same layout can be rewritten using a single RelativeLayout, thus saving one view, and even better one level in view hierarchy, per list item. The implementation of the layout with a RelativeLayout remains simple:

    

This new implementation behaves exactly the same way as the previous implementation, except in one case. The list item we want to display has two lines of text: the title and an optional description. When a description is not available for a given list item, the application would simply set the visibility of the second TextView to GONE. This works perfectly with the LinearLayout implementation but not with the RelativeLayout version:

RelativeLayout and description GONE
RelativeLayout and description GONE

In a RelativeLayout, views are aligned either with their parent, the RelativeLayout itself, or other views. For instance, we declared that the description is aligned with the bottom of the RelativeLayout and that the title is positioned above the description and anchored to the parent's top. With the description GONE, RelativeLayout doesn't know where to position the title's bottom edge. To solve this problem, you can use a very special layout parameter called alignWithParentIfMissing.

This boolean parameter simply tells RelativeLayout to use its own edges as anchors when a constraint target is missing. For instance, if you position a view to the right of a GONE view and set alignWithParentIfMissing to true, RelativeLayout will instead anchor the view to its left edge. In our case, using alignWithParentIfMissing will cause RelativeLayout to align the title's bottom with its own bottom. The result is the following:

RelativeLayout, description GONE and alignWithParentIfMissing
RelativeLayout, description GONE and alignWithParentIfMissing

The behavior of our layout is now perfect, even when the description is GONE. Even better, the hierarchy is simpler and because we are not using LinearLayout's weights it's also more efficient. The difference between the two implementations becomes obvious when comparing the view hierarchies in HierarchyViewer:

LinearLayout vs RelativeLayout

Again, the difference will be much more important when you use such a layout for every item in a ListView for instance. Hopefully this simple example showed you that getting to know your layouts is the best way to learn how to optimize your UI.

Android Developer Labs World Tour

Late last year, we held a series of developer labs to give you a chance to ask questions and play with some new hardware. One of the most common questions we received was, "When are you going to visit my city?" It's a good question, and we're pleased to answer it today.

The Android team is embarking on a world tour, which will include cities in Europe, North America, and Asia.

At each stop, we'll be delivering an update on the state of the Android platform—including a look at the latest Android hardware. It's a great opportunity to meet like-minded Android app developers, play with the latest Android devices, test your apps, and ask Android team members any questions you might have. You can find out more on the Android Developer Lab site.

Here's the line-up of Android Developer Lab locations for February and March 2010:

North America

  • Austin, Texas – Feb 4
  • Seattle, Washington – Feb 8
  • Waterloo, Ontario, Canada – Feb 8
  • Washington, D.C. – Feb 9
  • Mountain View, California – Feb 10
  • Cambridge, Massachusetts – Feb 11
  • New York, New York – Feb 12

Europe

  • London, UK – Feb 2
  • Paris, France – Feb 8
  • Berlin, Germany – Feb 10
  • Zurich, Switzerland – Feb 12
  • Madrid, Spain – Feb 13

Asia

  • Singapore – Feb 28
  • Taipei, Taiwan – March 3
  • Hong Kong – March 5

If you'd like to attend, you'll need to request a spot by February 1st. Space is limited, so please wait for an email to confirm that you have a spot in the lab.

While we're on the road, we're also going to stop by and speak at the following local Android user groups:

  • Stockholm, Sweden – Feb 4
  • London, UK – Feb 5
  • Chicago, Illinois, USA – Feb 6

We're looking forward to meeting you in person!

Android Icon Guidelines

For our second post in our series on Android UI, we're releasing our Icon Design Guidelines and an Android Icon Templates Pack. These should make it a lot easier for you (or your designer) to develop all the icons your applications need, so they fit with the other icons in the Android environment.

The Icon Design Guidelines document describes how to design and export icons that fit within the Android framework. It includes a wealth of detail about icons in the Home screen, menus, the status bar, tabs, dialogs, and lists.

The Android Icon Templates Pack is a collection of template designs, filters, and settings that make it easier for you to create icons that conform to the general specifications given in this Guidelines document. We recommend downloading the template pack archive before you get started with your icon design.

The Templates Pack provides templates in Adobe Photoshop and Adobe Illustrator file formats, which preserves the layers and design treatments we used when creating the standard icons for the Android platform. You can load the template files into any compatible image-editing program, although your ability to work directly with the layers and treatments may vary based on the program you are using.

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!

Android Layout Tricks #2: Reusing layouts

Android comes with a wide variety of widgets, small visual construction blocks you can glue together to present the users with complex and useful interfaces. However applications often need higher level visual components. A component can be seen as a complex widget made of several simple stock widgets. You could for instance reuse a panel containing a progress bar and a cancel button, a panel containing two buttons (positive and negative actions), a panel with an icon, a title and a description, etc. Creating new components can be done easily by writing a custom View but it can be done even more easily using only XML.

In Android XML layout files, each tag is mapped to an actual class instance (the class is always a subclass of View.) The UI toolkit lets you also use three special tags that are not mapped to a View instance: , and . The latter, , can be used to create pure XML visual components. (Note: I will present the tag in the next installment of Android Layout Tricks.)

The does exactly what its name suggests; it includes another XML layout. Using this tag is straightforward as shown in the following example, taken straight from the source code of the Home application that currently ships with Android:

   

In the only the layout attribute is required. This attribute, without the android namespace prefix, is a reference to the layout file you wish to include. In this example, the same layout is included three times in a row. This tag also lets you override a few attributes of the included layout. The above example shows that you can use android:id to specify the id of the root view of the included layout; it will also override the id of the included layout if one is defined. Similarly, you can override all the layout parameters. This means that any android:layout_* attribute can be used with the tag. Here is an example:

This tag is particularly useful when you need to customize only part of your UI depending on the device's configuration. For instance, the main layout of your activity can be placed in the layout/ directory and can include another layout which exists in two flavors, in layout-land/ and layout-port/. This allows you to share most of the UI in portrait and landscape.

Like I mentioned earlier, my next post will explain the , which can be particularly powerful when combined with .

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.