Month: December 2013

Glassboard Finds a Home

Published on by Nick Bradbury

A few months ago Glassboard went looking for a home, and I’m  happy to report that a home has been found at Second Gear.

When finding a new owner was first discussed, I was very unsure of the idea. We wouldn’t be just handing over our software to someone else – we’d also be handing over our customers and their data. That was such a concern of mine that I suggested we simply kill the product.

Luckily, clearer heads prevailed, and in the end we found someone we can trust to keep Glassboard going. Best of luck, Justin!

Android Tip: Avoid Hard-coded Sizes

Published on by Nick Bradbury

I often run across Android layouts which use hard-coded margins, padding, and font sizes, like this:

android-layout-hardcoded-sizes

Doing this often leads to inconsistency. Different layouts end up hard-coding different font sizes and margins, making the app appear less polished.

To avoid this, I recommend defining the sizes in values.xml like this:

android-layout-values

And then referring to these sizes in your layouts like this:

android-layout-declared-sizes

If every layout uses only the sizes defined in values.xml, then not only will your app appear more consistent but it will also make it much easier to adjust sizes application-wide.

Un-jank Your Android ListView

Published on by Nick Bradbury

Making a ListView scroll smoothly is a bit of a black art for Android developers, but there are a few simple rules:

  1. Use the View Holder pattern
  2. Do as little work as possible in getView()
  3. Reduce unnecessary overdraw
  4. Flatten the view hierarchy

The View Holder pattern is well known, but that second rule often gets ignored despite having the biggest impact.

Because getView() is called every time a cell is drawn, any extra work done there will slow things down. Things like formatting dates, manipulating bitmaps, querying SQLite, or loading image resources should be moved out of getView() and instead computed and cached prior to the list being populated.

Unnecessary overdraw can be caused when one view covers another one. If both views have a background, both backgrounds will be drawn even if the first is completely covered. The simplest way to find overdraw issues is to enable “Show GPU Overdraw” in the device’s developer options. If you see dark red blocks behind your ListView text after enabling that option, it’s time to work on overdraw. Simply getting rid of unnecessary background colors/drawables can make a huge difference. If you have an activity whose background is completely covered by another view, you may be able to get rid of one layer of overdraw by calling getWindow().setBackgroundDrawable(null) after setContentView() in the activity’s creation.

Flattening the view hierarchy in your layouts not only helps reduces overdraw but also means less work has to be done when the layout is inflated and drawn. When I create an XML layout, I’ll often use a ton of parent views (RelativeLayouts, LinearLayouts, etc.), to make it easier to group things and move them around. But once I’m happy with the layout, I try to remove as many of those parent views as possible.