Profile cover photo
Profile photo
Bobby Hargett
Bobby's posts

Post has shared content
Use a fixed aspect ratio with the Percent Support Library 23.1
Pro-tip by +Ian Lake

The Percent Support Library ( makes it easy to set dimensions and margins in terms of a percentage of the overall space. In the 23.1 release (, it also gained the ability to set a custom aspect ratio via app:layout_aspectRatio.

This allows you to set only a single dimension, such as only the width, and the height will be automatically determined based on the aspect ratio you’ve defined, whether it is 4:3 or 16:9 or even a square 1:1 aspect ratio.

So building a navigation drawer header with a 16:9 background image would look like:
  <!-- The rest of your layout -->

You’ll note we use layout_widthPercent instead of layout_width - this ensures that the height is not erroneously set to 0dp before the first layout pass is done and ensures the aspect ratio is always correctly computed based on the current width.

So how did a 16:9 aspect ratio turn into 178%? Our target 16:9 aspect ratio can also be expressed as a 1.78:1 ratio or equivalently, a width 178% of the height. This is the format the layout_aspectRatio expects.

Of course, you can also define the aspect ratio in separate XML files with code such as:

<item name="header_aspectRatio" type="fraction">178%</item>

This makes it possible to change or reuse them across different form factors or layouts.

Material design designates a number of ratio keylines ( which you can use in your app, but you could also consider using this for list items (where you may be using ?android:attr/listPreferredItemHeight) with items such as a profile image or video thumbnail for a fixed aspect ratio.

You’ll be able to use this with PercentFrameLayout, PercentRelativeLayout, or through any custom ViewGroup using PercentLayoutHelper (

Post has shared content
Make your windowBackground work for you instead of using null
Pro-tip by +Ian Lake

When looking for overdraw in your app, you’ll find that there’s something behind your Views: that default background color is your windowBackground. If you use fullscreen opaque Views, you might be tempted to set your windowBackground to null, but this may lead to even more problems in the form of visual artifacts.

When could a null windowBackground cause visual artifacts? One common case is during the cold start of your app, when the system uses your windowBackground to display a placeholder in the time before your Activity’s setContentView() is called. While calling getWindow().setBackground(null) in your onCreate() gets around that, you may still see artifacts when a keyboard/IME animates in behind where the keyboard appears or with ListViews overscroll behavior.

Instead, consider using your windowBackground. Make sure your windowBackground actually is the background of most of your Activity (particularly over scrollable sections where overdraw is the most important to avoid), removing opaque view backgrounds where possible.

Setting a windowBackground via XML involves just a single line in your theme:
<style name="AppTheme">

Note that this doesn’t preclude you from using a branded launch theme ( - in fact, that also uses the windowBackground precisely because it is what the system draws during cold starts.

Will FreeFlow ever be available on Maven?

Post has attachment
I won candy on the #googlebirthday doodle! Score: 140

Post has attachment
There is still some love is this crazy world of ours. Mashable: 7-Year Old Boy Fighting Brain Cancer Scores 69-Yard Touchdown.
Wait while more posts are being loaded