Rotate your UI
Tags: android, kotlin, foldable
Published: 2022-12-10 12:49:54

Welcome to the second part of *Understanding foldable devices*. Today we will continue looking at ways to hold a foldable and learn how this affects the user interface. As you'll see shortly, the posture significantly influences both position and size of various UI elements.

### Orientation

No matter if the device uses one or two screens when it's open, there will always be a fold or hinge that divides the area into two (usually equal-sized) parts. The fold can either run horizontally or vertically. Which direction will be more common depends on the form factor of the device. For example, the Surface Duo is best hold in portrait mode so its hinge usually runs vertically.

![An unfolded Surface Duo. Different colors mark important areas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/39y8d9ab1zg4rgbtk2lj.png)

The Duo has to equally sized screens. The full display area (green box) is separated by the hinge (red area). Many apps will have an action or app bar (blue box), which shrinks the content area (yellow box) vertically.


![An unfolded and rotated by 90 degrees Surface Duo. Different colors mark important areas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j92s71bpvzum1u0n08e6.png)

When we place the Duo like a laptop, its hinge runs horizontally. In the above picture, the full area is again marked with a green box and the hinge by a red area. As the app features an app bar, the upper part of the content area (a yellow box) is as wide as the second (lower) yellow box, but smaller in height, because of the app bar (blue box).

So, what does this mean? 🤔

Let*s recap.

- A fold or hinge divides the screen area into two parts. Usually these two parts will have the same size, but device manufacturers might come up with a dual screen device that has two differently sized screens or place the fold of a one-screen foldable asymmetrically (for whatever reasons).
- App bars, navigation rails, tab bars, or bottom navigation bars shrink the areas being available for the content
- How this affects the sizes of the two areas depends on the location of that UI element **and** the orientation of the fold or hinge.

Sounds easy enough, right?

Think about it, you want to put your app content into the two yellow boxes, whose location and size depend on something that may change every minute (when the user rotates the device). And there's more. 

### Respect non foldable devices

Please remember that there may not always be *two* yellow boxes. As soon as the user folds the device, there will be just **one**.


![Surface Duo with the second screen folded back](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/km2rkexr7n3lfi93izu0.jpg)

What's important to note: there is no hinge. I mean, yes, there certainly is. But if we ask our Android device it will tell otherwise. 😎 You likely already know that there is a library called **Jetpack WindowManager** which will help us determine such *features*. But please be patient just a little longer, as there is more we need to take into account.

Let's recap.

- A foldable device may report is has a hinge that is running either horizontally or vertically
- If the foldable device is in a certain posture, it may report it has *no* hinge, which essentially makes it an ordinary smartphone or tablet
- Even non foldable devices support two postures; we have been calling them **portrait** or **landscape** mode
- Certainly, these traditional postures affect our UI, too

Well, at least they should. Way too many apps ignore the landscape mode even in late 2022.

Again, take a look.


![Two column mode on a Pixel 6 in landscape mode](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cq13m7che3r0z5l8xyg9.png)

If my sample app runs on a smartphone in landscape mode, it features two columns, too. However, the columns differ from the foldable. 

So, here's an important takeaway: *two columns* doesn't mean *the same two columns on all devices*. On a tablet or other (non foldable) device the layout may (and probably even should) look different.

To illustrate, let's see how *Time Calculator* behaves when running in the Windows subsystem for Android.


![Time Calculator in a smartphone-sized window](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4ic1ghylg3znqdn9v5xd.png)

![Time Calculator in a foldable-sized window](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w7fro2xo4s4nk2rxrxkj.png)

![Time Calculator in a large window](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fxr5ax9itmcxkuvb8set.png)

Above pictures show *Time Calculator* in a smartphone-sized window, a foldable-sized window, and in a large window. The actual layout of the sample is not super important. The point is, optimizing for foldables must not mean we forget about other form factors and sizes. 

### Conclusion

Granted, this may make development a bit more complicated. In the next part we look at how complicated (or not) it gets. In the mean time, feel free to grab the source code of *Time Calculator*. You can find it on [GitHub](https://github.com/tkuenneth/timecalculator). You may also download the app from [Google Play](https://play.google.com/store/apps/details?id=com.thomaskuenneth.zeitrechner).