Zigurd Mednieks

Four Simple Rules to Avoid DisplayMetrics Antipatterns in Android Code

Effectively combine characteristics and qualifiers for optimum layouts

The DisplayMetrics Red Flag

A search of GitHub returns more than 42,000 hits for the class name DisplayMetrics. This is a red flag. Although there are safe and valuable uses for this information, a quick look at the code using this class reveals that most programs query it to determine screen dimensions, using code like this:

The programs then make decisions about how the program should present its user interface. This is dangerous, because it tempts the programmer to make decisions with awful long-range consequences, when these decisions should be left up to the Android run-time.

How to Break Lots of Apps in One Easy Step

How dangerous is it? Pull up a random app on your Android device, go to the Settings and select Font Size, then select Huge.

Now see how many apps break:

  • How many have fixed-size views in their layouts where text overflows its bounds?
  • How many “fixed” that bug by setting the font size, and ignoring your preferences?
  • How many make incorrect layout decisions where objects don’t quite fit?
  • How many lock the app’s UI to a landscape or portrait orientation?

When you make your own decisions, based on screen dimension and other parameters, about how to present the user interface, you enter a danger zone that spawns bugs that can easily escape detection in both automated and manual testing. If bugs are caught late in the game, they create pressure to implement lame fixes.

The Only Way To Win Is Not To Play the Game

Aren’t you forced to make decisions about presentation? The answer is “No.” You should not be asking “How high, how wide, how dense, what font,” etc.

You should let Android ask the questions and make decisions about presentation. The only question, then, is how many answers you need to provide. Using multiple layouts for different configurations, and avoiding fixed values in layouts, you can make a system of layouts and let Android choose which layouts to use for different screen sizes and orientations.

Read more…

Comments: 5

Go Native, Go Big, and Go Deep

Android software development at a crossroads

Apps have to get bigger and more ambitious. A key question for the developer community is how do you create big, integrated, multi-functional, configurable apps for the mobile enterprise? Curiously, Facebook is providing some answers by not using HTML5 and not attempting to make a cross-platform app. Go native, go big, and go deep.

Facebook Home is a harbinger of serious mobile apps

Facebook Home has earned positive reviews—in many cases from reviewers who had tired of Facebook and the intrusiveness of Facebook’s privacy policies and practices. Facebook Home is an example of a new kind of Android software development. It spans a variety of functions as a suite of cooperating software. It uses Android’s intent filters, high-level interprocess communication (IPC), shared databases (ContentProvider components) and remote APIs to bond together a software product that replaces many of the standard parts of Android—as they are meant to be replaced.

Facebook Home isn’t some kind of rogue hack, nor is it a “fork” of AOSP, as Kindle Fire is. Facebook Home is a tour de force of correct Android application architecture. It takes over your phone, interface by interface, always playing by the rules, and it does so for justifiable reasons: for putting Facebook’s functionality everywhere you want to perform communications and social media functions.

Going native

Moreover, Facebook Home simply can’t be done on iPhone. iOS has a specific vision of apps that is separate from system software, while Android’s frameworks are the basis of both applications and system software. Facebook Home was built with this difference in mind: It replaces key elements of the Android system user experience. It is a suite of communicating apps. The word “app” doesn’t sufficiently describe it.

Read more…

Comment