android - studio - commitAllowingStateLoss() en actividades de fragmentos

fragmentactivity to fragment

Question

mi aplicación utiliza actividades de fragmentos, está en modo retrato solamente y no hay forma de girar la pantalla.

Originalmente estaba usando el método commit() pero ahora planeo cambiarlos indiscriminadamente a commitAllowingStateLoss() para las actividades del fragmento

¿Hay alguna razón para no hacer esto indiscriminadamente sin volver a evaluar cada caso individual en el que utilizo un fragmento?

Answer 1

Puede anular el siguiente método como este

@Override
public void supportFinishAfterTransition() {
finish();
super.supportFinishAfterTransition();
}

funcionó para mí.

Answer 2

Si entiendo correctamente, quiere decir: ¿Hay alguna razón para NO hacer esto indiscriminadamente sin volver a evaluar cada caso individual en el que utilizo un fragmento?

La respuesta es Sí, no debe hacer esto sin volver a evaluar cuidadosamente cada caso individual en el que use un fragmento.

Por supuesto, al evitar los reinicios debido a cambios de configuración (rotaciones de pantalla) ha eliminado una de las áreas problemáticas clave: es decir, el usuario podría rotar la pantalla DESPUÉS de una llamada a onSaveInstanceState pero ANTES de commitAllowingStateLoss . En este caso, se podría perder un fragmento o parte de UI. Para una discusión informal de esto, vea esta post .

Pero hay otras situaciones que debes considerar antes de reemplazar commit por commitAllowingStateLoss .

1. Básicamente, cualquier actualización de interfaz de usuario entre onSaveInstanceState y commitAllowingStateLoss: Android: IllegalStateException: ¿cuándo se lanza?

2. Si tiene algún fragmento sin cabeza que actualice la interfaz de usuario de su actividad, algunas de sus actualizaciones podrían perderse (consulte este article ).

3. Android podría "matar" un fragmento porque el teléfono / la pestaña se está quedando sin recursos (ver esta answer ).

Por supuesto, si se evitan las rotaciones de pantalla, entonces no se puede onSaveInstanceState , en cuyo caso se incrementa la ventana de oportunidad para que se pierda una actualización.

Si decides usar commitAllowingStateLoss entonces puedes hacer cosas para minimizar los riesgos: por ejemplo, considerar hacer commit / executePendingTransactions cuando la próxima actividad de los padres sea reiniciada (sé que no quieres hacer esto, pero alguien más podría leer this ).

Finalmente (de nuevo, en caso de que alguien más lea esto, esto no es relevante en su caso), probablemente haya formas más seguras de manejar una IllegalStateException que pasar de commit a commitAllowStateLoss . por ejemplo, podría simplemente quedarse con la confirmación y manejar la IllegalStateException . Alternativamente, puede haber tocado un bug en Android y puede haber una solución alternativa.

Answer 3

Una mejor idea sería usar commit () en las devoluciones de llamada OnPostResume en lugar de usar commitAllowingStateLoss () indiscriminadamente. El siguiente blogpost proporciona una explicación detallada http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html

@Override
protected void onPostResume() {
super.onPostResume();
// Commit your transactions here.
}

Answer 4

Utilice commitAllowingStateLoss () solo como último recurso. La única diferencia entre invocar commit () y commitAllowingStateLoss () es que este último no generará una excepción si se produce una pérdida de estado. Por lo general, no desea utilizar este método porque implica que existe la posibilidad de que ocurra una pérdida de estado. La mejor solución, por supuesto, es escribir su aplicación para que commit () garantice que se llame antes de que se haya guardado el estado de la actividad, ya que esto dará como resultado una mejor experiencia de usuario. A menos que no se pueda evitar la posibilidad de pérdida de estado, no se debe usar commitAllowingStateLoss ().

Answer 5

public abstract int commit ()

Programa una confirmación de esta transacción. El compromiso no ocurre inmediatamente; se programará como trabajo en el hilo principal que se realizará la próxima vez que el hilo esté listo.

Una transacción solo puede comprometerse con este método antes de que su actividad contenedora guarde su estado. Si se intenta la confirmación después de ese punto, se lanzará una excepción. Esto se debe a que el estado después de la confirmación puede perderse si la actividad necesita restaurarse desde su estado. Consulte commitAllowingStateLoss () para situaciones en las que puede estar bien perder la confirmación.

public abstract int commitAllowingStateLoss ()

Agregado en el nivel de API 11

Like commit () pero permite que la confirmación se ejecute después de guardar el estado de una actividad. Esto es peligroso porque la confirmación puede perderse si la actividad necesita ser restaurada más tarde desde su estado, por lo tanto, esto solo debe usarse para casos en los que está bien que el estado de la IU cambie inesperadamente en el usuario.

Limitaciones de FragmentActivity

Antes de Honeycomb (3.0), el estado de una actividad se guardaba antes de la pausa. Los fragmentos son una cantidad significativa de nuevo estado, y lo suficientemente dinámicos como para que uno quiera cambiar entre pausar y detenerse. Estas clases lanzan una excepción si intenta cambiar el estado del fragmento después de que se ha guardado, para evitar la pérdida accidental del estado de la IU. Sin embargo, esto es demasiado restrictivo antes de Honeycomb, donde el estado se guarda antes de la pausa. Para solucionar esto, cuando se ejecuta en plataformas anteriores a Honeycomb, no se lanzará una excepción si cambia los fragmentos entre el estado guardado y la actividad que se detiene. Esto significa que, en algunos casos, si la actividad se restablece desde su último estado guardado, esta puede ser una instantánea levemente anterior a lo que el usuario vio por última vez.

Entonces, si no te conceden la pérdida del estado, creo que tu decisión está bien. Espero que te ayude con tu decisión.

Answer 6

try {
transaction.commit();
} catch (IllegalStateException e) {
transaction.commitAllowingStateLoss();
}