Debería "android: onOptionsItemSelected" devolver true o false
En onOptionsItemSelected … He visto algunos códigos que son diferentes en el bloque de interruptores.
Caso 1 (Normalmente visto)
public boolean onOptionsItemSelected (MenueItem item) switch (item.getItemId()){ case R.id.item1: startActivity (new Intent (this, PrefsActivity.class)); break; } return true Caso 2 (no está seguro de por qué está configurado de esta manera)
public boolean onOptionsItemSelected(MenuItem item) { switch (item.getItemId()) { case MENU_NEW_GAME: newGame(); return true; } return false;
Mi pregunta
¿Cuáles son las diferencias entre el Caso 1 y el Caso 2?
Kleaver
Por la documentación de onOptionsItemSelected()
Devoluciones
Boolean Devuelve false para permitir que el procesamiento normal del menú proceda, true para consumirlo aquí.
El if devuelto true el evento click será consumido por la llamada onOptionsItemSelect () y no caerá a otras funciones de clic de artículo. Si su devolución es falsa, puede comprobar el ID del evento en otras funciones de selección de elementos.
Su método seguirá funcionando, pero puede resultar en llamadas innecesarias a otras funciones. El ID caerá en última instancia a través de esas funciones ya que no hay ningún interruptor para capturarlo, pero devolver false es más correcto.
Según la documentación
True -> Evento consumido ahora No se debe reenviar para otro evento
False -> Reenviar para que otros consuman
Este tipo de retorno booleano realmente se beneficia cuando estamos trabajando con múltiples fragmentos y cada fragmento tiene su propio menú de opciones y sobreescribe OnOptionItemSelected (principalmente en el diseño de la tableta).
En este caso android traza el método OnOptionItemSelected () de cada fragmento, para evitar que
A) Si algún fragmento está consumiendo un evento en onOptionsItemSelected () devuelve "true" (para detener) else devuelve "false"
B) Si devolvemos false, entonces rastreará el fragmento conectado onOptionsItemSelected ()
Método hasta que termine todo el fragmento o alguien lo consume.
Aquí he tratado de explicar desde el diagrama
El límite del color verde es el fragmento 1 y el del color rojo es el fragmento 2
Ambos fragmentos tienen su propio Optionmenu que he destacado
Ahora Si hacemos clic en cualquiera de OptionmenuItem Se comprobará Implementación de onOptionsItemSelected () en ambos fragmentos
Si algún fragmento está consumiendo el evento onOptionsItemSelected devuelve true, Por esto nunca intentaría por otro fragmento y podemos reducir la sobrecarga del sistema operativo Android.
El problema con su método es que devuelve true incluso si la instrucción switch no encuentra un elemento. Si devuelves true inmediatamente como el otro método para cada caso de switch, puedes asumir, si estás al final del método, que no se encontraron casos de switch, así que devuelve false para mostrar que no se manejó.
Cuando utilicé Android Studio para generar una aplicación genérica, el código de plantilla para onOptionsItemSelected () devuelve true si el elemento se consume de lo contrario pasa la llamada a la superclase.
@Override public boolean onOptionsItemSelected(MenuItem item) { // Handle action bar item clicks here. The action bar will // automatically handle clicks on the Home/Up button, so long // as you specify a parent activity in AndroidManifest.xml. int id = item.getItemId(); //noinspection SimplifiableIfStatement if (id == R.id.action_mymenuaction) { return true; } return super.onOptionsItemSelected(item); }
Acabo de tener el problema de que mi
getActionBar().setDisplayHomeAsUpEnabled(true);
No estaba trabajando. Al tocar el botón de retroceso se resalta pero no sucedió nada.
Me tomó un tiempo para averiguar que este era el retorno de la verdad.
En mi opinión, la mejor solución con menos duplicación de código sería la siguiente:
public boolean onOptionsItemSelected(MenuItem item) { switch (item.getItemId()) { case MENU_NEW_GAME: newGame(); break; default: return false; } return true; }