한국의 개발자들을 위한 Google for Developers 국문 블로그입니다.
안드로이드 N 멀티윈도우 지원하기
2016년 5월 31일 화요일
게시자:
Ian Lake
, 디벨로퍼 어드보케
다양한
기능들이 Android N에 추가
됩니다. 그 중,
개발자들이 활용
할 수 있는 가장 도드라지는 기능 중 하나가 바로
멀티윈도우 지원
입니다.
Android N은 다양한 멀티윈도우 모드를 지원하지만, 그 중, 스마트폰과 태블릿에서 활용할 수 있는 분할 화면 모드를 잘 지원하는 것이 가장 핵심이 될 것입니다. 이 모드에서는 두 개의 앱이 동시에 실행될 수 있으며, 사용자가 나누어져 있는 두 화면 사이의 칸막이를 끌어 앱의 크기를 조절할 수 있습니다. 네. 예상하신 것처럼, 이 모드를 올바르게 지원하기 위해서는 지금까지와는 다른 디자인상의 도전적 과제를 해결해야 합니다.
훨씬 더 빠르게 반응하는 UI
이전 버전의 Android, 모바일 웹, 그리고 데스크톱 환경에서 배운 교훈들이 Android N에도 여전히 적용되고 있습니다.
반응형 UI
를 디자인하는 것이 멀티윈도우 환경 지원을 향한 중요한 첫 걸음입니다.
반응형 UI란 어떤 기기나 화면 크기에서도 훌륭한 사용자 환경을 창출하기 위해 가장 적절한
탐색 패턴
과 콘텐츠 표현 양식이 선택될 수 있게 주어진 사이즈에 적응하는 UI입니다. 다음 블로그 게시물에
반응형 UI 빌드하기
에서 효과적인 반응형 UI 디자인과 빌드 방법에 대해 자세히 알아보세요.
레이아웃 조정
어떤 사이즈의 화면을 디자인하든, 화면 크기가 변화될 때 발생하는 이벤트 처리를
분할 화면 레이아웃 가이드라인
에 설명된 것처럼 매끄럽고 끊김 없이 넘어가도록 만드는 것이 중요합니다. 이미 모바일과 태블릿 간에 비슷한 레이아웃을 가지고 있다면, 상당히 많은 작업들이 자동으로 처리되어 있는 것을 알게 될 것입니다.
하지만 모바일과 태블릿의 레이아웃이 서로 크게 다르다면, 사용자가 화면 크기를 조정할 때 마다 앱의 UI가 크게 변경되거나 서로 뒤섞이지 않도록 주의해야합니다. 사용자들이 앱의 크기를 조절할 때 마다 UI에 대해 다시 배울 필요가 없도록 해야 합니다.
minimalHeight
와
minimalWidth
레이아웃 특성
을 통해 액티비티가 지원할 수 있는 최소 크기를 설정할 수 있지만,
이것이 사용자가 액티비티를 해당 값 보다 더 작게 만들 수 없다는 의미는 아닙니다.
사용자가 화면 크기를 더 작게 만들면, 지정된 최소 크기외의 앱의 다른 부분은 잘려나간다는 것을 의미합니다. 따라서, 필수적인 UI의 요소들이 화면에 표시되지 못할 수도 있습니다. 그러므로, 언제나 사용자가 여러분의 앱의 핵심 기능을 불편함없이 사용할 수 있도록, 최소 크기 220x220dp까지는 지원하도록 해야 할 것입니다.
고려할 디자인 구성
멀티윈도우에서 가능한 크기 및 가로 세로의 비율 중 많은 것들이 기존의 기기와 비슷하지만(가로 방향 태블릿의 1/3이 기존 모바일 기기와 화면 크기가 비슷함), 멀티윈도우를 고려할 때 훨씬 더 보편적인 구성이 몇 가지 있습니다.
첫째는 세로 방향 모바일 기기에서의 16x9 레이아웃입니다. 이 경우 세로 공간이 극히 제한됩니다. 차곡차곡 쌓여있는 고정 요소들이 많이 있을 경우(툴바, 콘텐츠 스크롤, 하단의 탐색 모음), 사실상 스크롤하는 콘텐츠를 위한 공간이 없다는 것을 발견할 것입니다. 이게 가장 중요한 부분인데 말이죠!
두 번째로 고려해야 할 경우는 태블릿의 34.15% 레이아웃입니다. 세로 방향 기기에서는 매우 넓고, 가로 방향 기기에서는 매우 높은 이 가로 세로 비율은 기존의 기기에서 볼 수 있는 것보다 더 심각합니다. 이 구성을 위한 출발점으로 모바일 레이아웃을 사용하는 것을 고려해 보세요.
피해야 할 패턴
멀티윈도우 디자인에서 전적으로 피해야 할 몇 가지 패턴이 있습니다.
첫째, 화면 가장자리로부터의 스외이프에 의존하는 UI입니다. 이는 (Nexus 기기 등의) 많은 기기에서 두드러진 화상 탐색 모음의 경우 이미 어느 정도 이슈가 되었었는데, 분할 화면 모드에서는 더 큰 문제가 됩니다. 액티비티가 맨 위에 있는지 맨 아래에 있는지, 왼쪽에 있는지 오른쪽에 있는지 (단호하게) 판단할 길이 없으므로
앱에서 가장자리 스와이프를 기능에 액세스하는 유일한 방법으로 삼지 마세요.
그렇다고 가장자리 스와이프를 완전히 사용하지 말라는 뜻은 아닙니다. 반드시 대안을 마련하라는 겁니다. 이것의 좋은 예는
탐색 서랍
버튼입니다. 가장자리 스와이프로 서랍을 열지만, 툴바에서 햄버거 아이콘을 눌러서 열 수도 있습니다.
두 번째는 멀티윈도우를 완전히 비활성화하는 것입니다. 이 방법을 피할 수 없는 경우가 분명히 있지만(게임 등에서처럼 근본적으로 몰입적인 경험이 되므로), 여러분의 액티비티와 그 액티비티로부터 시작된 액티비티가 멀티윈도우를 지원하도록
강요되는
경우도 있습니다.
멀티윈도우 준비하기
란 제목의 블로그 게시물에서 언급했듯이, 외부 앱에서 액티비티가 시작되도록 지원할 경우,
그 액티비티는 호출하는 액티비티의 멀티윈도우 속성을 상속합니다.
멀티윈도우 디자인은 모든 기기를 위한 디자인
반응형 UI는 개발은 훌륭한 멀티윈도우 환경을 위해서도 매우 중요하지만, 근본적으로 다양한 Android 기기에 걸쳐 모든 사용자들에게 혜택을 줄 수 있는 지침입니다.
그러므로 이것을 #BuildBetterApps의 기회로 삼으십시오.
Android 개발 패턴 모음
을 팔로우하여 더 자세히 알아보세요!
Contents
ML/Tensorflow
Android
Flutter
Web/Chrome
Cloud
Google Play
Community
Game
Firebase
검색
Tag
인디게임페스티벌
정책 세미나
창구프로그램
AdMob
AI
Android
Android 12
Android 12L
Android 13
Android 14
Android Assistant
Android Auto
Android Games
Android Jetpack
Android Machine Learning
Android Privacy
Android Studio
Android TV
Android Wear
App Bundle
bootcamp
Business
Chrome
Cloud
Community
compose
Firebase
Flutter
Foldables
Game
gdg
GDSC
google
Google Developer Student Clubs
Google Play
Google Play Games
Interview
Jetpack
Jetpack Compose
kotlin
Large Screens
Library
ma
Material Design
Material You
ML/Tensorflow
mobile games
Now in Android
PC
Play Console
Policy
priva
wa
wear
Wearables
Web
Web/Chrome
Weeklyupdates
WorkManager
Archive
2024
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2023
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2022
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2021
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2020
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2019
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2018
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2017
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2016
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2015
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2014
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2013
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2012
12월
11월
10월
9월
8월
7월
6월
5월
3월
2월
1월
2011
12월
11월
Feed