studio personalizar bar android compatibility android-3.0-honeycomb android-4.0 android-4.2-jelly-bean

personalizar - Manejo del botón MENÚ faltante en las nuevas versiones de Android(3.xy superior)



menu overflow android studio (6)

Soy fanático del botón de menú que se usa en Android <3.0, ya que fue muy útil para mis aplicaciones de juego; me permitió tomar la funcionalidad irrelevante pero importante del juego (guardar juego, enlaces de información de referencia) y colocarla en algún lugar donde no abarrotó 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 MENÚ y lo sustituyó con la Barra de acciones. La barra de acción realmente no es adecuada para un juego que le gusta correr en pantalla completa, por lo que fue un verdadero dolor. Sin barra de acción: sin acceso al menú de opciones. Sin embargo, podría ignorarlo por un tiempo, ya que no tenía tantos usuarios en tabletas y no tenía el tiempo para probar esto.

Sin embargo, ICS lo convierte en un problema grave, ya que obviamente el botón MENU no regresa. Ahora no solo tengo que lidiar con este problema en las tabletas, sino también en los teléfonos.

Mi solución inicial a este problema ha sido simplemente colocar un botón suave en mi GUI para reemplazar el botón de menú duro

this.openOptionsMenu();

Y todo ha vuelto a funcionar perfectamente en ICS.

Sin embargo, esto no funciona en Honeycomb. Llamar a openOptionsMenu no hace absolutamente nada si no tiene la barra de acciones visible.

¿Alguna idea sobre cómo lidiar con esto?

  • Supongo que siempre podría volver a utilizar TargetSDK <11 (forzando así que ActionBar aparezca en las tabletas), pero hasta donde puedo ver, esto simplemente está empujando el problema hacia el futuro, lo que preferiría no hacer.

  • ¿Desea abandonar por completo el menú de opciones y acceder solo a los menús contextuales? [Aclaración: con esto quiero decir que en lugar de abrir un menú de opciones, solo uso menús contextuales, ya que, al menos por ahora, funcionan en todos los dispositivos].

Interesado en escuchar lo que otros que han tenido problemas similares con todo el menú de Opciones / Lío de ActionBar decidieron hacer.

Sin embargo, ICS lo convierte en un problema grave, ya que obviamente el botón MENU no regresa.

Más exactamente, depende de los fabricantes del dispositivo si tienen 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 hacer estas funciones disponibles para el usuario en todo momento cuando se ejecutan aplicaciones. Estas funciones PUEDEN implementarse a través de botones físicos específicos (como botones táctiles mecánicos o capacitivos), o PUEDEN implementarse utilizando teclas de software, gestos, panel táctil, etc.

Por lo tanto, no puede contar con que haya un botón MENÚ fuera de la pantalla, aunque puede haber uno.

¿Alguna idea sobre cómo lidiar con esto?

Escribe tu propio "menú" como parte de la interfaz de usuario de tu juego. No esperaría un juego que crea que necesita la pantalla completa para usar el menú de opciones; de hecho, no recuerdo haber visto un juego que lo haya hecho (aunque, ciertamente, no soy un gran jugador). . Todos los juegos que he jugado no hacen nada al presionar MENÚ. 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 la interfaz de usuario del juego, que ofrece opciones de cosas que hacer).

¿Desea abandonar por completo el menú de opciones y acceder solo a los menús contextuales?

Eso sería horrible, ya que los usuarios no sabrán dónde presionar durante mucho tiempo para que aparezca el menú.

Agregué una lógica especial para las versiones 3.x. Solo 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 demás lanzamientos, muestro mi propio botón de menú y ejecuto mi juego en modo de pantalla completa. Al presionar mi botón de menú, uso la siguiente línea de código, donde "acto" es la actividad actual.

act.openOptionsMenu();

Como parte de su menú xml, asegúrese de tener una línea como esta para establecer "showAsAction"

showAsAction="ifRoom"

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

minSdkVersion = 8 targetSdkVersion = 14 SDK build versión 8 (en configuraciones de eclipse. podría establecerse en 14 pero me gusta el tipo de seguridad que proporciona)

Los usuarios con API <10 usan el botón de menú fijo y ven el menú de opción estándar. Los usuarios con API> = 10 ven un icono de tres puntos (menú de desbordamiento) en la aplicación y cuando hacen clic en obtener mi menú de diálogo personalizado. También ven el nuevo aspecto de ICS en Configuración, etc.

No parece que el botón Menú vuelva y quería romper la barrera heredada, aunque solo <1% de mis usuarios usa ICS.

Permítanme compartir otro escenario donde el botón de menú se vuelve crítico, aunque no es un juego.

Tengo aplicación implementar sus propias barras de herramientas que se comportan en cierta medida como ActionBar. Bueno, lo hice porque mi aplicación fue lanzada con 1.5 sdk. En ese momento no existe tal concepto. Y para acomodar mis barras de herramientas, oculto la barra de título predeterminada. Pero algunas de las acciones se realizan a través de la funcionalidad del menú.

Ahora que en Galaxy Nexus no hay un botón de Menú si no está utilizando ActionBar y eso me está perjudicando porque mi aplicación todavía admite 1.5.

Bueno, hay varias soluciones, pero ninguna es fácil.

Dicho esto, el único trabajo que se me ocurre 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 solo tengo dos acciones que no son parte de la barra de herramientas.

En su situación, el menú contextual de un botón no es una mala solución en un juego, ya que el juego tendrá solo un contexto en el que se ejecuta, en comparación con tener un menú contextual en los elementos de la lista donde cada elemento tiene un contexto diferente.

Por cierto, si openOptionsMenu funciona en ICS y puedes abandonar HoneyComb después de un tiempo (incluso ahora la base de usuarios es muy baja), intenta dar ambos menús en función de la versión .

EDITAR: Bueno, también hay otra manera de obtener el botón MENU s / w en la barra de navegación a continuación. Simplemente configure la targetSdkVersion a menos de 11. Para obtener más información, lea la solución completa.

Respondiendo a esa publicación reciente del blog, parece que quieren que los desarrolladores comiencen a usar las barras de acción sobre los menús, pero esto se convierte en un dolor si se quiere admitir API => 3.0 y API <3.0. Entonces, o bien cree una Barra de acciones personalizada que sea compatible con API <3.0 (puede encontrar ejemplos en el SDK), o ... Estaba experimentando con esto la semana pasada:

También tuve un problema donde el botón del menú no apareció en mi tableta ICS, creo que tenía targetSdk establecido en 11 en ese momento, ya que quería implementar una barra de acciones. Luego configuré minSdk en 3 y targetSdk en 4. Aparecieron tanto la barra de acciones como el botón de desbordamiento del menú. Así que esta es la solución en este momento (al menos para el proyecto en el que estoy trabajando).