Material Design on Android Checklist

Android 5.0 brings in material design as the new design system for
the platform and system apps. Consumers will soon start getting Android
5.0 and they’re already seeing glimpses of material design with apps
like Google Play Newsstand, Inbox by Gmail and Tumblr. Meanwhile, developers now have the Android 5.0 SDK, along with AppCompat for backward compatibility. And designers now have access
to Photoshop, Illustrator and Sketch templates. All this means that
now—yes now!—is the time to start implementing material design in your
Android apps. Today, let’s talk about what implementing material design
really boils down to.

Below, you’ll find a material design checklist
that you can use to mark progress as you implement the new design
system. The checklist is divided into 4 key sections based on the 4 key
aspects of material design.

If you include a good chunk of the items in the checklist below,
especially the ones indicated as signature elements, and follow
traditional Android design best practices (i.e. these, these, and things we discussed on ADiA), you’ll be well on your way to material design awesomeness!

Tangible Surfaces

UIs consist of surfaces (pieces of “digital paper”) arranged at varying elevations, casting shadows on surfaces behind them.

Figure 1.
Surfaces and layering.

• Signature element: Shadows are used to communicate which surfaces are in front of others, helping focus attention and establish hierarchy. Read more on depth and layering in UIs.
  
  In code: This is the android:elevation and android:translationZ attribute in Android 5.0. On earlier versions, shadows are normally provided as PNG assets.
• Shadows and surfaces are used in a consistent and structured way.
  Each shadow indicates a new surface. Surfaces are created thoughtfully
  and carefully.
• There are generally between 2 and 10 surfaces on the screen at once; avoid too much layering/nesting of surfaces.
• Scrollable content either scrolls to the edges of the screen or
  behind another surface that casts a shadow over the content’s surface.
  Never clip an element against an invisible edge—elements don’t just
  scroll off into nowhere. Put another way, you rarely scroll the ink on a
  surface; you scroll the surface itself.
  
  In code: android:clipToPadding=false often helps with this when using ListView and ScrollView.
• Surfaces have simple, single-color backgrounds.

A Bold, Print-Like Aesthetic

The “digital ink” you draw on those pieces of digital paper is informed
by classic print design, with an emphasis on bold use of color and type,
contextual imagery, and structured whitespace.

Figure 2.
Primary and accent colors.


Figure 3.
Keylines.

• Signature element: Apps use a primary color and an accent color
  (Figure 2) to color surface backgrounds and key UI widgets such as text
  fields and checkboxes. The accent color contrasts very well with the
  primary color (for example an app can use a dark blue primary color and a
  neon pink accent color). The accent color is high-contrast and is used
  to call attention to key UI elements, like a circular floating action
  button, selected tab strips, or form fields.
  
  In code: Set the android:colorPrimary and android:colorAccent attributes in your theme (drop the android prefix if using AppCompat). AppCompat automatically colors text fields, checkboxes, and more on pre-L devices.
• Signature element: On Android
  5.0, the status bar is colored to match the app’s primary color, or the
  current screen’s content. For full-bleed imagery, the status bar can be
  translucent.
  
  In code: Set the android:colorPrimaryDark or android:statusBarColor attribute in your theme (drop the android prefix if using AppCompat) or call Window.setStatusBarColor.
• Icons, photos/images, text, and other foreground elements are
  colored “ink” on their surfaces. They don’t have shadows and don’t use
  gradients.
• Colors extracted from images can be used to color adjacent UI elements or surfaces.
  
  In code: This can be done using the Palette support library.
• Signature element: Icons in the app follow the system icon guidelines, and standard icons use the material design icon set.
• Photos are generally immersive and full-bleed. For example, for detail screens, run edge-to-edge and can even appear behind the app bar or status bar.
  
  In code: The new Toolbar widget (and its AppCompat equivalent) can be transparent and placed directly in your layout. For the status bar, check this Stack Overflow post.
• Signature element: Where appropriate, elements like body text, thumbnails, app bar titles, etc. are aligned to 3 keylines
  (Figure 3). On phones, those keylines are 16dp and 72dp from the left
  edge and 16dp from the right edge of the screen. On tablets those values
  are 24dp and 80dp.
• UI elements are aligned to and sized according to an 8dp baseline
  grid. For example, app bars are 56dp tall on phones and 64dp tall on
  tablets. Padding and margins can take on values like 8dp, 16dp, 24dp,
  etc. More precise text positioning uses a 4dp grid.

Authentic Motion

Motion helps communicate what’s happening in the UI, providing visual
continuity across app contexts and states. Motion also adds delight
using smaller-scale transitions. Motion isn’t employed simply for
motion’s sake.

Figure 4.
"Hero" transitions.

• In general, UI and content elements don’t just appear or disappear—they animate into place, either together as a unit, or individually.
• Signature element: When touching
  an item to see its details, there’s a “hero” transition (Figure 4) that
  moves and scales the item between its position in the browsing screen
  and its position in the detail screen.
  
  In code: These are called “shared element transitions” in the SDK. The support version of FragmentTransaction also includes some shared element support.
• Signature element: Ripple effects originating from where you touched the screen are used to show touch feedback on an item.
  
  In code: The default android:selectableItemBackground and android:selectableItemBackgroundBorderless have this, or you can use RippleDrawable (<ripple>) to customize the effect. On pre-5.0 devices, ripples aren’t an expected feature, so defer to the default android:selectableItemBackground behavior.
• Signature element: UI elements can appear using a circular “reveal” animation.
  
  In code: See this doc or the ViewAnimationUtils class for more.
• Signature element: Animations are used in more subtle, delightful ways, such as to convey the transition between icon states
  or text states. For example, a “+” icon can morph into an “x” symbol,
  or an outlined heart icon can be filled using a paint-bucket fill
  effect.
  
  In code: Icon transitions can be implemented using AnimatedStateListDrawable and its XML counterpart. An example can be found in the Google I/O app source. There’s also support for animated vector icons.
• Animations and transitions are fast—generally under 300ms.
• Crossfades are often replaced by translate/slide transitions:
  vertical slides for descendant navigation and horizontal slides for
  lateral navigation. For slide transitions, prefer quick acceleration and
  gentle ease-in deceleration over simple linear moves. See the material
  design spec on motion for more.

Adaptive Design (and UI Patterns)

Tangible surfaces, bold graphic design, and meaningful motion work
together to bring a consistent experience across any screen, be it
phones, tablets, laptops, desktops, TVs, wearables, or even cars.
Additionally, the key UI patterns below help establish a consistent
character for the app across devices.

Figure 5.
The floating action button.

• The app uses responsive design best practices to ensure screens lay themselves out appropriately on any screen size, in any orientation. See the Tablet App Quality Checklist for a list of ways to optimize for tablets, and this blog post for high-level tablet optimization tips.
  
  • In material design, detail screens are often presented as popups that appear using “hero” transitions (see above).
  • In multi-pane layouts, the app can use multiple toolbars to place actions contextually next to their related content.
• Signature element: Where appropriate, the app promotes the key action on a screen using a circular floating action button
  (FAB). The FAB (Figure 5) is a circular surface, so it casts a shadow.
  It is colored with a bright, accent color (see above). It performs a
  primary action such as send, compose, create, add, or search. It floats
  in front of other surfaces, and is normally at an 8dp elevation. It
  frequently appears at the bottom right of the screen, or centered on an
  edge where two surfaces meet (a seam or a step).
  

App bar

• Signature element: The app uses a
  standard Android app bar. The app bar doesn’t have an app icon. Color
  and typography are used for branding instead. The app bar casts a shadow
  (or has a shadow cast on it by a surface below and behind it). The app
  bar normally has a 4dp elevation.
  
  In code: Use the new Toolbar widget in Android 5.0 that is placed directly into the activity’s view hierarchy. AppCompat also provides android.support.v7.widget.Toolbar, which supports all modern platform versions.
• The app bar might be for example 2 or 3 times taller than the
  standard height; on scroll, the app bar can smoothly collapse into its
  normal height.
• The app bar might be completely transparent in some cases, with the text and actions overlaying an image behind it. For example, see the Google Play Newsstand app.
• App bar titles align to the 2nd keyline (see more info on keylines above)
  
  In code: when using the Toolbar widget, use the android:contentInsetStart attribute.
• Where appropriate, upon scrolling down, the app bar can scroll off
  the screen, leaving more vertical space for content. Upon scrolling back
  up, the app bar should be shown again.

Tabs

Figure 6.
Tabs with material design.

• Signature element: Tabs follow the newer material design interactions and styling (Figure 6). There are no vertical separators between tabs. If the app uses top-level tabs, tabs are visually a part of the app bar; tabs are a part of the app bar’s surface.
  
  In code: See the SlidingTabsBasic sample code in the SDK or the Google I/O app source (particularly the "My Schedule" section for phones).
• Tabs should support a swipe gesture for moving between them.
  
  In code: All tabs should be swipeable using the ViewPager widget, which is available in the support library.
• Selected tabs are indicated
  by a foreground color change and/or a small strip below the tab text
  (or icon) colored with an accent color. The tab strip should smoothly
  slide as you swipe between tabs.

Navigation drawer

Figure 7.
Navigation drawers
with material design.

• Signature element: If the app
  uses a navigation drawer, it follows the newer material design
  interactions and styling (Figure 7). The drawer appears in front of the
  app bar. It also appears semitransparent behind the status bar.
  
  In code: Implement drawers using the DrawerLayout widget from the support library, along with the new Toolbar widget discussed above. See this Stack Overflow post for more.
• Signature element: The leftmost icon in the app bar is a navigation drawer indicator;
  the app icon is not visible in the app bar. Optionally, on earlier
  versions of the platform, if the app has a drawer, the top-left icon can
  remain the app icon and narrower drawer indicator, as in Android 4.0.
• The drawer is a standard width: No wider than 320dp on phones and
  400dp on tablets, but no narrower than the screen width minus the
  standard toolbar height (360dp - 56dp = 304dp on the Nexus 5)
• Item heights in the drawer follow the baseline grid: 48dp tall rows, 8dp above list sections and 8dp above and below dividers.
• Text and icons should follow the keylines discussed above.

More and more apps from Google and across the Google Play ecosystem
will be updating with material design soon, so expect Winter 2014 to be a
big quarter for design on Android. For more designer resources on
material design, check out the DesignBytes series. For additional developer resources, check the Creating Apps with Material Design docs!

Read More

Tips for integrating with Google Accounts on Android

Happy Tuesday! We've had a few questions come
in recently regarding Google Accounts on Android, so we've put this post
together to show you some of our best practices. The tips today will
focus on Android-based authentication, which is easily achieved through
the integration of Google Play services. Let's get started.

Unique Identifiers

A common confusion happens when developers use the account name
(a.k.a. email address) as the primary key to a Google Account. For
instance, when using GoogleApiClient to sign in a user, a developer might use the following code inside of the onConnected callback for a registered GoogleApiClient.ConnectedCallbacks listener:

[Error prone pseudocode]

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
// createLocalAccount() is specific to the app's local storage strategy.
createLocalAccount(accountName);

While it is OK to store the email address for display or caching purposes, it is possible for users to change
the primary email address on a Google Account. This can happen with
various types of accounts, but these changes happen most often with Google Apps For Work accounts.

So what's a developer to do? Use the Google Account ID (as opposed to
the Account name) to key any data for your app that is associated to a
Google Account. For most apps, this simply means storing the Account ID
and comparing the value each time the onConnected callback is invoked to
ensure the data locally matches the currently logged in user. The API
provides methods that allow you to get the Account ID from the Account
Name. Here is an example snippet you might use:

[Google Play Services 6.1+]

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
createLocalAccount(accountID);

[Earlier Versions of Google Play Services (please upgrade your client)]

Person currentUser = Plus.PeopleApi.getCurrentPerson(mGoogleApiClient);
String accountID = currentUser.getID();
createLocalAccount(accountID);

This will key the local data against a Google Account ID, which is
unique and stable for the user even after changing an email address.

So, in the above scenario, if your data was keyed on an ID, you
wouldn’t have to worry if your users change their email address. When
they sign back in, they’ll still get the same ID, and you won’t need to
do anything with your data.

Multiple Accounts

If your app supports multiple account connections simultaneously (like the Gmail user interface shown below), you are calling setAccountName on the GoogleApiClient.Builder
when constructing GoogleApiClients. This requires you to store the
account name as well as the Google Account ID within your app. However,
the account name you’ve stored will be different if the user changes
their primary email address. The easiest way to deal with this is to
prompt the user to re-login. Then, update the account name when
onConnected is called after login. Any time a login occurs you, can use
code such as this to compare Account IDs and update the email address
stored locally for the Account ID.

[Google Play Services 6.1+]

String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
// isExistingLocalAccount(), createLocalAccount(), 
// getLocalDataAccountName(), and updateLocalAccountName() 
// are all specific to the app's local storage strategy.
boolean existingLocalAccountData = isExistingLocalAccount(accountID);
if (!existingLocalAccountData) {
    // New Login.
    createLocalAccount(accountID, accountName);
} else {
    // Existing local data for this Google Account.
    String cachedAccountName = getLocalDataAccountName(accountID);    
    if (!cachedAccountName.equals(accountName)) {
        updateLocalAccountName(accountID, accountName);
    }
}

This scenario reinforces the importance of using the Account ID to store data all data in your app.

Online data

The same best practices above apply to storing data for Google
Accounts in web servers for your app. If you are storing data on your
servers in this manner and treating the email address as the primary
key:

ID [Primary Key]	Field 1	Field 2	Field 3
user1@gmail.com	Value 1	Value 2	Value 3

