¿Por qué no usar siempre android:configChanges=”keyboardHidden|orientation”?

10 minutos de lectura

¿Por que no usar siempre androidconfigChangeskeyboardHiddenorientation
Mikooos

Me preguntaba por qué no usar android:configChanges="keyboardHidden|orientation" en cada (casi cada ;)) actividad?

Bienes:

  • no hay necesidad de preocuparse de que su actividad haya sido rotada
  • es mas rapido

No tan agradable:

  • necesita cambiar sus diseños si dependen del tamaño de la pantalla (por ejemplo, diseños con dos columnas más o menos)

Malo:

  • no hay forma flexible de tener diferentes diseños en diferentes orientaciones
  • no tan bueno cuando se usan fragmentos

Pero si no usamos diferentes diseños, ¿por qué no?

  • También debe explicar lo que pensar teclado oculto | orientación está haciendo

    – Blundell

    19 de octubre de 2011 a las 8:50

  • Impide el uso del manejo nativo de cambios de configuración específicos y permite que la aplicación los maneje, ¿no es así?

    – Mikooos

    19 de octubre de 2011 a las 10:39

  • Es por eso que esta opción está ahí, si sabe lo que está haciendo (sin cambios en los recursos), utilícela.

    – Puntero nulo

    31/10/2011 a las 21:23

  • ¿Por qué es más rápido que usar ScreenSize?

    – Emilio

    30 de mayo de 2017 a las 13:59

1646966114 823 ¿Por que no usar siempre androidconfigChangeskeyboardHiddenorientation
yydl

Fondo rápido

De manera predeterminada, cuando ocurren ciertos cambios clave en la configuración de Android (un ejemplo común es un cambio de orientación), Android reinicia por completo la actividad en ejecución para ayudarla a adaptarse a dichos cambios.

cuando defines android:configChanges="keyboardHidden|orientation" en su AndroidManifest, le está diciendo a Android: “Por favor, no haga el restablecimiento predeterminado cuando se saca el teclado o se gira el teléfono; quiero manejar esto yo mismo. Sí, sé lo que estoy haciendo”.

¿Es esto algo bueno? Pronto veremos…

¿Sin preocupaciones?

Uno de los pros con los que comienzas es que hay:

no hay necesidad de preocuparse de que su actividad haya sido rotada

En muchos casos, las personas creen erróneamente que cuando tienen un error que está siendo generado por un cambio de orientación (“rotación”), simplemente pueden arreglarlo poniendo android:configChanges="keyboardHidden|orientation".

Sin embargo, android:configChanges=”keyboardHidden|orientation” no es más que una tirita. En realidad, hay muchas formas de activar un cambio de configuración. Por ejemplo, si el usuario selecciona un nuevo idioma (es decir, la configuración regional ha cambiado), su actividad se reiniciará de la misma manera que lo hace con un cambio de orientación. Si quieres puedes ver una lista de todos los diferentes tipos de cambios de configuración.

Editar: Sin embargo, lo que es más importante, como señala hackbod en los comentarios, su actividad también se reiniciará cuando su aplicación esté en segundo plano y Android decida liberar algo de memoria eliminándola. Cuando el usuario regrese a su aplicación, Android intentará reiniciar la actividad de la misma manera que lo hace si hubo algún otro cambio de configuración. Si no puede manejar eso, el usuario no estará contento…

En otras palabras, usando android:configChanges="keyboardHidden|orientation" no es una solución para sus “inquietudes”. La forma correcta es codificar sus actividades para que estén contentos con cualquier reinicio que les arroje Android. Esta es una buena práctica que te ayudará en el futuro, así que acostúmbrate.

Entonces, ¿cuándo debo usarlo?

Como mencionaste, hay una clara ventaja. Sobrescribir el cambio de configuración predeterminado para una rotación manejándolo usted mismo acelerará las cosas. Sin embargo, esta velocidad viene con un precio de conveniencia.

En pocas palabras, si usa el mismo diseño tanto para el retrato como para el paisaje, está en buena forma al sobrescribir. En lugar de una recarga completa de la actividad, las vistas simplemente cambiarán para llenar el espacio restante.

Sin embargosi por alguna razón usas un diseño diferente cuando el dispositivo está en horizontal, el hecho de que Android vuelva a cargar tu Actividad es bueno porque luego cargará el diseño correcto. [If you use the override on such an Activity, and want to do some magical re-layout at runtime… well, good luck – it’s far from simple]

