[Android] Say Goodbye to the Menu Button

원본 : http://goo.gl/S9Fem

Say Goodbye to the Menu Button(Posted by Tim Bray on 26 January 2012 at 12:10 PM)

[This post is by Scott Main, lead tech writer for developer.android.com. — Tim Bray]

 

Before Android 3.0 (Honeycomb), all Android-powered devices included a dedicated Menu button. As a developer, you could use the Menu button to display whatever options were relevant to the user, often using the activity’s built-in options menu. Honeycomb removed the reliance on physical buttons, and introduced the ActionBar class as the standard solution to make actions from the user options immediately visible and quick to invoke. In order to provide the most intuitive and consistent user experience in your apps, you should migrate your designs away from using the Menu button and toward using the action bar. This isn’t a new concept — the action bar pattern has been around on Android even before Honeycomb — but as Ice Cream Sandwich rolls out to more devices, it's important that you begin to migrate your designs to the action bar in order to promote a consistent Android user experience.

 

안드로이드 3.0이전에 출시된 모든 안드로이드 기반의 디바이스들은 전용 메뉴버튼을 포함하였습니다. 개발자로서 당신은 자주 사용되는 액티비티에 종속적인 옵션메뉴와 관련있는 옵션들을 출력하기 위해 메뉴버튼을 사용할 수 있습니다. 허니컴은 물리적인 버튼에 대한 의존성을 제거하였고 사용자의 옵션들을 즉시 보여주고 빠르게 사용할 수 있는 표준 솔루션으로서 액션바 클래스를 소개하였습니다. 이해하기 쉽고 어플리케이션에서의 사용자 경험이 극대화 될수 있도록 당신은 액션바를 사용하여 메뉴버튼의 사용과 방향에 대한 설계적인 측면을 마이그레이션 해야 합니다. 이것은 새로운 컨셉트가 아닙니다 - 액션바 패턴은 허니컴 이전부터 계속 안드로이드에 있어왔습니다. - 그러나 ICS에 와서 더 많은 디바이스에 적용되게 되었습니다. 당신이 일관된 안드로이드 사용자 경험을 촉진하기 위해 액션바 설계를 마이그레이션하기 시작하는 것은 중요합니다.

 

You might worry that it’s too much work to begin using the action bar, because you need to support versions of Android older than Honeycomb. However, it’s quite simple for most apps because you can continue to support the Menu button on pre-Honeycomb devices, but also provide the action bar on newer devices with only a few lines of code changes.

 

당신은 아마도 액션바를 사용하는 것을 시작함에있어 너무 많은 작업량이 있을까 걱정할지 모릅니다. 왜냐하면 당신은 허니컴보다 오래된 안드로이드 버전에 대한 지원이 필요하기 때문이죠. 당신은 허니컴 이전의 디바이스에 대한 메뉴버튼에 대해 지속적인 지원할 수 있기때문에 대부분의 어플리케이션에서는 꽤나 간단합니다.

 

If I had to put this whole post into one sentence, it’d be: Set targetSdkVersion to 14 and, if you use the options menu, surface a few actions in the action bar with showAsAction="ifRoom".

 

이 모든 포스트를 한줄요약해보면 targetSdkVersion을 14로 맞추고, 만약에 당신이 옵션메뉴를 사용한다면 showAsAction="ifRoom"을 잉요해 액션바에서의 몇개의 액션들은 나타내세요.

 

Don’t call it a menu

 

Not only should your apps stop relying on the hardware Menu button, but you should stop thinking about your activities using a “menu button” at all. Your activities should provide buttons for important user actions directly in the action bar (or elsewhere on screen). Those that can’t fit in the action bar end up in the action overflow.

 

하드웨어 메뉴버튼에 의존하는 것을 중지해야 할뿐 아니라, "메뉴버튼"을 사용하는 당신의 액티비티들에 대해서 아무런 생각을 하지 말아야 합니다. 당신의 액티비티들은 액션바에서의(또는 다른 곳에서의) 중요한 사용자 액션들을 직접적으로 버튼으로 제공해야 합니다. 액션바에 알맞지 않는 것들은 액션 오버플로우에서 이루어져야 합니다.

(스크린샷 생략)

In the screenshot here, you can see an action button for Search and the action overflow on the right side of the action bar.

 

여기 스크린샷이 있는데, 당신은 검색을 위한액션 버튼과 액션바 우측의 액션오버플로우를 보실 수 있습니다.

 

