Android: problemas con una cadena de actividad multinivel
(Tenga en cuenta que he buscado en línea las advertencias que estoy describiendo a continuación, y he llegado con casi nada sobre ellos.)
Estoy trabajando con el nivel de API 10. Tengo una pantalla de preferencias (basada en XML), y una de las opciones de allí crea una ListActivity personalizada de la siguiente manera:
- Android Intents - putExtra, ¿qué sucede con ocurrencias múltiples?
- Cómo obtener extras de la actividad actualmente en ejecución a través de ADB
- Error de compra de la aplicación en códigos estáticos
- Ninguna actividad encontrada para manejar Intent action.VIEW al hacer clic en el enlace de correo electrónico
- ¿Es posible falsificar un SMS entrante en Android?
- PreferenceActivity contiene una opción que crea una …
- ListActivity que es un diálogo que emplea …
- SetOnClickListener () que contiene un método onClick () que ( justo antes de llamar a finish () ) startActivity () una nueva intención …
- Sub-Actividad que arranca una …
- AsyncTask que hace el trabajo de tiempo variable que cuando se hace llamadas …
- OnPostExecute () que llama a finish ()
- Sub-Actividad que arranca una …
- SetOnClickListener () que contiene un método onClick () que ( justo antes de llamar a finish () ) startActivity () una nueva intención …
- ListActivity que es un diálogo que emplea …
La cosa es, funciona … pero estoy recibiendo una serie de advertencias empezando por:
10-16 21:59:25.010: WARN/WindowManager(170): Rebuild removed 4 windows but added 3 10-16 21:59:25.010: WARN/WindowManager(170): This window was lost:.....
Curiosamente, esta balsa de advertencias sólo aparece cuando la tarea se ejecuta rápidamente! Cuando agregué una llamada de Thread.sleep () a mi AsyncTask para inflar artificial su funcionamiento funcionó y no lanzó ningunas advertencias cualesquiera. De hecho, siempre y cuando se necesita más de (aproximadamente) 500 ms para ejecutar funciona bien. (Tenga en cuenta que he intentado usar startActivityForResult () sin mayor efecto – el mismo problema ocurre.)
El objetivo es que el usuario seleccione un elemento de preferencia, cambie su configuración, se realice algún procesamiento y, a continuación, el usuario se deja atrás en el menú de preferencias en el que comenzó.
Estoy apostando que es una condición de carrera … el orden en que se destruyen las ventanas varía dependiendo de ese tiempo de ejecución … y tengo la impresión de que cuando la subactividad se cierra antes de su lista de padres ListActivity se lanzan las advertencias. Pero rociar un 1s dormir () en no es una solución razonable a menos que esto sea algún tipo de error de Android (improbable, pero de nuevo he reproducido un par de los que hoy ya).
Entonces, ¿cuál es el defecto en este mi que lleva a esta corriente de advertencias? Sería bueno decir "de preferencia, hacer esto, luego hacer eso, y luego terminar", pero creo que lo que estoy haciendo es el equivalente. Tal vez no … pensamientos?
Edit: He decidido intentar hacer esto ListActivity como un cuadro de diálogo personalizado … que fue una de las cosas más dolorosas que he intentado hacer últimamente (getApplication () no funciona y muchas otras cosas parecen ir mal .. Puede ser inexperiencia hasta cierto punto, pero los diálogos realmente no estaban destinados a esto tampoco …
- Pasar encabezados mientras utiliza la intención del navegador
- Intención de ir a la página de configuración de una cuenta específica
- GMail para KitKat se bloquea al enviar archivos adjuntos que no son imágenes o videos
- ¿Cómo cancelar la tarea de repetición en el Administrador de alarmas?
- Archivo de exportación desde una aplicación de Android a la aplicación de calendario de Google
- No se puede comprobar si AlarmManager ha configurado la alarma
- Acciones personalizadas con intenciones implícitas entre aplicaciones
- ¿Es mejor pasar los datos por intención o consultar la base de datos cuando sea necesario?
Pruebe las siguientes dos cosas:
-
Descarte su diálogo antes de llamar a finish () en su actividad principal (PreferenceActivity).
-
Asegúrese de iniciar su AsyncTask más adelante en el ciclo de vida de la subactividad. Estoy pensando específicamente que usted debe lanzarlo en onResume ().
Mi mejor suposición es que el AsyncTask está llamando a finish () en la subactividad, antes de que la subactividad haya tenido la oportunidad de iniciarse completamente. ¿Por qué eso importaría? No estoy seguro. Algo para probar aunque. ¡Buena suerte!
- ¿Alguien ha encontrado una solución para el error Cordova Android keyboard?
- Sincronización entre la base de datos SQL Lite en un dispositivo android y la base de datos de SQL Server