Sumario rápido

Por todos los medios, si android:configChanges="keyboardHidden|orientation" es adecuado para usted, entonces utilícelo. Pero POR FAVOR asegúrese de probar qué sucede cuando algo cambia, porque un cambio de orientación no es la única forma en que se puede activar un reinicio completo de la actividad.

  • Vale la pena agregar que no manejar el reinicio de su actividad significa que tiene problemas más grandes que simplemente no manejar cambios de configuración menos comunes. El reinicio de la actividad que se usa aquí es exactamente el mismo mecanismo con el que Android restaura su actividad a su estado anterior cuando su aplicación se cierra en segundo plano. Entonces, si no está haciendo esto correctamente, sus usuarios experimentarán que su aplicación aleatoriamente no volverá correctamente cuando regresen a ella desde el fondo, dependiendo de si el proceso se cerró. Entonces, un gran beneficio: se asegura de que su aplicación se reinicie correctamente.

    – hackbod

    4 de noviembre de 2011 a las 6:46

  • A partir de Android 3.x, no olvide agregar “screenSize” ———- android:configChanges=[“mcc”, “mnc”, “locale”, “touchscreen”, “keyboard”, “keyboardHidden”, “navigation”, “screenLayout”, “fontScale”, “uiMode”, “orientation”, “screenSize”, “smallestScreenSize”]

    –Michael Biermann

    10 de diciembre de 2012 a las 21:26


  • Me di cuenta de que cuando usa el atributo configChanges, su aplicación también ignora la función de bloqueo de orientación. ¿Cómo puedes resolver esto? si sabe la respuesta, escríbala aquí: stackoverflow.com/questions/24000361/…

    – desarrollador de Android

    2 de junio de 2014 a las 17:55

  • Please don't do the default reset when the keyboard is pulled out nunca he visto un reinicio de actividad para Sacar el teclado!

    – Muhammad Babar

    1 de diciembre de 2014 a las 7:28

  • Lamentablemente, esta respuesta no menciona la explicación principal del funcionario Documentación de Google. El problema principal está en los conjuntos de recursos alternativos, que no se aplican automáticamente al cambiar la configuración, en caso de que desee manejarlos manualmente. Y afecta no solo a la Actividad en cuestión sino a toda la aplicación.

    – Corifeo

    15 de enero de 2016 a las 11:46

Desde mi punto de vista: si el diseño es el mismo tanto en modo horizontal como vertical, también puede desactivar uno de los dos en su aplicación.

La razón por la que afirmo esto es que yo, como usuario, espero que la aplicación me brinde algún beneficio cuando cambio de orientación. Si no importa cómo sostenga mi teléfono, entonces no necesito elegir.

Tomemos, por ejemplo, una aplicación en la que tiene un ListView y, al hacer clic en ListItem, desea que se le muestre una vista detallada de ese elemento. En horizontal, haría esto dividiendo la pantalla en dos, teniendo ListView a la izquierda y la vista detallada a la derecha. En Portrait tendría la lista en una pantalla y luego cambiaría la pantalla a la vista detallada cuando se selecciona un ListItem. En ese caso, el cambio de orientación tiene sentido, así como diferentes diseños.

  • Sí, usamos eso en la versión 1.0 de nuestra aplicación, para que coincida con nuestro lanzamiento de Apple. Se presentó SOLO en retrato. Lo cual se veía muy bien en mi Droid X, igualamos exactamente el comportamiento del teclado emergente de la versión IOS. Luego, el director financiero instaló la aplicación en su Droid, la giró hacia un lado y abrió el teclado. UPS. Lo que pasa con Android es que es una plataforma abierta y realmente no puedes predecir la configuración del hardware o lo que el usuario querrá hacer con él, por lo que probablemente deberías admitir ambas (todas) orientaciones por si acaso.

    – Tevo D.

    1 de noviembre de 2011 a las 18:45

  • Lo que, por cierto, anuló nuestra configuración de solo retrato, ya que básicamente estaba en el hardware que el paisaje era entonces la orientación normal, no alternativa. Lo que REALMENTE arruinó nuestro diseño 🙁 y fue bastante vergonzoso, tener una falla importante a los pocos segundos de instalar la aplicación

    – Tevo D.

    1 de noviembre de 2011 a las 18:51


  • ¿Por qué estabas tratando de hacer que se comportara exactamente como iOS? 🙁

    – FunkTheMonk

    1 de noviembre de 2011 a las 20:53

  • @FunkTheMonk Desafortunadamente vivimos en un mundo donde los empresarios toman decisiones técnicas. Incluso si argumentas en contra, la mitad de las veces piensan que tienen razón de todos modos. Y controlan su cheque de pago.

    – Pila desbordada

    25 de junio de 2012 a las 2:11

  • Usar solo un diseño no significa que la pantalla se verá igual cuando se gire. Un diseño XML bien estructurado hará que las cosas cambien automáticamente para funcionar bien con dimensiones razonables, y los usuarios lo apreciarán.

    – Melinda Verde

    9 de noviembre de 2012 a las 0:12