Even if your app is built to support versions of Android older than 3.0 (in which apps traditionally use the options menu panel to display user options/actions), when it runs on Android 3.0 and beyond, there’s no Menu button. The button that appears in the system/navigation bar represents the action overflow for legacy apps, which reveals actions and user options that have “overflowed off the screen.”

 

당신의 어플리케이션이 3.0 보다 오래된 버전의 안드로이드(사용자의 옵션/액션들은 메뉴패널을 이용하여 전통적으로 출력하는)를 지원하여 만들어졌다고 하더라도, 그것이 안드로이드 3.0과 그 이후버전에서 실행될때 그곳에는 어떠한 메뉴버튼도 없습니다. 시스템/네비게이션바 상에서 나타나는 버튼은 대대로 내려오는 어플리케이션들을 위한 액션 오버플로우를 대표합니다. 이것들은 액션들과 "화면에서 넘치는" 사용자 옵션을 나타냅니다.

 

This might seem like splitting hairs over terminology, but the name action overflow promotes a different way of thinking. Instead of thinking about a menu that serves as a catch-all for various user options, you should think more about which user options you want to display on the screen as actions. Those that don't need to be on the screen can overflow off the screen. Users can reveal the overflow and other options by touching an overflow button that appears alongside the on-screen action buttons.

 

이것은 마치 전문용어를 시시콜콜 따지는 것 같지만, 액션 오버플로우라는 이름은 생각의 방향을 다르게 촉진시킵니다. 사용자 옵션들을 위한 잡동사니 바구니처럼 제공되는 메뉴에 대한 생각과는 반대로 당신은 액션으로서 화면상에 나타낼 사용자 옵션들에 대해 더 많이 생각해야 합니다. 화면상에 나타나지 않아도 되는것들은 화면상에서 숨길 수 있습니다. 사용자는 화면상의 액션 버튼과 나란히 나타나는 오버플로우 버튼을 눌러 오버플로우 메뉴 및 기타 옵션들을 확인 할 수 있습니다.

 

Action overflow button for legacy apps

 

If you’ve already developed an app to support Android 2.3 and lower, then you might have noticed that when it runs on a device without a hardware Menu button (such as a Honeycomb tablet or Galaxy Nexus), the system adds the action overflow button beside the system navigation.

 

만약 당신이 이미 안드로이드 2.3 과 그 이하 버전을 지원하는 어플리케이션의 개발이 완료되었다면, 그렇다면 당신은 하드웨어 메뉴버튼이 없는 디바이스(예를들면 허니컴 태블릿이나 갤럭시 넥서스)에서 그것이 동작하는 경우에 대해서 눈치챘을 겁니다. 시스템은 시스템 네비게이션 옆으로 액션 오버플로우 버튼을 추가하게 됩니다.

(스크린샷 생략) 

This is a compatibility behavior for legacy apps designed to ensure that apps built to expect a Menu button remain functional. However, this button doesn’t provide an ideal user experience. In fact, in apps that don’t use an options menu anyway, this action overflow button does nothing and creates user confusion. So you should update your legacy apps to remove the action overflow from the navigation bar when running on Android 3.0+ and begin using the action bar if necessary. You can do so all while remaining backward compatible with the devices your apps currently support.

 

이것은 메뉴버튼을 기능적으로 남겨 사용되도록 설계된 전통적인 어플리케이션에서도 동작이 가능하도록 합니다. 그러나 이 버튼은 완벽한 사용자 경험을 제공하지 않습니다. 사실 어찌되었든 옵션메뉴를 사용하지 않고, 이 액션 오버플로우 버튼이 아무런 동작도 하지 않는 어플리케이션이라면 사용자에게 혼란만 가져올 것 입니다.

 

If your app runs on a device without a dedicated Menu button, the system decides whether to add the action overflow to the navigation bar based on which API levels you declare to support in the <uses-sdk> manifest element. The logic boils down to:

 

