¿Cuáles son los pros y los contras de usar configChanges = "orientación" para dispositivos Android?
Estoy queriendo usar android:configChanges="orientation|keyboardHidden"
para algunas de mis actividades para que mi onCreate no se llame de nuevo, pero pensé que vería si alguien tenía una lista de pros y contras primero porque Este enlace dice que sólo debe utilizarse como último recurso.
- Cómo controla la orientación de la pantalla del dispositivo Android
- ¿Por qué `android: screenOrientation =" detrás "` no hay efecto en android 4.1.2?
- Diferencia entre SCREEN_ORIENTATION_USER y SCREEN_ORIENTATION_SENSOR
- Cambiar la orientación del dispositivo Android desde la línea de comandos
- Rotación inexplicable de la cámara Android en la captura de algunos dispositivos (no en EXIF)
- Apoyo a las dos orientaciones del paisaje en Honeycomb
- Manera correcta de manejar un cambio de orientación en Android
- Sólo en la aplicación Android
- Orientación de la pantalla de Android NDK
- Android: La preferencia programática 'permitir reorientación' funciona sólo una vez
- Los metadatos Exif no proporcionan orientación para las imágenes de unidades de Google
- Androide: ¿por qué devuelve la devolución de la matriz?
- Mostrar imágenes desde el tamaño de la URL y los problemas de orientación de la pantalla
Un gran Pro de usar este enfoque es que requiere muy poco esfuerzo de su parte, y que su aplicación sobrevivirá cambios de configuración sin recurrir a accidentes.
El pequeño inconveniente es que el uso de recursos específicos de configuración (para orientación horizontal o vertical) no se aplican automáticamente.
En mi (quizás poco) experiencia, creo que no vale la pena el esfuerzo de hacer todas las tuberías.
El manejo "correcto" de estos cambios de configuración requiere mucha plomería de su parte, y las cosas se vuelven aún más dramáticas si tiene que soportar diálogos de progreso durante los cambios de orientación de la pantalla.
Aunque la mayoría de la gente opta por la solución rápida cambiando el manifiesto y configurando su actividad con android: configChanges = "keyboardHidden | orientation", creo que es importante darse cuenta de que hay alternativas a esto.
Requiere más código, pero le da una mejor visión de cómo funciona el sistema en general.
Es extraño que Google realmente no habla más sobre el razonamiento detrás de él, pero realmente hay tres razones principales que puedo pensar en evitar el uso de ese enfoque:
- En mi experiencia, algunos tipos de vista (especialmente WebViews y MapViews en Android 2.1 o inferior) pueden comportarse de forma bastante extraña después del cambio de orientación si no se han recreado (botones de zoom erróneos, por ejemplo).
- Le impide utilizar diseños orientativos específicos (consulte la vista horizontal de la nueva aplicación Market, por ejemplo).
- Puede impedir que descubra el comportamiento de errores de su aplicación en relación con otros tipos de razones por las que su actividad podría ser destruida y recreada (por ejemplo, baja memoria u otras matanzas normales mientras está en segundo plano). Es decir, si su actividad puede manejar con gracia un reinicio debido a la rotación, probablemente puede manejar un reinicio debido a la muerte de fondo. Sin embargo, si omite la manipulación de la rotación, es posible que no se reinicie debido a una matanza de fondo bajo pruebas normales hasta que un usuario con un teléfono de memoria baja antiguo registre un informe de error.
La última razón es la grande; Especialmente con los teléfonos más antiguos de baja RAM y con los comportamientos supuestamente más agresivos de autokilling en Gingerbread, sus actividades necesitan saber cómo ser recreados rápidamente después de una destrucción al guardar su estado, independientemente del manejo de la orientación. Y una vez que sus actividades pueden manejar ese tipo de destrucción / recreación, es probable que todos los establecidos para el cambio de rotación mata de todos modos. Usted puede ganar cierta velocidad absorbiendo el evento de rotación (ya que no tiene que volver a través de la inflación de diseño y todo eso), pero eso es todo, en ese momento.
Si decides tragar rotaciones, recomiendo siempre usar un emulador o dispositivo con la opción "Destruir actividades inmediatamente" de Development.apk marcada y, a continuación, asegurarse de que cambiar las aplicaciones o el respaldo a través de la pila de tareas siga funcionando correctamente.
En mi experiencia, la absorción de rotaciones en realidad puede ser una buena opción para una experiencia de usuario mejorada, especialmente en actividades con diseños complejos que pueden tardar unos momentos en volver a crear, pero realmente necesita probar cuidadosamente y efectivamente que su actividad siga funcionando incluso sin La rotación-ignorando.
- Cómo utilizar SearchView de tema oscuro en el tema Light Appcompat
- El encabezado ListView ignora el layout_height