2012-07-22 12 views
8

Sto utilizzando ActionBarSherlock. Desidero essere in grado di far apparire due pulsanti nella barra delle azioni in risposta a una determinata operazione dell'utente. L'operazione dell'utente non è completamente correlata alla barra delle azioni. La visibilità dei pulsanti deve essere controllata chiamando un metodo. Inoltre, la risposta al clic su quei pulsanti deve essere gestita dal mio codice applicazione.ActionBarSherlock: mostra/nascondi i pulsanti di azione con programmazione programmata tramite una chiamata al metodo

I pulsanti devono avere l'aspetto ideale di quelli creati durante la definizione delle voci di menu come elementi di azione utilizzando android:showAsAction="ifRoom|withText", come illustrato here.

Il mio problema è che, per quanto posso dire, lo standard ActionBar API fornisce alcun meccanismo per mostrare o nascondere azione I pulsanti Voce a volontà, e l'unica volta che le voci di menu possono essere definiti rientra onCreateOptionsMenu() che è di Ovviamente chiamato dal sistema.

La mia convinzione è che l'unico modo per aggiungere pulsanti come questo e mostrarli/nasconderli a piacimento è creare un layout personalizzato per loro e utilizzare .setCustomView() per metterli nella barra delle azioni. La gente generalmente sarebbe d'accordo con questo, o c'è qualcosa che mi è sfuggito?

Se si utilizza il parametro .setCustomView(), desidero che i miei pulsanti appaiano identici ai pulsanti di azione che ActionBarSherlock visualizza per una voce di menu con l'attributo android:showAsAction="ifRoom|withText". Per fare ciò, qualcuno può consigliarmi quale particolare tema, stile o layout all'interno della libreria ActionBarSherlock dovrei usare? Ho già provato a utilizzare R.layout.abs__action_menu_item_layout, ma il tentativo di gonfiare questo layout produce un'eccezione relativa a un colorStateList durante il tentativo di gonfiaggio dello CapitalizingButton contenuto nel layout.

risposta

9

Se si desidera che i due pulsanti abbiano l'aspetto e la funzionalità delle voci di menu, è necessario creare le voci di menu. La tua ipotesi che le voci di menu possano essere definite solo in onCreateOptionsMenu() non è corretta, perché esiste anche un metodo chiamato onPrepareOptionsMenu(), che verrà chiamato ogni volta proprio prima che venga visualizzato il menu. Insieme al metodo invalidateOptionsMenu() di un'attività, è possibile creare facilmente un menu dat riflette lo stato corrente in tempo reale.

L'alternativa è di mantenere un riferimento ai singoli oggetti MenuItem, in quanto la documentazione indica il suo salvataggio per trattenere quelli e modificare la loro visibilità quando appropriato. Potrebbe comunque essere necessario chiamare il numero invalidateOptionsMenu() per aggiornare il menu. Non riesco a ricordare da cima alla mia testa. (Modifica: Jake mi ha battuto su questo su questo)

Personalmente, preferisco il primo approccio, dal momento che si tiene raggruppata tutta la logica relativa ai menu e la visibilità si basa su una sorta di stato/modello. La seconda opzione potrebbe essere più semplice da implementare, a seconda del codice corrente, ma potrebbe risultare in elementi di menu dappertutto.

+1

Grazie, MH. Ci sono molte idee qui di cui sono grato. C'è ancora un problema che mi meraviglia se avrò ancora bisogno di ricorrere a '.setCustomView()'. Il problema è che voglio che l'etichetta di testo mostri sempre, non solo l'icona. Sul mio HTC One X con niente sull'ABS oltre all'icona di overflow e un singolo oggetto azione, l'etichetta di testo dell'elemento azione viene visualizzata solo in orizzontale, anche se c'è spazio sufficiente in entrambi gli orientamenti. Mi rendo conto che la barra delle azioni applica la logica in base alla densità dello schermo e alla larghezza della barra per determinare se l'etichetta è visibile. Investigherò un po 'di più su questo. – Trevor

+0

Juse ha riscritto la mia logica MenuItem all'interno di Fragments usando i consigli che hai dato - funziona MOLTO meglio ora. Chiunque vada in questo modo, si assicuri di impostare setHasMenuOptions (true) e fare come @MH. suggerito (eseguo entrambi onPrepareOptionsMenu e mantengo il riferimento agli oggetti MenuItem). – kape123

+0

"Personalmente, preferisco il primo approccio, dal momento che si tiene raggruppata tutta la logica relativa ai menu e la visibilità si basa su una sorta di stato/modello." Sì, insieme a tutto il resto, insieme nell'oggetto dio, chiamato Attività. E l'oggetto divino è un modello anti. –

11

È possibile chiamare setVisibility nelle istanze MenuItem.

documentation states "È possibile mantenere in sicurezza il menu (e qualsiasi elemento creato da esso), apportando le modifiche desiderate, fino alla prossima volta suCreateOptionsMenu()."

+0

Grazie, Jake (e molte grazie per ABS, anche se probabilmente sei stanco di essere ringraziato per questo ormai :-)). Come ho commentato a MH, un problema è che vorrei forzare le etichette di testo a mostrare sempre. Questo è uno dei motivi per cui potrei aver bisogno di applicare solo una vista personalizzata, ma proverò prima alcuni di questi suggerimenti. – Trevor

2

hai controllato i campioni demo?

hanno questa caratteristica in "opzioni di attivazione/disattivazione".

+0

Mille grazie. Daremo un'occhiata a questo esempio adesso. – Trevor

Problemi correlati