¿Por que no usar siempre androidconfigChangeskeyboardHiddenorientation
Renetik

No veo por qué… en mi opinión, los reinicios ocasionales están bien… configChanges maneja la mayoría de los casos por mí… bueno, tal vez en algunos tipos de aplicaciones esto puede ser un problema, pero depende realmente del tipo de aplicación y de cómo restaure estado cuando la aplicación se reinicia… Cuando una de mis aplicaciones se reinicia, el usuario vuelve a iniciar sesión y la última actividad se abre con mi código y el usuario solo pierde algunos pasos para volver a donde estaba, pero no es gran cosa… En otro estado, siempre persiste y algún estado siempre se restaura al reiniciar. Cuando se reinició la actividad, tenía que ser que la aplicación no se había utilizado o algo así… así que no hay problema en absoluto… En el juego, por ejemplo, esto puede ser un problema tal vez o en algún otro tipo de aplicación que no sé…

Yo digo que cuando lo haces de esta manera, las aplicaciones funcionan bien en circunstancias normales. Y el código es mucho más legible sin una tonelada de lógica necesaria para guardar y restaurar donde solo puede crear nuevos errores y tiene que mantenerlo todo el tiempo … seguro que si Android se queda sin energía y elimina la ventana de la aplicación, perderá el contexto y comienza de nuevo, pero esto sucede solo en situaciones especiales y en dispositivos más nuevos, creo que esto es cada vez más raro…

Así que mátame, pero uso esto en todas las aplicaciones con bastante éxito… android:configChanges=”locale|keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize” buena manera, pero la mayoría de las aplicaciones pueden vivir con esto, simplemente está bien.

  • Hola, ¿alguien que tenga conocimientos sobre este tema puede echar un vistazo a mi hilo: stackoverflow.com/questions/35941585/…? Necesito ayuda desesperadamente.

    – Lucas Allison

    14 de marzo de 2016 a las 4:28

  • Debe admitir completamente guardar/reanudar actividades… manejarlo para la rotación no es diferente… Dice que pierde algunos pasos… si lo hace correctamente, no pierde ningún paso y restaura exactamente donde lo dejó el usuario … incluso después de reiniciar el dispositivo.

    – MARTILLADO

    7 dic 2016 a las 18:46

  • martillado No sé de qué estás hablando, pero digo que cuando lo haces de esta manera, las aplicaciones funcionan bien en circunstancias normales. Y el código es mucho más legible sin una tonelada de lógica necesaria para guardar y restaurar donde solo puede crear nuevos errores y tiene que mantenerlo todo el tiempo … seguro que si Android se queda sin energía y elimina la ventana de la aplicación, perderá el contexto y comienza de nuevo, pero esto sucede solo en situaciones especiales y en dispositivos más nuevos, creo que esto es cada vez más raro…

    – Renetik

    8 de diciembre de 2016 a las 1:56


  • Ignorar el cumplimiento del contrato de actividad (estado de ahorro/restauración) es una mala práctica y, en general, es un consejo terrible. Intente probar contra la muerte del proceso y vea a dónde lo lleva su aplicación, y este comportamiento es una “circunstancia normal” completamente estándar si su usuario usa al menos 2-3 aplicaciones en su teléfono y cambia entre ellas.

    – EpicPandaForce

    16 de enero de 2018 a las 12:49

  • Deberías estar usando un servicio para reproducir música. En serio, le está diciendo a la gente que agregue un código que todavía tiene ” // TODO stub de método generado automáticamente”. Solución descuidada. Tampoco funcionará bien, deberá volver a vincular todas sus referencias y, si no lo hace, serán impredecibles en el mejor de los casos.

    – MARTILLADO

    07/12/2016 a las 18:39

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad