Manejo del botón MENU que falta en las nuevas versiones de Android (3.x y superior)

Soy un fan del botón de menú como se utiliza en Android <3.0, ya que era muy útil para mis aplicaciones de juego – que me permitió tener funcionalidad importante pero gameplay irrelevante (guardar juego, enlaces de información de referencia) y colocarlo en algún lugar donde No enturbiar la interfaz principal del juego, pero todavía era fácilmente accesible (el menú de opciones).

Este uso de claves se convirtió en un problema con 3.0, ya que eliminó el botón MENU y lo sustituyó por la barra de acción. La barra de acción no es realmente adecuado para un juego que le gusta correr a pantalla completa, por lo que fue un verdadero dolor. No hay barra de acción – no hay acceso al menú de opciones. Sin embargo, podría ignorarlo por un tiempo, ya que no tenía muchos usuarios en tabletas y no tenía tiempo para probar esto.

Sin embargo, ICS hace que esto sea un problema grave, ya que el botón MENU, obviamente, no está regresando. Ahora no sólo tengo que lidiar con estos problemas en las tabletas, sino en los teléfonos también.

Mi solución inicial a este problema ha sido colocar simplemente un botón suave en mi GUI para substituir el botón duro del MENÚ

this.openOptionsMenu();

Y todo vuelve a funcionar perfectamente en ICS.

Sin embargo, esto no funciona en Honeycomb. Llamar openOptionsMenu no hace absolutamente nada si no tiene visible la ActionBar.

¿Alguna idea sobre cómo lidiar con esto?

Supongo que siempre podría volver a usar TargetSDK <11 (forzando así a ActionBar a aparecer en las tabletas), pero en la medida de lo que puedo ver esto es simplemente empujando el problema en el futuro, lo que prefiero no hacer.
Suelte el menú de opciones por completo, y pasar a utilizar sólo los menús de contexto? [Clarificación: Con esto quiero decir que en lugar de abrir un menú de opciones – sólo uso menús contextuales desde – al menos por ahora – estos trabajos en todos los dispositivos].

Interesado en escuchar lo que otros que han tenido problemas similares con todo el menú Opciones / ActionBar lío decidió hacer.

Permítanme compartir otro escenario en el que Menú Botón se convierte en crítica a pesar de que no es un juego.

Tengo aplicación implementar sus propias barras de herramientas que se comportan en cierta medida como ActionBar. Bueno, hice que coz mi aplicación fue lanzado con 1,5 sdk. En ese momento no existe tal concepto. Y para acomodar a mis barras de herramientas ocultar la barra de título por defecto. Pero algunas de las acciones se realizan a través de la funcionalidad de menú.

Ahora, ya que en Galaxy Nexus no hay botón Menú si no estás usando ActionBar y eso me está doliendo porque mi aplicación sigue soportando 1.5.

Bueno, hay varios trabajos alrededor, pero ninguno es fácil.

Dicho esto, el único trabajo que me propongo es dar al usuario todas las opciones en mi barra de herramientas, por lo que no hay necesidad de menú en absoluto. Puedo hacer esto porque sólo tengo dos acciones que no forman parte de la barra de herramientas.

En su situación, el menú contextual de un botón no es un mal soln en un juego como juego tendrá sólo un contexto en el que se está ejecutando en comparación con tener menú contextual en los elementos de la lista donde cada elemento es un contexto diferente.

BTW si openOptionsMenu funciona en ICS y se puede abandonar HoneyComb después de un tiempo (incluso ahora la base de usuarios es demasiado baja), a continuación, intente dar los dos menús basados en la versión .

EDIT: Bueno, hay otra forma de obtener el botón MENU s / w en la barra de navegación inferior. Apenas fije el targetSdkVersion a menos de 11. Para más detalles pls lea el soln entero.

Sin embargo, ICS hace que esto sea un problema grave, ya que el botón MENU, obviamente, no está regresando.

Más exactamente, es hasta fabricantes del dispositivo si tener botones fuera de la pantalla o no para cosas como MENÚ. Citando el documento de definición de compatibilidad para Android 4.0:

Las funciones Inicio, Menú y Atrás son esenciales para el paradigma de navegación de Android. Las implementaciones de dispositivos DEBEN poner estas funciones a disposición del usuario en todo momento cuando se ejecutan aplicaciones. Estas funciones PUEDEN ser implementadas a través de botones físicos dedicados (como los botones táctiles mecánicos o capacitivos), o PUEDEN ser implementados usando teclas de software dedicadas, gestos, panel táctil, etc.

Por lo tanto, no se puede contar con un botón MENU fuera de la pantalla, aunque puede haber uno.

¿Alguna idea sobre cómo lidiar con esto?

Escriba su propio "menú" como parte de su interfaz de usuario de juego. Yo no esperaría un juego que piensa que necesita la pantalla completa para usar el menú de opciones – de hecho, no recuerdo haber visto nunca un juego que hizo que (aunque, sin duda, no soy un jugador de gran tiempo de juego) . Todos los juegos que he jugado no hacen nada en una prensa MENU. Por el contrario, cualquier cosa que pueda considerarse un "menú" se implementa directamente en la interfaz de usuario del juego (por ejemplo, un botón que conduce a una pantalla, formateada en el juego de la interfaz de usuario de aspecto y sensación, que ofrece opciones de cosas que hacer).

Suelte el menú de opciones por completo, y pasar a utilizar sólo los menús de contexto?

Eso sería horrible, ya que los usuarios no saben a dónde presionar para abrir el menú.

Y sólo para poner el último pico en el proverbial ataúd del botón de menú, Google pesa con un último adiós:

http://android-developers.blogspot.com/2012/01/say-goodbye-to-menu-button.html

Michael, estaba exactamente en la misma situación y lo solucioné implementando mi menú de opciones usando un diálogo personalizado. Se ve mejor en ICS que el menú de opción de legado en la parte inferior. Está configurado de esta manera

MinSdkVersion = 8 targetSdkVersion = 14 SDK build versión 8 (en eclipse settings.could establecido en 14 pero me gusta el tipo de seguridad que proporciona)

Los usuarios con API <10 utilizan el botón de menú duro y ver el menú de opciones estándar. Los usuarios con API> = 10 ver un icono de tres puntos (menú de desbordamiento) en la aplicación y cuando haga clic en obtener mi menú de diálogo personalizado. También ven la nueva apariencia de ICS en Configuración, etc.

No parece que el botón de menú está regresando y quería romper la barrera heredada, aunque sólo <1% de mis usuarios utilizan ICS.

Respondiendo a esa reciente publicación en el blog, parecen querer que los desarrolladores comiencen a usar barras de acción sobre los menús, pero esto se convierte en un dolor si quieren soportar API => 3.0 y API <3.0. Por lo tanto, puede crear una barra de acción personalizada que sea compatible con API <3.0 (puede encontrar ejemplos en el SDK) o … Estaba experimentando con esta última semana:

También tuve un problema donde el botón de menú no aparece en mi tableta ICS, creo que tenía targetSdk conjunto a 11 en el momento que quería implementar un ActionBar. Entonces fijé minSdk a 3, y targetSdk a 4. Apareceron el ActionBar y el botón del desbordamiento del menú. Así que esta es la solución en este momento (al menos para el proyecto en el que estoy trabajando).

He añadido una lógica especial para las versiones 3.x. Sólo para estos lanzamientos utilizo la barra de acción.

  if (Build.VERSION.SDK_INT == Build.VERSION_CODES.HONEYCOMB || Build.VERSION.SDK_INT == Build.VERSION_CODES.HONEYCOMB_MR1 || Build.VERSION.SDK_INT == Build.VERSION_CODES.HONEYCOMB_MR2) { requestWindowFeature(Window.FEATURE_ACTION_BAR); } else{ // hide the status bar, do not use action bar requestWindowFeature(Window.FEATURE_NO_TITLE); getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); }

Para todos los otros lanzamientos exhibo mi propio botón del menú y ejecuto mi juego en modo de la pantalla completa. Al presionar mi botón de menú, utilizo la siguiente línea de código, donde "act" es la actividad actual.