Posted by Hoi Lam, Developer Advocate

Rushing onto a train, entering a concert, or simply ordering a coffee, we have all seen users (or ourselves) rummaging through their wallets or mobile app trying to get the right boarding pass, ticket or loyalty card. With Android Wear and a few lines of code in your mobile app, this can all work like magic.

What’s new in the Android Support Library

While QR Code images could be attached to a notification since the first release of the Android Wear platform, developers have asked about two situations which they would like to see improve:

1. With circular displays, it is hard for developer to know if the QR code is displayed in it’s entirety and not cropped.
2. To conserve battery, Android Wear switches off the screen after five seconds of inactivity. However, this makes it hard for the user to ensure that the QR code is still displayed on their wrist when they reach the front of the queue.

With the latest support library, we have added two additional methods to WearableExtender to give developers more control over how background images are displayed in notifications. These new APIs can be used in a number of scenarios, we will focus on the QR code use case in this post:

• Ensure the image is not cropped - setHintAvoidBackgroundClipping(true)
With this new method, developers can ensure that the entire QR code is always visible.

Wrong: setHintAvoidBackgroundClipping (false) // this is the Default	Right: setHintAvoidBackgroundClipping (true)

• Ensure the QR code is still displayed when the user gets to the front of the queue - setHintScreenTimeout(timeInMS)
This new method enables developers to set a timeout that makes sense for their specific use case.

Design Best Practices

We have experimented with a number of customization options with QR codes and here are some of the lessons learnt:

Dos

• Do test with your equipment - Before deploying, test with your QR code readers to ensure that the QR code displayed on the wearable works with your equipment.
• Do use black and white QR codes - This ensures maximum contrasts and makes it easier for the reader to read the information.
• Do display only the core information in the text notification - Remember that less is more. Glanceability is important for wearables.
• Do test with both round and square watches - The amount of text can be displayed on the notification varies especially dependent on the form factor (square and circular).
• Do brand with icon - On the main notification in the Android Wear stream, developers can set a full color icon using setLargeIcon to brand your notification.
• Do convey additional information using background - To achieve an even better result, consider setting context sensitive backgrounds through setBackground, such as a photo of the destination for the train or a picture of the stadium.
• Do use QR codes which are 400x400 pixels or larger - In line with other background images, the recommended minimum size for QR code is 400x400 pixels.

Don'ts

• Do not brand the QR code - The screen real estate is limited on Android Wear and using some of this for branding may result in the QR code not working correctly.
• Do not use anything other than grey or default theme color for notification text - Although Android Wear notifications support basic text formatting such as setting text color, this should be used in moderation with the color set to default or grey. The reason is that the Holo theme for Android 4.x has a default background of black whereas Material Design theme for Android 5+ including Android Wear has a white background. This makes it hard for the colour to work for both themes. Bold and Italic are fine formatting choices.

Android Wear is for people on the move

Using QR codes on Android Wear is a very delightful experience. The information that the user needs is right on their wrist at the right time in the right place. With the new APIs, you can now unlock more doors than ever before and give users an easier time with check in on the go.

Sample code can be downloaded from this repository.

Join the discussion on

+Android Developers

Posted by Hoi Lam, Developer Advocate, Android Wear

What’s a better holiday gift than great performance? You’ve got a great watch face idea -- now, you want to make sure the face you’re presenting to the world is one of care and attention to detail.

At the core of the watch face's process is an onDraw method for canvas operations. This allows maximum flexibility for your design, but also comes with a few performance caveats. In this blog post, we will mainly focus on performance using the real life journey of how we optimised the Santa Tracker watch face, more than doubling the number of fps (from 18 fps to 42 fps) and making the animation sub-pixel smooth.

Starting point - 18 fps

Our Santa watch face contains a number of overlapping bitmaps that are used to achieve our final image. Here's a list of them from bottom to top:

1. Background (static)
2. Clouds which move to the middle
3. Tick marks (static)
4. Santa figure and sledge (static)
5. Santa’s hands - hours and minutes
6. Santa’s head (static)

The journey begins with these images...

Large images kill performance (+14 fps)

Image size is critical to performance in a Wear application, especially if the images will be scaled and rotated. Wasted pixel space (like Santa’s arm here) is a common asset mistake:

Before: 584 x 584 = 341,056 pixels	After: 48*226 = 10,848 (97% reduction)

It's tempting to use bitmaps from the original mock up that have the exact location of watch arms and components in absolute space. Sadly, this creates problems, like in Santa's arm here. While the arm is in the correct position, even transparent pixels increase the size of the image, which can cause performance problems due to memory fetch. You'll want to work with your design team to extract padding and rotational information from the images, and rely on the system to apply the transformations on our behalf.

Since the original image covers the entire screen, even though the bitmap is mostly transparent, the system still needs to check every pixel to see if they have been impacted. Cutting down the area results in significant gains in performance. After correcting both of the arms, the Santa watch face frame rate increased by 10 fps to 28 fps (fps up 56%). We saved another 4 fps (fps up 22%) by cropping Santa’s face and figure layer. 14 fps gained, not bad!

Combine Bitmaps (+7 fps)

Although it would be ideal to have the watch tick marks on top of our clouds, it actually does not make much difference visually as the clouds themselves are transparent. Therefore there is an opportunity to combine the background with the ticks.

When we combined these two views together, it meant that the watch needed to spend less time doing alpha blending operations between them, saving precious GPU time. So, consider collapsing alpha blended resources wherever we can in order to increase performance. By combining two full screen bitmaps, we were able to gain another 7 fps (fps up 39%).

Anti-alias vs FilterBitmap flags - what should you use? (+2 fps)

Android Wear watches come in all shapes and sizes. As a result, it is sometimes necessary to resize a bitmap before drawing on the screen. However, it is not always clear what options developers should select to make sure that the bitmap comes out smoothly. With canvas.drawBitmap, developers need to feed in a Paint object. There are two important options to set - they are anti-alias and FilterBitmap. Here’s our advice:

• Anti-alias does not do anything for bitmaps. We often switch on the anti-alias option by default as developers when we are creating a Paint object. However, this option only really makes sense for vector objects. For bitmaps, this has no impact. The hand on the left below has anti-alias switched on, the one on the right has it switched off. So turn off anti-aliasing for bitmaps to gain performance back. For our watch face, we gained another 2 fps (fps up 11%) by switching this option off.

• Switch on FilterBitmap for all bitmap objects which are on top of other objects - this option smooths the edges when drawBitmap is called. This should not be confused with the filter option on Bitmap.createScaledBitmap for resizing bitmaps. We need both to be turned on. The bitmaps below are the magnified view of Santa’s hand. The one on the left has FilterBitmap switched off and the one on the right has FilterBitmap switched on.


Eliminate expensive calls in the onDraw loop (+3 fps)

onDraw is the most critical function call in watch faces. It's called for every drawable frame, and the actual painting process cannot move forward until it's finished. As such, our onDraw method should be as light and as performant as possible. Here's some common problems that developers run into that can be avoided:

1. Do move heavy and common code to a precompute function - e.g. if we commonly grab R.array.cloudDegrees, try doing that in onCreate, and just referencing it in the onDraw loop.
2. Don’t repeat the same image transform in onDraw - it’s common to resize bitmaps at runtime to fit the screen size but this is not available in onCreate. To avoid resizing the bitmap over and over again in onDraw, override onSurfaceChanged where width and height information are available and resize images there.
3. Don't allocate objects in onDraw - this leads to high memory churn which will force garbage collection events to kick off, killing frame rates.
4. Do analyze the CPU performance by using a tool such as the Android Device Monitor. It’s important that the onDraw execution time is short and occurs in a regular period.

Following these simple rules will improve rendering performance drastically.

In the first version, the Santa onDraw routine has a rogue line:

int[] cloudDegrees = 
    getResources().getIntArray(R.array.cloudDegrees);

This loads the int array on every call from resources which is expensive. By eliminating this, we gained another 3 fps (fps up 17%).

Sub-pixel smooth animation (-2 fps)

For those keeping count, we should be 44 fps, so why is the end product 42 fps? The reason is a limitation with canvas.drawBitmap. Although this command takes left and top positioning settings as a float, the API actually only deals with integers if it is purely translational for backwards compatibility reasons. As a result, the cloud can only move in increments of a whole pixel resulting in janky animations. In order to be sub-pixel smooth, we actually need to draw and then rotate rather than having pre-rotate clouds which moves towards Santa. This additional rotation costs us 2 fps. However, the effect is worthwhile as the animation is now sub-pixel smooth.

Before - fast but janky and wobbly

for (int i = 0; i < mCloudBitmaps.length; i++) {
    float r = centerX - (timeElapsed / mCloudSpeeds[i]) % centerX;
    float x = centerX + 
        -1 * (r * (float) Math.cos(Math.toRadians(cloudDegrees[i] + 90)));
    float y = centerY - 
        r * (float) Math.sin(Math.toRadians(cloudDegrees[i] + 90));
    mCloudFilterPaints[i].setAlpha((int) (r/centerX * 255));
    Bitmap cloud = mCloudBitmaps[i];
    canvas.drawBitmap(cloud,
        x - cloud.getWidth() / 2,
        y - cloud.getHeight() / 2,
        mCloudFilterPaints[i]);
}

After - slightly slower but sub-pixel smooth

for (int i = 0; i < mCloudBitmaps.length; i++) {
    canvas.save();
    canvas.rotate(mCloudDegrees[i], centerX, centerY);
    float r = centerX - (timeElapsed / (mCloudSpeeds[i])) % centerX;
    mCloudFilterPaints[i].setAlpha((int) (r / centerX * 255));
    canvas.drawBitmap(mCloudBitmaps[i], centerX, centerY - r,
        mCloudFilterPaints[i]);
    canvas.restore();
}



Before: Integer translation values create janky, wobbly animation. After: smooth sailing!

Quality on every wrist

The watch face is the most prominent UI element in Android Wear. As craftspeople, it is our responsibility to make it shine. Let’s put quality on every wrist!

Join the discussion on

+Android Developers




Source: Android Developers Blog