Jetpack
Kotlin
Docs
News
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
More
Android Developers Blog
The latest Android and Google Play news for app and game developers.
Designing for Multi-Window
11 May 2016
Posted by
Ian Lake
, Developer Advocate
As a developer, there’s a wide range of
features added in Android N
to take advantage of
, but when it comes to
designing
and building your UI, having strong
multi-window support
should be at the forefront.
The primary mode that users will be interacting with multi-window is through
split-screen mode
, which is available on both handheld devices and larger tablets. In this mode, two apps split the available screen space and the user can drag the divider between the two split screens to resize the apps. As you might imagine, this mode offers some unique design challenges beyond what was needed previously.
An even more responsive UI
The lessons learned from previous versions of Android, the mobile web, and desktop environments still apply to Android N. Designing a
responsive UI
is still an important first step towards an amazing multi-window experience.
A responsive UI is one that adapts to the size provided, picking the best representation of the content and the appropriate
navigation patterns
to make a great user experience on any device. Check out the
Building a Responsive UI blog post
for details on how to design and build an effective responsive UI.
Adapting your layout
As you’re designing layouts for the largest and smallest screens and everything in between, it is important to make resizing a smooth and seamless transition as mentioned in the
split screen layout guidelines
. If you already have a similar layout between mobile and tablet, you’ll find much of your work taken care of for you.
However, if your mobile and tablet layouts are vastly different and there’s no way to smoothly transition between the two,
you should not transition between them
when resizing. Instead, focus on making your tablet UI scale down using the same responsive UI patterns. This ensures that users do not have to relearn their UI when resizing your app.
Note that the
minimalHeight
and
minimalWidth
layout attributes
allow you to set a minimum size you want reported to your Activity, but they do
not
mean the user cannot resize your activity smaller - it actually means that your activity will be cropped to the size the user requests, potentially forcing elements of your UI off the screen. Strive to support down to the minimum size of 220x220dp.
Design configurations to consider
While many of the sizes and aspect ratios possible in multi-window are similar to existing devices (1/3rd of a landscape tablet is similar to existing mobile devices in screen size), there are a few configurations that are much more common when considering multi-window.
The first is a 16x9 layout on mobile devices in portrait. In this case, the vertical space is extremely limited. If you have a number of fixed elements stacked on top of one another (a toolbar, scrolling content, and a bottom navigation bar), you might find there’s not actually any room for the scrolling content - the most important part!
The second case to consider is the 34.15% layout on tablets. The very wide aspect ratio in device portrait or very tall aspect ratio in device landscape orientation are more extreme than what is found on existing devices. Consider using your mobile layouts as a starting point for this configuration.
Patterns to avoid
When it comes to multi-window, there are a few patterns you want to avoid entirely.
The first is UI interactions that rely on swiping from the edge of the screen. This has already been somewhat of an issue when it comes to the on screen navigation bar prominent on many devices (such as Nexus devices), but is even more so in split-screen mode. Since there is (purposefully) no way to determine if your activity is on the top or bottom or the left or the right,
don’t make edge swipes the only way to access functionality in your app
. That doesn’t mean you have to avoid them entirely - just make sure there is an alternative. A good example of this is the temporary
navigation drawer
- an edge swipe opens the drawer, but it is also accessible by pressing the hamburger icon in the toolbar.
The second is disabling multi-window entirely. While there are certainly cases where this makes sense (i.e., it is fundamentally an immersive experience such as a game), there are also cases where your activity and any Activities launched from that Activity are
forced
to support multi-window. As mentioned in the
Preparing for Multi-Window blog post
, when you support external apps launching your activity,
your activity inherits the multi-window properties of the calling Activity.
Designing for Multi-Window is designing for every device
Building a responsive UI that reacts to the space available is critical to a great multi-window experience, but it is an exercise that can benefit all of your users across the wide variety of Android devices.
So use this as an opportunity to #BuildBetterApps
Follow the
Android Development Patterns Collection
for more!
Labels
Android O
Android Studio
Design
Develop
Google Play
Archive
January 2022
(2)
December 2021
(8)
November 2021
(4)
October 2021
(15)
September 2021
(11)
August 2021
(7)
July 2021
(15)
June 2021
(9)
May 2021
(18)
April 2021
(10)
March 2021
(12)
February 2021
(11)
January 2021
(3)
December 2020
(7)
November 2020
(7)
October 2020
(7)
September 2020
(9)
August 2020
(18)
July 2020
(18)
June 2020
(18)
May 2020
(4)
April 2020
(7)
March 2020
(9)
February 2020
(9)
January 2020
(3)
December 2019
(8)
November 2019
(12)
October 2019
(11)
September 2019
(5)
August 2019
(9)
July 2019
(8)
June 2019
(6)
May 2019
(15)
April 2019
(10)
March 2019
(11)
February 2019
(5)
January 2019
(6)
December 2018
(11)
November 2018
(9)
October 2018
(13)
September 2018
(5)
August 2018
(13)
July 2018
(9)
June 2018
(16)
May 2018
(16)
April 2018
(8)
March 2018
(8)
February 2018
(7)
January 2018
(9)
December 2017
(9)
November 2017
(13)
October 2017
(14)
September 2017
(11)
August 2017
(19)
July 2017
(11)
June 2017
(13)
May 2017
(21)
April 2017
(12)
March 2017
(14)
February 2017
(11)
January 2017
(12)
December 2016
(17)
November 2016
(16)
October 2016
(9)
September 2016
(6)
August 2016
(7)
July 2016
(12)
June 2016
(14)
May 2016
(16)
April 2016
(14)
March 2016
(8)
February 2016
(8)
January 2016
(9)
December 2015
(9)
November 2015
(13)
October 2015
(19)
September 2015
(15)
August 2015
(13)
July 2015
(9)
June 2015
(8)
May 2015
(10)
April 2015
(10)
March 2015
(12)
February 2015
(8)
January 2015
(3)
December 2014
(9)
November 2014
(13)
October 2014
(11)
September 2014
(6)
August 2014
(2)
July 2014
(9)
June 2014
(10)
May 2014
(4)
March 2014
(4)
February 2014
(3)
January 2014
(2)
December 2013
(3)
November 2013
(2)
October 2013
(7)
September 2013
(2)
August 2013
(5)
July 2013
(5)
June 2013
(4)
May 2013
(9)
April 2013
(3)
March 2013
(2)
February 2013
(3)
January 2013
(3)
December 2012
(5)
November 2012
(3)
October 2012
(3)
September 2012
(1)
August 2012
(1)
July 2012
(2)
June 2012
(5)
May 2012
(1)
April 2012
(5)
March 2012
(5)
February 2012
(5)
January 2012
(5)
December 2011
(7)
November 2011
(7)
October 2011
(5)
September 2011
(5)
August 2011
(3)
July 2011
(7)
June 2011
(2)
May 2011
(5)
April 2011
(6)
March 2011
(8)
February 2011
(8)
January 2011
(4)
December 2010
(8)
November 2010
(3)
October 2010
(4)
September 2010
(7)
August 2010
(6)
July 2010
(10)
June 2010
(11)
May 2010
(11)
April 2010
(2)
March 2010
(3)
February 2010
(2)
January 2010
(5)
December 2009
(7)
November 2009
(5)
October 2009
(5)
September 2009
(8)
August 2009
(2)
July 2009
(1)
June 2009
(2)
May 2009
(5)
April 2009
(12)
March 2009
(5)
February 2009
(8)
January 2009
(3)
December 2008
(3)
November 2008
(1)
October 2008
(4)
September 2008
(6)
August 2008
(4)
June 2008
(1)
May 2008
(5)
April 2008
(4)
March 2008
(5)
February 2008
(2)
January 2008
(5)
December 2007
(3)
November 2007
(5)
Feed
Newsletter
Android Developers
Google Play
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
