Foldables and Developers

As you probably heard, Google has announced official support for “foldable” phones. You can unfold a foldable phone and have access to a larger touchscreen, but still have access to a smaller touchscreen when the phone is folded. That announcement ties into Samsung’s shrouded unveiling of a foldable phone, scheduled to be released in 2019. Lots of excited noises came out of the Android Developer Summit about foldables, as Google tries to get developers interested in YAFF (Yet Another Form Factor).

Google has gone the YAFF route previously, of course:

  • Chrome OS
  • Android Things
  • Android Auto
  • Android TV
  • Android Wear/WearOS
  • Google TV
  • Tablets

On the whole, app developers have not paid a lot of attention to YAFFs. Big-brand apps are more likely to support more YAFFs, because with a huge user base they will have quite a few users on all of these (except long-dead Google TV). Certain apps might get support for certain YAFFs, as the form factor lends itself to that particular app’s category (e.g., jogging apps for wearables, streaming media players for TVs). Overall, though, for YAFFs where developers need to opt into being available (TV, wearables, cars, things), few developers bother. For YAFFs where developers need to opt out (tablets, Chrome OS, and soon foldables), few developers bother with that either, but also do not necessarily take steps to ensure that their apps work well on those YAFFs.

IMHO, the foldable YAFF is unlikely to change that, for a few reasons:

  • It is not different enough for many apps to want to target it specifically. Whereas wearables, cars, and TVs have affinities for certain app types, phones and tablets are more “general purpose”. A phone that can transmogrify into a small tablet is still a general-purpose device. Off the top of my head, I cannot think of an app category that would be specifically useful for a foldable but not for a regular tablet or Chrome OS device. As a result, few developers will race towards foldables to be “a big fish in a small pond” with apps specifically aimed for foldables.

  • Foldables are likely to be expensive in the short term. I cannot imagine that Samsung will sell theirs for less than they sell their current flagship devices, at least at the outset. As a result, I am expecting prices to be 1200 USD or higher. Eventually, perhaps foldables will become common enough that they become a standard feature of flagship devices. With luck, foldables will become commonplace and available at lower price points. However, in 2019 and 2020, I expect foldables to be pricey. UPDATE 2018-11-12: Ars Technica reports a possible price tag above 1700 USD.

  • Foldables might be marketed as luxuries in the short term. Foldables are bling. Nobody is going to look at a car and say, “Wow! That’s a really cool container for Android Auto!”. By contrast, foldables are the sort of thing that people will pull out of their pocket/purse/pouch/pontoon just for the sake of showing off. Samsung, in particular, might lean into this approach, specifically pricing their foldable very high and skipping any carrier marketing deals, with an eye towards having their foldable become a status symbol.

  • Foldables are likely to be a small niche in the short term. There are tens of millions of users of Chrome OS and Android tablets… and lots of app developers yawn at those figures. It will be a wonderful day when we can say that there are tens of millions of users of foldables. Depending on pricing and marketing, in 2019 and 2020, it might be closer to tens of thousands of users of foldables. As such, as Gertrude Stein once wrote of the city of Oakland, “there’s no there there” – few developers will be inspired to support foldables when there are so few users.

The good news is that supporting foldables is likely to be not that different than supporting multi-window and configuration changes in general. It appears that we will simply get a configuration change for a new screen size (and perhaps density) when the device moves from a folded to an unfolded state. We already should be dealing with that for existing form factors – the foldable YAFF just adds a few more users that would benefit from our work. If anything, Samsung’s foldable might be simpler than scenarios like Chrome OS, as it appears that Samsung is going to limit the number of simultaneous windows (3 at a time, based on their initial statements).

Foldables might cause other headaches – Samsung’s device has an unusual 21:9 aspect ratio when folded – but these are headaches that we have had to deal with from time to time for years. The fewer assumptions that you make about the device that you run on, the more likely it is that your app will hold up nicely, even when faced with strange device specifications.

It appears that the way that Android is going to handle foldables from an architecture standpoint is to consider them as having two displays, with activities moving from one display to another when unfolded. We have had support for this sort of behavior since Android 8.0, though it has not been that widely used. However, this puts additional pressure on developers to do the right thing: if it involves your UI, always get the information from an Activity. In particular, do not work with resources, Display, or similar objects that you get from an Application singleton. The Activity knows which display it is on and will give you the right resources and display metrics for that display. Application, by constrast, will only know to use the default display (whatever that default might be), which may be substantially different than the display that your Activity appears on.

I am somewhat nervous about “multi-resume”. With current multi-window support on Android, only the window that the user is interacting with is considered to be resumed. All other windows, and their top-most activities, are paused. With “multi-resume”, that distinction vanishes: all windows’ top-most activities are resumed. This is an opt-in behavior for Android 9.0 – both the manufacturer and the developer (via a manifest <meta-data> element) have to agree to allow for multi-resume. However, in an Android Developer Summit presentation, Google indicated that they expect this to be mandatory in Android Q. This will introduce more weird edge cases that we have to deal with, and it does not appear to be really tied to foldables at all.

It is possible that, in the long term, we will look back on the days with rigid non-folding displays the same way that we look back on CRT monitors, dot-matrix printers, and dial-up Internet access. Near-term, foldables are unlikely to “move the needle” much in terms of the characteristics of the Android user base. However, foldables are yet another reason to try to support a wider range of Android devices than simple phones, and the work that you might do with foldables in mind will help many more users than just those who elect to buy a foldable.

Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!