전용 메뉴버튼이 없는 디바이스에서 당신이 어플리케이션이 실행되고 있다면, 시스템은 매니페스트 항목에 당신이 선언한 <uses-sdk> 지원 API 레벨에 근거하여 액션 오버플로우를 네비게이션바에 추가할지 결정하게 됩니다. 이 토픽은 아래를 참고하세요.

 

   - If you set either minSdkVersion or targetSdkVersion to 11 or higher, the system will not add the legacy overflow button.

 

   - Otherwise, the system will add the legacy overflow button when running on Android 3.0 or higher.

 

   - The only exception is that if you set minSdkVersion to 10 or lower, set targetSdkVersion to 11, 12, or 13, and you do not use ActionBar, the system will add the legacy overflow button when running your app on a handset with Android 4.0 or higher.

 

   - 당신이 minSdkVerion 이나 targetSdkVersion을 11 또는 그 이상으로 설정한다면, 시스템은 기존의 오버플로우 버튼을 추가하지 않습니다.

 

   - 그렇지 않으면 시스템은 안드로이드 3.0이나 그 이상의 장치에서 실행될때에 기존의 오버플로우 버튼을 추가할 것 입니다.

 

   - 단 한가지 예외사항으로는 minSdkVersion을 10이나 그 이하로 설정하는 경우, targetSdkVerion을 11/12/또는 13으로 설정하는 경우, 그리고 액션바를 사용하지 않는 경우이며 시스템은 안드로이드 4.0 또는 그 이상의 단말장치에서 당신의 어플리케이션이 실행될 때에 기존의 오버플로우 버튼을 추가할 것 입니다.

 

That exception might be a bit confusing, but it’s based on the belief that if you designed your app to support pre-Honeycomb handsets and Honeycomb tablets, it probably expects handset devices to include a Menu button (but it supports tablets that don’t have one).

 

이러한 예외는 아마도 약간 혼란스러울 수 있겠지만, 허니컴 이전과 허니컴 태블릿을 지원하는 당신의 어플의 결정에 따르는 것입니다. 그것은 아마도 메뉴버튼이 존재하는 단말장치를 기대할 것 입니다. (그러나 그것은 메뉴버튼이 없는 태블릿을 지원합니다.)

 

So, to ensure that the overflow action button never appears beside the system navigation, you should set the targetSdkVersion to 14. (You can leave minSdkVersion at something much lower to continue supporting older devices.)

 

그래서 오버플로우 액션 버튼이 시스템 네비게이션 옆에 나타나는지를 확인하려면, 당신은 targetSdkVersion을 14로 설정해야 합니다.

 

Migrating to the action bar

 

If you have activities that use the options menu (they implement onCreateOptionsMenu()), then once the legacy overflow button disappears from the system/navigation bar (because you’ve set targetSdkVersion to 14), you need to provide an alternative means for the user to access the activity’s actions and other options. Fortunately, the system provides such a means by default: the action bar.

 

당신이 만일 옵션메뉴를 사용하는 액티비티(onCreateOptionMenu()를 구현하는)가 있다면, 다시한번 기존의 오버플로우 버튼이 시스템/네비게이션 바에서 사라집니다. (왜냐하면 당신이 targetSdkVersion을 14로 설정했기 때문입니다.) 당신은 액티비티의 액션과 기타 옵션들에 엑세스하려는 사용자를 위한 대체수단을 제공해야 합니다. 다행스럽게도 시스템은 기본적으로 그러한 수단을 액션바를 이용해 제공합니다.

 

Add showAsAction="ifRoom" to the <item> elements representing the activity’s most important actions to show them in the action bar when space is available. For help deciding how to prioritize which actions should appear in the action bar, see Android Design’s Action Bar guide.

 

공간을 사용할 수 있는 경우 액션바에 그것들을 보여주려는 작업에서 가장 중요한 행동을 나타내는 showAsAction="ifRoom"을 <item> 항목에 추가하십시오. 액션들이 액션바에서 표시되어야 하는 우선순위를 결정하는 방법에 도움을 줍니다. 안드로이드 설계의 액션바 가이드를 보십시오.

(스크린샷 생략)

To further provide a consistent user experience in the action bar, we suggest that you use action icons designed by the Android UX Team where appropriate. The available icons support common user actions such as Refresh, Delete, Attach, Star, Share and more, and are designed for the light and dark Holo themes. Here they are!

 

액션바에서의 일관된 사용자 경험을 추가적으로 제공하기 위해, 우리는 당신이 안드로이드 UX팀에의해 적절히 디자인된 액션 아이콘들은 사용하는 것을 제안합니다. 사용가능한 아이콘들은 새로고임, 삭제, 첨부, 별점, 공유 그리고 기타와 같은 일반적인 사용자의 액션들을 제공하며 밝고 어두운 홀로테마들고 디자인되어 있습니다. 여기에 있습니다! (첨부파일 참고)

 

If these icons don’t accommodate your needs and you need to create your own, you should follow the Iconography design guide.

 

이 아이콘들이 당신의 요구에 알맞지 않고, 직접 생성해야 하는 경우에는 도해법 디자인 가이드를 준수해야 합니다.

 

Removing the action bar

 

If you don’t need the action bar, you can remove it from your entire app or from individual activities. This is appropriate for apps that never used the options menu or for apps in which the action bar doesn’t meet design needs (such as games). You can remove the action bar using a theme such as Theme.Holo.NoActionBar or Theme.DeviceDefault.NoActionBar.

 