You need to migrate to this model where the primary key is the Google Account ID.:

ID [Primary Key]	Email	Field 1	Field 2	Field 3
108759069548186989918	user1@gmail.com	Value 1	Value 2	Value 3

If you don't make Google API calls from your web server, you might be
able to depend on the Android application to notify your web server of
changes to the primary email address when implementing the
updateLocalAccountName method referenced in the multiple accounts sample
code above. If you make Google API calls from your web server, you
likely implemented it using the Cross-client authentication and can detect changes via the OAuth2 client libraries or REST endpoints on your server as well.

Conclusion

When using Google Account authentication for your app, it’s
definitely a best practice to use the account ID, as opposed to the
account name to distinguish data for the user. In this post, we saw
three scenarios where you may need to make changes to make your apps
more robust. With the growing adoption of Google for Work, users who are
changing their email address, but keeping the same account ID, may
occur more frequently, so we encourage all developers to make plans to
update their code as soon as possible.

Read More

The fastest route between voice search and your app | Android Developers Blog

The fastest route between voice search and your app | Android Developers Blog

Read More

Your Chance to be on TV!

We’re excited to see the launch of Nexus Player,
the first consumer streaming media player running Android TV. Android
TV delivers an entertainment experience tailored for users, including
movies, shows, games and more.
Now is a great time to develop apps for Android TV that reach a whole new audience.

Starting today, you can publish your apps for Android TV on Google Play,
the largest digital store for apps and games. We’ve provided guidance
on how to get started building great apps for Android TV in this post.

"Google
has done an insanely good job to ease the developer’s task of creating a
TV application, mainly thanks to the Leanback support library. It
literally takes 2 hours to create a fully working and possibly fancy
app, which is awesome."



- Sebastiano Gottardo

A high bar for quality experiences

We want to offer the best possible experience for users to enjoy your
apps and games. To make this possible, your Android TV app must meet the basic requirements for usability. When your app meets these requirements, users will be able to discover and download it directly on their Android TV devices.

Even if you have already uploaded your app to the Google Play
Developer Console, you will need to add TV graphics and screenshots, and
opt-in to distribution on TV on the Pricing & Distribution page.
For complete information about the requirements and process of
publishing your Android TV app for Google Play, make sure to check out
the publishing documentation.

Get started!

With our Leanback Library we’ve made it easy for you to extend your
existing app to the TV screen or even build a completely new app for
Android TV. For a quick look at the Leanback Library, check out this DevBytes video.

We’ve only begun scratching the surface of what’s possible with this
new form factor, and we are very excited to see what you will build, start developing today!

Read More

Going Global: Space Ape Games Finds Success in Japan | Android Developers Blog

Going Global: Space Ape Games Finds Success in Japan | Android Developers Blog

Read More

Introducing a New Guide, “The Secrets to App Success on Google Play” | Android Developers Blog

Introducing a New Guide, “The Secrets to App Success on Google Play” | Android Developers Blog

Read More

Improved Game Testing with Google Play Games Management API

We’re always looking to help developers improve the gaming experience
for their users on Google Play. So today, we've expanded our existing
suite of Management APIs
to let you fully control all resources in your Google Play
Games-enabled game during development and testing, with better support
for alpha and beta groups.

Let’s take a quick dive into the expanded offering.

• Reset a single tester’s state for any resource (e.g.,
  achievements, leaderboards), or do it for all resources at once. For
  example, you can now completely reset a given tester’s data if they’ve
  ended up in a bad state due to an experimental build. You can do this
  for individual instances or all instances of achievements, events,
  quests, or leaderboards scores.
• Reset the state of a single draft resource for all testers,
  or do it for all draft resources at once. You can now reset all draft
  leaderboards in your game before publishing with a single API call. This
  ensures the members of your alpha or beta communities don’t have an
  unfair advantage on release day. You can do this for individual
  instances or all instances of achievements, events, quests, or
  leaderboards scores.
• Clear global match state for all real time or turn based
  matches composed solely of testers. You can now reset all turn-based
  matches on release day. This will ensure that all matches from that
  point on are on the release version of the game. This is available for
  both real-time or turn-based games.

These updates make it far less complex and error prone to manage data
during testing, saving you time and improving the rate at which you can
make and test changes to your games.

Play Games Management API background

The Management API is a set of tools that enable developers to do
things like manage tester data and clean up bogus leaderboard score
submissions. Developers can also use the API to control and manipulate
resources (e.g., achievements, events, multiplayer match data).

Getting started

You can get started with the latest version of the Management API right now. Review the updated API reference documentation, start with an example management interface, or download the sample client libraries to get on your way.

Read More