2012-07-22 10 views
8

Estoy usando ActionBarSherlock. Deseo poder hacer que aparezcan dos botones en la barra de acciones en respuesta a una determinada operación del usuario. La operación del usuario no está relacionada con la barra de acciones. La visibilidad de los botones debe controlarse llamando a un método. Además, la respuesta al hacer clic en esos botones se manejará con mi propio código de aplicación.ActionBarSherlock: Mostrar/ocultar botones de elementos de acción mediante programación a través de una llamada a un método

Idealmente, los botones se verán como los que se crean al definir elementos de menú como Elementos de acción usando android:showAsAction="ifRoom|withText", como se ilustra en here.

Mi problema es que por lo que yo puedo decir, la ActionBar API estándar proporciona ningún mecanismo para mostrar u ocultar acción Los botones de artículo a voluntad, y la única vez que los elementos de menú se pueden definir está dentro onCreateOptionsMenu() que es de curso llamado por el sistema.

Mi creencia es que la única forma en que voy a agregar botones como este y mostrarlos/ocultarlos a voluntad es crear un diseño personalizado para ellos y hacer uso de .setCustomView() para colocarlos en la barra de acciones. ¿La gente generalmente estaría de acuerdo con eso, o hay algo que me he perdido?

Si sigo la ruta del uso de .setCustomView(), me gustaría que mis botones se vean idénticos a los botones del elemento de acción que ActionBarSherlock muestra para un elemento de menú que tiene el atributo android:showAsAction="ifRoom|withText". Para hacer esto, ¿alguien puede aconsejarme qué tema, estilo o diseños en particular de la biblioteca ActionBarSherlock debo utilizar? Ya he intentado usar R.layout.abs__action_menu_item_layout, pero intentar inflar este diseño produce una excepción relacionada con colorStateList al intentar inflar el CapitalizingButton que contiene el diseño.

Respuesta

9

Si desea que esos dos botones tengan la apariencia de los elementos del menú, debe convertirlos en elementos del menú. Su suposición de que los elementos del menú solo se pueden definir en onCreateOptionsMenu() es incorrecta, porque también hay un método llamado onPrepareOptionsMenu(), que se invocará cada vez que se muestre el menú. Junto con el método invalidateOptionsMenu() de una actividad, puede crear fácilmente un menú que refleje el estado actual en tiempo real.

La alternativa es mantener una referencia a los objetos individuales MenuItem, ya que la documentación indica su guardar para retenerlos y cambiar su visibilidad cuando corresponda. Es posible que aún tenga que llamar al invalidateOptionsMenu() para actualizar el menú. No puedo recordarlo de memoria. (Editar: Jake se me adelantó en este caso)

Personalmente, prefiero la primera aproximación, ya que se mantiene toda la lógica relacionada con menús agrupados juntos y la visibilidad se basa en una especie de estado/modelo. La segunda opción puede ser más sencilla de implementar, dependiendo de su código actual, pero puede dar lugar a cosas de menú en todo el lugar.

+1

Gracias, MH. Aquí hay varias ideas por las cuales estoy agradecido. Todavía hay un problema que me hace preguntarme si todavía necesitaré recurrir a '.setCustomView()'. El problema es que quiero que la etiqueta de texto se muestre siempre, no solo el ícono. En mi HTC One X sin nada en el ABS que no sea un icono de desbordamiento y un único elemento de acción, la etiqueta de texto del elemento de acción solo se muestra en horizontal, aunque haya espacio suficiente en cualquier orientación. Me doy cuenta de que la barra de acción aplica lógica en función de la densidad de la pantalla y el ancho de la barra para determinar si la etiqueta es visible. Voy a investigar esto un poco más. – Trevor

+0

Juse reescribió mi lógica de MenuItem dentro de Fragments usando el consejo que me diste: funciona MUCHO mejor ahora. Cualquiera que vaya por aquí, asegúrese de hacer setHasMenuOptions (verdadero) e ir por el camino @MH. sugerido (hago tanto onPrepareOptionsMenu como haciendo referencia a los objetos MenuItem). – kape123

+0

"Personalmente, prefiero el primer enfoque, ya que mantiene toda la lógica relacionada con el menú agrupada y la visibilidad se basa en algún tipo de estado/modelo". Sí, junto con todo lo demás, juntos en el objeto dios, llamado Actividad. Y el objeto de dios es un patrón anti. –

11

Puede llamar al setVisibility en las instancias MenuItem.

documentation states que "Puede guardar de manera segura el menú (y cualquier elemento creado a partir de él), realizando modificaciones según lo desee, hasta que se llame a la próxima vez que se llame aCreateOptionsMenu()".

+0

Gracias, Jake (y muchas gracias por ABS, aunque probablemente ya estés cansado de que te lo agradezcan :-)). Como le comenté a MH, un problema es que me gustaría obligar a las etiquetas de texto a mostrar siempre. Esta es una de las razones por las que podría necesitar simplemente aplicar una vista personalizada, pero primero probaré algunas de estas sugerencias. – Trevor

2

ha comprobado las muestras de demostración?

tienen esta característica allí en "características alterna".

+0

Muchas gracias. Voy a echar un vistazo a esa muestra en este momento. – Trevor

Cuestiones relacionadas