액션바가 필요없으시면, 당신은 전체 어플리케이션이나 각 액티비티에서 제거 할 수 있습니다. 이것은 옵션메뉴의 사용이 일어나지 않을만한 어플리케이션이거나 액션바가 설계요구사항에 불필요한 경우(예를들면 게임과 같은)에 적합합니다. 당신은 Theme.Holo.NoActionBar 또는 Theme.DeviceDefault.NoActionBar와 같은 테마를 이용하여 액션바를 제거할 수 있습니다.

 

In order to use such a theme and remain backward compatible, you can use Android’s resource system to define different themes for different platform versions, as described by Adam Powell’s post, Holo Everywhere. All you need is your own theme, which you define to inherit different platform themes depending on the current platform version.

 

이러한 테마를 사용하면서 이전 버전과의 호환성을 유지하기 위해서, Adam Powell의 'Holo Everyshere(http://android-developers.blogspot.com/2012/01/holo-everywhere.html)'포스트에서 설명된 것 처럼 당신은 다른 플랫폼 버전에 대해 서로 다른 테마를 정의하는 안드로이드의 리소스 시스템을 사용할 수 있습니다. 당신이 필요로 하는 것은 현재의 플랫폼 버전에 따라 서로 다른 플랫폼 테마가 정의된 자신의 테마입니다.

 

For example, here’s how you can declare a custom theme for your application:

 

예를들면, 여기에 당신의 어플리케이션을 위해 어떻게 커스텀 테마를 정의하는지 답이 있습니다.

 

    <application android:theme="@style/NoActionBar">

 

Or you can instead declare the theme for individual <activity> elements.

 

아니면 개별적인 <activity> 항목들을 위한 테마를 대신 선언할 수 있습니다.

 

For pre-Honeycomb devices, include the following theme in res/values/themes.xml that inherits the standard platform theme:

 

허니컴 이전의 디바이스인 경우, 표준 플랫폼 테마를 상속한 res/values/themes.xml 내에 다음의 테마를 포함합니다.

 

     <resources>

         <style name="NoActionBar" parent="@android:style/Theme">

             <!-- Inherits the default theme for pre-HC (no action bar) -->

         </style>

     </resources>

 

For Honeycomb and beyond, include the following theme in res/values-v11/themes.xml that inherits a NoActionBar theme:

 

허니컴 또는 그 이상의 경우, NoActionBar를 상속하는 res/values-v11/themes.xml 내에 다음의 테마를 포함합니다.

 

     <resources>

         <style name="NoActionBar" parent="@android:style/Theme.Holo.NoActionBar">

             <!-- Inherits the Holo theme with no action bar; no other styles needed. -->

         </style>

     </resources>

 

At runtime, the system applies the appropriate version of the NoActionBar theme based on the system’s API version.

 

실행시에 시스템은 시스템의 API 버전에 따라 NoActionBar 테마의 해당 버전을 적용합니다.

 

Summary

 

- Android no longer requires a dedicated Menu button, some devices don’t have one, and you should migrate away from using it.

- Set targetSdkVersion to 14, then test your app on Android 4.0.

- Add showAsAction="ifRoom" to menu items you’d like to surface in the action bar.

- If the ActionBar doesn’t work for your app, you can remove it with Theme.Holo.NoActionBar or Theme.DeviceDefault.NoActionBar.

 

- 안드로이드가 몇몇 디바이스들과 같이 더 이상 전용 메뉴버튼을 요구하지 않으면,  당신은 그것을 사용하여 마이그레이션 해야 합니다.

- targetSdkVersion을 14로 설정하시고, 안드로이드 4.0에서 당신의 어플리케이션을 테스트 하십시오.

- 액션바의 표면에 나타내고 싶은 항목에 showAsAction="ifRoom"을 메뉴아이템에 추가합니다.

- 당신의 어플리케이션에서 액션바가 동작하지 않는 경우, Theme.Holo.NoActionBar 또는 Theme.DeviceDafault.NoActionBar를 사용하여 그것을 제거할 수 있습니다.

 

For information about how you should design your action bar, see Android Design’s Action Bar guide. More information about implementing the action bar is also available in the Action Bar developer guide.

 

당신의 액션바를 어떻게 설계해야 하는지에 대한 정보는 안드로이드 설계의 액션바 가이드를 참조하십시오. 액션바의 구현에 대한 더 자세한 정보는 또한 액션바 개발 가이드문서를 참조하실 수 있습니다.