pie - android versiones

¿Está mal visto dejar una aplicación? (30)

Respuesta: (Romain Guy): El usuario no, el sistema maneja esto automáticamente. Para eso es el ciclo de vida de la actividad (especialmente onPause / onStop / onDestroy). No importa lo que haga, no ponga el botón de aplicación "salir" o "salir". Es inútil con el modelo de aplicación de Android. Esto también es contrario a cómo funcionan las aplicaciones principales.

1: Salir totalmente de una aplicación puede ser generalmente no obligatorio, pero no es inútil. ¿Qué pasa si Windows no tiene opción de salida? El sistema sería doggy lento ya que la memoria estaba llena y el sistema operativo tenía que adivinar qué programas había terminado. No me importa lo que digan Romain Guy o incluso Larry Page y Sergey Brin: estos son hechos incuestionables: los sistemas funcionan más lentamente cuando tienen que eliminar tareas para recuperar su memoria antes de poder lanzar una nueva aplicación. ¡No puedes decirme que no lleva tiempo matar una aplicación! Incluso la luz de las estrellas lejanas tomar tiempo ... No es cierto uso en que permite al usuario cerrar totalmente aplicaciones.

2: ¿Contrario a cómo funcionan las aplicaciones principales? ¿Que se supone que significa eso? Cuando termine de ejecutar una aplicación por ahora, ya no está haciendo ningún trabajo ... Solo está esperando que el sistema operativo lo mate cuando se necesite su memoria.

En resumen, hay una clara diferencia entre minimizar y salir, y ninguno de los dos puede golpear bien al otro. ¿Dejamos un destornillador en cada tornillo? ¿O una llave en cada puerta? ¿Dejamos todos nuestros electrodomésticos a toda velocidad hasta que el disyuntor explote y tengamos que encender otro electrodoméstico? ¿Dejamos el lavaplatos lleno de platos y solo sacamos lo suficiente cada vez para dejar espacio para algunos nuevos sucios? Dejamos todos los autos corriendo en el camino de entrada hasta que ... no importa.

Si el usuario quiere minimizar una aplicación, entonces lo mejor es minimizarla. Si un usuario quiere salir de una aplicación, entonces por todos los medios es mejor salir.

¿Está mal visto? Esa es la opinión de Android: fruncen el ceño. Y muchos de los desarrolladores independientes de Android novatos fruncen el ceño.

Pero cuando se trata de eso, hay una buena codificación y una mala codificación. Hay buenos modelos de flujo de programa y hay malos modelos de flujo de programa.

Dejar los programas en la memoria cuando el usuario sabe que han terminado con ellos simplemente no es un buen flujo de programas. No tiene ningún propósito en absoluto, y ralentiza las cosas cuando se inician nuevas aplicaciones o cuando se ejecutan, asignan más memoria.

Es algo así como su automóvil: hay veces en que lo deja en marcha, como parar en un semáforo, o tal vez pasar por la comida rápida, o detenerse en el cajero automático. Pero hay otras situaciones en las que quiere apagarlo, como cuando va al trabajo, en el supermercado o incluso en su casa.

Del mismo modo, si estás jugando un juego y suena el teléfono, sí. Pausa el juego y sigue funcionando. Pero si el usuario termina con el juego por un tiempo, entonces déjelo salir.

El botón de salida en algunas aplicaciones debería estar más al frente que otras. Los juegos, por ejemplo, o los programas en los que es probable que el usuario quiera salir completamente, deberían tener una salida obvia. Otros programas, como, tal vez, los programas de correo electrónico, donde salir es un deseo improbable (para que pueda seguir revisando el correo electrónico): estos programas no deben desperdiciar el espacio de la pantalla de entrada de control principal con una opción de salida, pero para un buen flujo de programas, Debe tener una opción de salida. ¿Qué sucede si alguien decide que no quiere que su programa de correo electrónico intente revisar el correo electrónico cuando se encuentra en un área de cobertura deficiente, o tal vez en una llamada de Skype o lo que sea? ¡Déjalos salir del programa de correo electrónico si quieren!

Suspender y salir son dos tareas vitales y ninguna cumple el rol de la otra.

Continuando con mi intento de aprender Android, acabo de leer lo siguiente :

Pregunta: ¿Tiene el usuario la opción de eliminar la aplicación a menos que pongamos una opción de menú para eliminarla? Si no existe tal opción, ¿cómo termina la aplicación el usuario?
Respuesta: (Romain Guy): El usuario no, el sistema maneja esto automáticamente. Para eso es el ciclo de vida de la actividad (especialmente onPause / onStop / onDestroy). No importa lo que haga, no ponga el botón de aplicación "salir" o "salir". Es inútil con el modelo de aplicación de Android. Esto también es contrario a cómo funcionan las aplicaciones principales.

Jeje, por cada paso que doy en el mundo de Android me encuentro con algún tipo de problema = (

Aparentemente, no puede salir de una aplicación en Android (pero el sistema Android puede destruir totalmente su aplicación cuando lo desee). ¿Que pasa con eso? Estoy empezando a pensar que es imposible escribir una aplicación que funcione como una "aplicación normal", que el usuario pueda abandonar la aplicación cuando decida hacerlo. Eso no es algo que se deba confiar en el sistema operativo para hacer.

La aplicación que estoy tratando de crear no es una aplicación para Android Market. No es una aplicación para "uso general" por parte del público en general, es una aplicación de negocios que se utilizará en un campo de negocios muy limitado.

Tenía muchas ganas de desarrollar para la plataforma Android, ya que aborda muchos de los problemas que existen en Windows Mobile y .NET. Sin embargo, la última semana ha sido algo así como un desvío para mí ... Espero no tener que abandonar Android, pero no se ve muy bien en este momento = (

¿Hay alguna manera de que realmente salga de la aplicación?

Con el tiempo, llegará a su pregunta, pero primero quiero abordar una serie de cuestiones que plantea en sus diversos comentarios a las diversas respuestas ya dadas en el momento de escribir este artículo. No tengo intención de cambiar de opinión; más bien, estos están aquí para otros que vengan a leer esta publicación en el futuro.

El punto es que no puedo permitir que Android determine cuándo se terminará mi aplicación. Esa debe ser la elección del usuario.

Millones de personas están perfectamente satisfechas con el modelo donde el entorno cierra la aplicación según sea necesario. Esos usuarios simplemente no piensan en "terminar" la aplicación de Android, como tampoco piensan en "terminar" una página web o "terminar" un termostato.

Los usuarios de iPhone son muy parecidos, ya que al presionar el botón del iPhone no necesariamente se "siente" como si la aplicación hubiera finalizado, ya que muchas aplicaciones de iPhone se retoman donde el usuario las dejó, incluso si la aplicación realmente se cerró permite una aplicación de terceros a la vez, en la actualidad).

Como dije anteriormente, hay muchas cosas que están sucediendo en mi aplicación (los datos se PULSAN al dispositivo, listas con las tareas que siempre deberían estar ahí, etc.).

No sé lo que significa "listas con tareas que siempre deberían estar ahí", pero los "datos PUSHed al dispositivo" son una ficción agradable y no deben hacerse en ningún caso por una actividad. Use una tarea programada (a través de AlarmManager ) para actualizar sus datos para obtener la máxima confiabilidad.

Nuestros usuarios inician sesión y no pueden hacerlo cada vez que reciben una llamada y Android decide cancelar la aplicación.

Hay muchas aplicaciones de iPhone y Android que tratan con esto. Por lo general, se debe a que mantienen las credenciales de inicio de sesión, en lugar de obligar a los usuarios a iniciar sesión de forma manual.

Por ejemplo, queremos comprobar las actualizaciones al salir de la aplicación.

Eso es un error en cualquier sistema operativo. Por todo lo que sabe, la razón por la que su aplicación está "saliendo" es porque el sistema operativo se está cerrando, y luego el proceso de actualización fallará a mitad de la secuencia. En general, eso no es algo bueno. O verifique las actualizaciones en el inicio o las actualizaciones de forma totalmente asíncrona (por ejemplo, a través de una tarea programada), nunca en la salida.

Algunos comentarios sugieren que presionar el botón Atrás no mata la aplicación en absoluto (vea el enlace en mi pregunta más arriba).

Presionar el botón ATRÁS no "mata la aplicación". Finaliza la actividad que estaba en pantalla cuando el usuario presionó el botón ATRÁS.

Solo debe terminar cuando los usuarios quieran terminarlo, nunca de otra manera. Si no puedes escribir aplicaciones que se comportan así en Android, entonces creo que Android no puede usarse para escribir aplicaciones reales = (

Entonces tampoco pueden las aplicaciones web. O WebOS , si entiendo su modelo correctamente (aún no he tenido la oportunidad de jugar con uno). En todos esos, los usuarios no "terminan" nada, simplemente se van. El iPhone es un poco diferente, ya que actualmente solo permite que una cosa se ejecute a la vez (con algunas excepciones), por lo que el hecho de irse implica una terminación bastante inmediata de la aplicación.

¿Hay alguna manera de que realmente salga de la aplicación?

Como todos los demás le dijeron, los usuarios (a través de ATRÁS) o su código (a través de finish() ) pueden cerrar su actividad actual. En general, los usuarios no necesitan nada más, para las aplicaciones correctamente escritas, más de lo que necesitan una opción de "salir" para usar las aplicaciones web.

No hay dos entornos de aplicación iguales, por definición. Esto significa que puede ver tendencias en entornos a medida que surgen nuevos y otros se entierran.

Por ejemplo, hay un movimiento creciente para tratar de eliminar la noción del "archivo". La mayoría de las aplicaciones web no obligan a los usuarios a pensar en archivos. Las aplicaciones de iPhone normalmente no obligan a los usuarios a pensar en archivos. Las aplicaciones de Android generalmente no obligan a los usuarios a pensar en archivos. Y así.

De manera similar, hay un movimiento creciente para tratar de eliminar la noción de "terminar" una aplicación. La mayoría de las aplicaciones web no obligan al usuario a cerrar sesión, sino que lo cierran implícitamente después de un período de inactividad. Lo mismo con Android, y en menor medida, iPhone (y posiblemente WebOS).

Esto requiere un mayor énfasis en el diseño de la aplicación, centrándose en los objetivos de negocio y no apegarse a un modelo de implementación vinculado a un entorno de aplicación anterior. Los desarrolladores que carecen del tiempo o la inclinación para hacer esto se frustrarán con los entornos más nuevos que rompen su modelo mental existente. Esto no es culpa de ninguno de los entornos, como tampoco lo es la falla de una montaña por las tormentas que fluyen a su alrededor y no a través de ellas.

Por ejemplo, algunos entornos de desarrollo, como Hypercard y Smalltalk, tenían la aplicación y las herramientas de desarrollo unidas en una sola configuración. Este concepto no alcanzó gran parte de las extensiones de lenguaje de las aplicaciones (por ejemplo, VBA en Excel , Lisp en AutoCAD ). Los desarrolladores que crearon modelos mentales que presumían la existencia de herramientas de desarrollo en la propia aplicación, por lo tanto, tenían que cambiar su modelo o limitarse a entornos en los que su modelo fuera cierto.

Entonces, cuando escribes:

Junto con otras cosas desordenadas que descubrí, creo que el desarrollo de nuestra aplicación para Android no va a suceder.

Eso parece ser lo mejor, para ti, por ahora. De manera similar, le recomendaría que no intente portar su aplicación a la Web, ya que algunos de los mismos problemas que ha informado con Android también lo encontrarán en las aplicaciones Web (por ejemplo, no hay "terminación"). O, a la inversa, algún día, si transporta su aplicación a la Web, puede encontrar que el flujo de la aplicación Web puede ser una mejor opción para Android, y puede volver a visitar un puerto de Android en ese momento.

Deja de pensar en tu aplicación como una aplicación monolítica. Es un conjunto de pantallas de interfaz de usuario que el usuario puede interactuar con su "aplicación" y "funciones" proporcionadas a través de los servicios de Android.

No saber lo que tu misteriosa aplicación "hace" no es realmente importante. Asumamos que se conecta a una intranet corporativa super segura, realiza algún monitoreo o interacción y permanece conectado hasta que el usuario "abandona la aplicación". Debido a que su departamento de TI lo ordena, los usuarios deben estar muy conscientes de cuándo están ENTRADA o FUERA de la intranet. De ahí que su mentalidad sea importante para que los usuarios "abandonen".

Esto es simple. Haga un servicio que coloque una notificación en curso en la barra de notificaciones que diga "Estoy en la intranet o estoy en ejecución". Haga que ese servicio realice toda la funcionalidad que necesita para su aplicación. Tenga actividades que se unan a ese servicio para permitir que sus usuarios accedan a los bits de IU que necesitan para interactuar con su "aplicación". Y tiene un botón de Menú de Android -> Salir (o cerrar sesión, o lo que sea) que le dice al servicio que salga y luego cierra la actividad en sí.

Esto es, para todos los efectos, exactamente lo que usted dice que quiere. Hecho a la manera de Android. Mire en Google Talk o en Google Maps Navigation para ver ejemplos de esta "salida" es una mentalidad posible. La única diferencia es que al presionar el botón Atrás fuera de su actividad puede dejar su proceso UNIX en espera, en caso de que el usuario quiera reactivar su aplicación. Esto realmente no es diferente de un sistema operativo moderno que almacena en la memoria caché los archivos a los que se accede recientemente. Después de salir de su programa de Windows, los recursos más probables que necesitaba aún están en la memoria, esperando ser reemplazados por otros recursos a medida que se cargan ahora que ya no son necesarios. Android es lo mismo.

Realmente no veo tu problema

Esta es una discusión interesante y perspicaz con muchos expertos que contribuyen. Siento que esta publicación debería volver desde el sitio web principal de desarrollo de Android, ya que gira en torno a uno de los diseños centrales del sistema operativo Android.

También me gustaría añadir mis dos centavos aquí.

Hasta el momento, me ha impresionado la forma en que Android maneja los eventos del ciclo de vida, llevando el concepto de una experiencia similar a la web a las aplicaciones nativas.

Dicho esto, sigo creyendo que debería haber un botón Salir . ¿Por qué? ... no para mí ni para Ted ni para ninguno de los gurús de la tecnología, sino con el único propósito de satisfacer la demanda de un usuario final.

Aunque no soy un gran fanático de Windows, pero hace mucho tiempo introdujeron un concepto al que la mayoría de los usuarios finales están acostumbrados (un botón X) ... "Quiero dejar de ejecutar un widget cuando ''yo'' quiero".

Eso no significa que alguien (OS, desarrollador?) Se encargará de eso a su propia discreción ... simplemente significa "¿dónde está mi botón X rojo al que estoy acostumbrado?". Mi acción debería ser análoga a ''terminar una llamada al presionar un botón'', ''apagar el dispositivo presionando un botón'', y así sucesivamente ... es una percepción. Es una satisfacción per se que mi acción efectivamente logre su propósito.

Aunque un desarrollador puede simular este comportamiento utilizando las sugerencias que se ofrecen aquí, la percepción aún permanece, es decir, una aplicación debería dejar de funcionar (ahora) por una fuente independiente, confiable y neutral (OS) a pedido del usuario final.

Este debate se reduce a la antigua pregunta de si los desarrolladores saben mejor o si el usuario sabe mejor. Diseñadores profesionales en todas las áreas de los factores humanos luchan con esto todos los días.

Ted ha señalado que una de las aplicaciones más descargadas en el mercado es el ''App Killer''. Las personas obtienen un poco de serotonina adicional cuando abandonan las aplicaciones. Están acostumbrados a ello con una computadora de escritorio / portátil. Mantiene las cosas en movimiento rápido. Mantiene el procesador frío y el ventilador se enciende. Utiliza menos energía.

Cuando considera que un dispositivo móvil es un barco mucho más pequeño, entonces puede apreciar especialmente su incentivo para "arrojar por la borda lo que ya no necesita". Ahora los desarrolladores de Android han razonado que el sistema operativo es el que mejor conoce y que abandonar una aplicación es antiguo. Apoyo de todo corazón esto.

Sin embargo, también creo que no debe frustrar al usuario, incluso si esa frustración se debe a su propia ignorancia. Debido a eso, llego a la conclusión de que tener una opción ''Salir'' es un buen diseño, incluso si se trata principalmente de un botón de placebo que no hace más que cerrar una vista.

Puede salir, ya sea presionando el botón Atrás o llamando a finish() en su Activity . Simplemente llame a finish() desde un MenuItem si desea eliminarlo explícitamente.

Romain no está diciendo que no se pueda hacer, solo que no tiene sentido: los usuarios no tienen que preocuparse por dejar de fumar o guardar su trabajo o lo que sea, ya que la forma en que funciona el ciclo de vida de la aplicación lo alienta a escribir software inteligente que guarda y Restaura su estado sin importar lo que pase.

Solo me gustaría agregar una corrección aquí para los futuros lectores de este hilo. Este matiz en particular se me escapó durante mucho tiempo, así que quiero asegurarme de que ninguno de ustedes cometa los mismos errores:

System.exit() no mata tu aplicación si tienes más de una actividad en la pila. Lo que realmente sucede es que el proceso se interrumpe y se reinicia de inmediato con una actividad menos en la pila. Esto también es lo que sucede cuando su aplicación es eliminada por el cuadro de diálogo Forzar cierre, o incluso cuando intenta eliminar el proceso desde DDMS. Este es un hecho que es completamente indocumentado, que yo sepa.

La respuesta corta es que, si desea salir de su aplicación, debe realizar un seguimiento de todas las actividades en su pila y finish() TODAS cuando el usuario desea salir (y no, no hay manera de iterar). la pila de actividades, así que tienes que gestionar todo esto por ti mismo). Incluso esto realmente no mata el proceso ni ninguna de las referencias pendientes que pueda tener. Simplemente termina las actividades. Además, no estoy seguro de si Process.killProcess(Process.myPid()) funciona mejor; No lo he probado.

Si, por otro lado, está bien que tengas actividades restantes en tu pila, hay otro método que te facilita las cosas: Activity.moveTaskToBack(true) simplemente mostrará el proceso y mostrará la pantalla de inicio.

La respuesta larga implica la explicación de la filosofía detrás de este comportamiento. La filosofía nace de una serie de suposiciones:

En primer lugar, esto solo sucede cuando su aplicación está en primer plano. Si está en el fondo, el proceso terminará bien. Sin embargo, si está en primer plano, el sistema operativo asume que el usuario desea seguir haciendo lo que estaba haciendo. (Si está intentando eliminar el proceso desde DDMS, primero debe presionar el botón de inicio y luego eliminarlo)
También supone que cada actividad es independiente de todas las demás actividades. Esto suele ser cierto, por ejemplo, en el caso de que su aplicación inicie la Actividad del navegador, que es completamente independiente y no fue escrita por usted. La actividad del navegador puede o no crearse en la misma tarea, en función de sus atributos manifiestos.
Asume que cada una de sus actividades es completamente autosuficiente y que puede cancelarse / restaurarse en cualquier momento. (Más bien me disgusta esta suposición en particular, ya que mi aplicación tiene muchas actividades que se basan en una gran cantidad de datos almacenados en caché, demasiado grandes para ser serializados de manera eficiente durante el estado de onSaveInstanceState , pero ¿qué haremos?) Para la mayoría de las aplicaciones de Android bien escritas, esto debería ser cierto. , ya que nunca se sabe cuándo se eliminará tu aplicación en segundo plano.
El factor final no es tanto una suposición, sino una limitación del sistema operativo: matar a la aplicación explícitamente es lo mismo que la aplicación que falla, y también lo mismo que Android matar a la aplicación para recuperar memoria. Esto culmina en nuestro golpe de gracia: ya que Android no puede saber si la aplicación salió o se bloqueó o se eliminó en segundo plano, se supone que el usuario quiere regresar donde lo dejó, y así el ActivityManager reinicia el proceso.

Cuando lo piensas, esto es apropiado para la plataforma. Primero, esto es exactamente lo que sucede cuando el proceso se cancela en segundo plano y el usuario vuelve a él, por lo que debe reiniciarse donde lo dejó. En segundo lugar, esto es lo que sucede cuando la aplicación falla y presenta el temido cuadro de diálogo Forzar cierre.

Digamos que quiero que mis usuarios puedan tomar una foto y subirla. Inicio la actividad de la cámara desde mi actividad y le pido que devuelva una imagen. La cámara se coloca en la parte superior de mi tarea actual (en lugar de crearla en su propia tarea). Si la cámara tiene un error y se bloquea, ¿debería dar lugar a que la aplicación se bloquee? Desde el punto de vista del usuario, solo la cámara falló y deberían volver a su actividad anterior. Así que solo reinicia el proceso con todas las mismas Actividades en la pila, menos la Cámara. Debido a que sus Actividades deben diseñarse de modo que puedan eliminarse y restaurarse en un abrir y cerrar de ojos, esto no debería ser un problema. Desafortunadamente, no todas las aplicaciones se pueden diseñar de esa manera, por lo que es un problema para muchos de nosotros, sin importar lo que Romain Guy o cualquier otra persona le diga. Por lo tanto, tenemos que utilizar soluciones provisionales.

Entonces, mi último consejo:

No trates de matar el proceso. O llame a finish() en todas las actividades o llame a moveTaskToBack(true) .
Si su proceso se bloquea o muere, y si, como yo, necesita los datos que estaban en la memoria que ahora está perdida, tendrá que volver a la actividad raíz. Para hacer esto, debe llamar a startActivity() con un Intent que contiene el indicador Intent.FLAG_ACTIVITY_CLEAR_TOP .
Si desea eliminar su aplicación desde la perspectiva de Eclipse DDMS, es mejor que no esté en primer plano o se reiniciará solo. Primero debe presionar el botón Inicio y luego finalizar el proceso.

Todas mis aplicaciones tienen botones de salir ... y con frecuencia recibo comentarios positivos de los usuarios debido a eso. No me importa si la plataforma fue diseñada de una manera que las aplicaciones no deberían necesitar. Decir "no los pongas allí" es algo ridículo. Si el usuario desea salir ... les proporciono el acceso para hacer exactamente eso. No creo que reduzca el funcionamiento de Android en absoluto y parece una buena práctica. Entiendo el ciclo de vida ... y mi observación ha sido que Android no hace un buen trabajo manejándolo ... y ese es un hecho básico.

En primer lugar, nunca nunca use System.exit (0). ¡Es como hacer dormir a una persona pegándole en la cabeza!

Segundo: Estoy enfrentando este problema. Antes de compartir mi solución a quiero compartir mis pensamientos.

Creo que un "botón de salida" es estúpido. Realmente realmente muy estúpido. Y creo que los usuarios (consumidores) que solicitan un botón de salida para su aplicación también son estúpidos. No entienden cómo funciona el sistema operativo ni cómo administran los recursos (y hace un gran trabajo).

Creo que si escribe un buen código que haga las cosas correctas (actualiza, guarda y empuja) en el momento y las condiciones correctas y utilizando las cosas correctas (Servicio y Receptor), funcionará bastante bien y nadie se quejará. .

Pero para hacer eso tienes que estudiar y aprender cómo funcionan las cosas en Android. De todos modos, esta es mi solución para proporcionar a los usuarios un "Botón de salida".

Creé un menú de opciones siempre visible en cada actividad (tengo una súper actividad que hace eso).

Cuando el usuario hace clic en ese botón, esto es lo que sucede:

Intent intent = new Intent(this, DashBoardActivity.class); intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP); intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE); SharedPreferences.Editor editor = settings.edit(); editor.putBoolean(FORCE_EXIT_APPLICATION, true); // Commit the edits! editor.commit(); startActivity(intent); finish();

Así que estoy guardando en SharedPreferences que quiero matar mi aplicación, y comienzo un intento. Por favor, mira esas banderas; esos borrarán todo mi backstack llamando a mi actividad de DashBoard que es mi actividad de "hogar".

Así que en mi Actividad del Tablero ejecuto este método en onResume:

private void checkIfForceKill() { // CHECK IF I NEED TO KILL THE APP // Restore preferences SharedPreferences settings = getSharedPreferences( getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE); boolean forceKill = settings.getBoolean( MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false); if (forceKill) { //CLEAR THE FORCE_EXIT SETTINGS SharedPreferences.Editor editor = settings.edit(); editor.putBoolean(FORCE_EXIT_APPLICATION, false); // Commit the edits! editor.commit(); //HERE STOP ALL YOUR SERVICES finish(); } }

Y funcionará bastante bien.

Lo único que no entiendo por qué está sucediendo es que cuando finalizo por última vez (y lo he comprobado: sigue todo el flujo correcto de onPause → onStop → onDestroy) la aplicación todavía está en la actividad reciente ( esta en blanco).

Parece que la última intención (que ha iniciado DashboardActivity) aún está en el sistema.

Tengo que cavar más para quitarlo también.

Cada vez que pase a la página siguiente a través de la intención, use:

`YourActivityname.this.finish()`;

Ejemplo:

Intent intent = new Intent(getApplicationContext(), SMS.class); startActivity(intent); MainActivity.this.finish();

Para que no se ejecute ninguna actividad en segundo plano y cuando desee salir de su aplicación, use:

MainActivity.this.finish(); android.os.Process.killProcess(android.os.Process.myPid()); System.exit(0); getParent().finish();

Esta salida funcionó como un encanto para mí :)

Cuando concibo una aplicación en Android, la veo de esta manera:

Estás trabajando con tu aplicación.
El teléfono sonó
Tu tomas la llamada
Al final de la llamada, regresa a su solicitud en el mismo lugar donde estaba

Para hacerlo, solo necesita el Backbotón o el Homebotón de su teléfono (ya sea con una pulsación corta o larga) y la barra de notificaciones.

Cuando salgo de mi aplicación, solo uso el Backbotón hasta que esté fuera de él o el Homebotón.

Así es como se conciben la mayoría de las aplicaciones, creo. Pero si necesito algún tipo de sesión o conexión, se lo dejé claro al usuario con un botón de inicio de sesión / cierre de sesión y una notificación (barra de título o cualquier otra cosa). Este es un estilo bastante diferente al de la aplicación de estilo puro "exit".

En las PC, tiene un escritorio de múltiples GUI y en Android, obviamente tiene tareas múltiples, pero solo muestra una aplicación a la vez (no considero los widgets aquí ^^) Y en un teléfono móvil, en cualquier momento, puede recibir una notificación de algo más importante que lo que está haciendo.

Por lo tanto, todo el concepto de una aplicación se basa en algo diferente que "ingrese application - work - exit application".

El ciclo de vida de la aplicación de Android está diseñado para usuarios de teléfonos móviles, no para usuarios de computadoras.

El ciclo de vida de la aplicación es el paradigma brutalmente simplista requerido para convertir un servidor Linux en un dispositivo para el consumidor.

Android es Java sobre Linux, un verdadero sistema operativo multiplataforma para servidores. Así es como se propagó tan rápido. El ciclo de vida de la aplicación encapsula la realidad subyacente del sistema operativo.

Para los usuarios móviles, las aplicaciones se instalan o no se instalan. No hay concepto de correr o salir. De hecho, los procesos de la aplicación deben ejecutarse hasta que el sistema operativo los libere para sus recursos retenidos.

Dado que se trata de , cualquier persona que lea esto es un usuario de computadora y debe desactivar el 90% de su conocimiento para comprender el ciclo de vida de la aplicación móvil.

En cualquier caso, si desea terminar su aplicación siempre puede llamar System.exit(0); .

Hmmmm ...

Creo que simplemente no ves la aplicación de Android de la manera correcta. Puedes hacer algo casi como lo que quieres fácilmente:

Haga las actividades de la aplicación guardar / restaurar el estado como se recomienda en la documentación del ciclo de vida del desarrollador.
Si se necesita algún inicio de sesión en la etapa de restauración (no hay información de inicio de sesión / sesión disponible), entonces hágalo.
Finalmente, agregue un botón / menú / tiempo de espera, en cuyo caso hará finish()sin guardar el inicio de sesión y otra información de la sesión, lo que hará implícitamente el final de la sesión de la aplicación: por lo tanto, si la aplicación se inicia / presenta nuevamente, comenzará una nueva sesión.

De esa manera, realmente no te importa si la aplicación es realmente eliminada de la memoria o no.

Si realmente desea eliminarlo de la memoria (esto no se recomienda y, ¿para qué sirve?), Puede matarlo condicionalmente al final onDestroy()con java.lang.System.exit(0)(o quizás restartPackage(..)?). Por supuesto, hágalo solo en el caso en el que desee "finalizar realmente la aplicación", ya que onDestroy()forma parte del ciclo de vida normal de las actividades y no es un fin de aplicación.

Me tomó más tiempo leer estas preguntas y respuestas que implementar un ciclo de vida de aplicaciones de Android semi-adecuado.

Es una aplicación de GPS que busca puntos y envía la ubicación actual a un servicio web cada pocos segundos utilizando un hilo ... Esto podría ser un sondeo cada 5 minutos en el caso de Ted para obtener una actualización, luego, OnStop simplemente puede iniciar la actividad de actualización. preocupado por si se encontró uno (Ted asíncrono, no codifique como un programador de Windows o sus programas se ejecutarán como programas de Windows ... eww, no es tan difícil).

Hice algo de código inicial en onCreate para configurar cosas para la vida útil de la actividad, incluido checkUpdate.start(); :

...

@Override public void onStart() { super.onStart(); isRemote = true; checkUpdate.resume(); locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh); } @Override public void onPause() { isRemote = false; checkUpdate.suspend(); locationManager.removeUpdates(luh); super.onStop(); }

Este código puede estar completamente equivocado, pero funciona. Esta es una de mis primeras aplicaciones de Android.

Voilà, una aplicación que no consume CPU cuando está en segundo plano, pero está lista para reabrirse instantáneamente porque está en la RAM (aunque no tiene RAM como el ciclo de vida de Android) ... una aplicación siempre está lista, es un teléfono , chicos / chicas. Si una aplicación utilizara toda la memoria RAM y el sistema operativo no pudiera apagarla, entonces la cosa podría dejar de sonar = P Es por eso que el sistema operativo debe poder cerrar la aplicación cuando está en segundo plano (si la aplicación no lo está) No es un recurso que no se cerrará (por cierto), así que escribamos mejores aplicaciones.

Si no puede entender cómo hacer que sus datos / conexiones (y, por lo tanto, su "aplicación") sean persistentes, no podrá hacer lo que "necesita" hacer con Android.

Aquellos que descargan esas lindas y pequeñas aplicaciones, los Asesinos generalmente descubren que no ayudan a la duración de la batería ni al uso de la memoria, pero dificultan que el sistema operativo haga su trabajo de administrar la memoria de manera eficiente ...

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Si tiene 10,20 ... múltiples actividades en ejecución y desea finalizarlas todas y salir del sistema.

Crear una matriz estática en application classoconstants class.

Constantes

public class Constants { public static ArrayList<Activity> activities = new ArrayList<Activity>(); }

MainActivity Agregar referencia de actividad actual en esta matriz

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity { private ImageView imageButton; private Activity activity; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); activity = MainActivity.this; Constants.activities.add(activity); imageButton = (ImageView) findViewById(R.id.camera); imageButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { // existing app. if (Constants.activities != null) { for (int i = 0; i < Constants.activities.size(); i++) { Activity s = Constants.activities.get(i); s.finish(); } } //super.finish(); finish(); android.os.Process.killProcess(android.os.Process.myPid()); System.exit(1); } }); } }

Sin una función de salida para que el desarrollador de la aplicación elimine su propia aplicación, es un diseño muy malo.

Mi aplicación debe permitir que el usuario cambie dinámicamente los datos de forma dinámica durante el tiempo de ejecución y el usuario debe reiniciar mi aplicación para que el cambio tenga efecto, pero Android no permitió que la aplicación se reiniciara por sí sola. El sistema operativo Android tiene un muy mal ciclo de vida de la aplicación de diseño.

Ted, lo que estás tratando de lograr se puede hacer, tal vez no cómo lo estás pensando ahora.

Le sugiero que lea sobre Actividades y Servicios. Deje de usar el término "aplicación" y comience a referirse a los componentes, es decir, Actividad, Servicio. Creo que solo necesitas aprender más sobre la plataforma Android; es un cambio de mentalidad desde una aplicación de PC estándar. El hecho de que ninguna de sus publicaciones haya tenido la palabra "Actividad" (excepto una cita de Preguntas frecuentes, es decir, no sus palabras) me dice que necesita leer un poco más.

Al parecer, ha encontrado la respuesta que desea en el comando finish (). Esto no eliminará su aplicación de la memoria, pero Android lo hará cuando necesite los recursos, por lo que no hace ninguna diferencia que no lo hará explícitamente.

Solo agregaría que para lograr el efecto completo que normalmente tendría una salida de aplicación, desearía restablecer el estado de la aplicación a cualquier estado que sea normalmente en el momento en que se ejecuta por primera vez después de un arranque del dispositivo, justo antes Para llamar al final () en todas tus actividades. De esa manera, si el usuario selecciona su aplicación nuevamente, parecerá que se ejecutó "fresco", sin dejar ningún estado desde el punto anterior a la "salida" simulada.

Si hay algunas acciones especiales que solo deberían ocurrir en "salir", como guardar el trabajo del usuario o lo que sea, también puede realizarlas antes de la parte de reinicialización de la rutina anterior.

Este enfoque le permite lograr su objetivo de tener un comando de "salida" sin violar la filosofía de Android de dejar la administración de los recursos del sistema operativo, incluido el cierre de aplicaciones, en manos del sistema operativo.

Personalmente, no usaría este enfoque, porque los usuarios de Android esperan que una aplicación conserve su continuidad cuando la revisen, por lo que no están acostumbrados a la modalidad de "salir" de una aplicación. En su lugar, admitiría una función "clara" que un usuario puede invocar para restablecer la aplicación a algún estado inicial predeterminado, sin la necesidad de "dejarla" en el proceso.

La única excepción sería cuando el usuario haya presionado el botón Atrás una cantidad suficiente de veces para hacer que la aplicación se cierre. En esa situación, no hay ninguna expectativa por parte del usuario de que ese estado se haya guardado (y si hay un estado no guardado en la aplicación, entonces usted, como desarrollador, debe tener un código que maneje el botón Atrás que detecta esos datos no guardados, y solicita al usuario que lo guarde en SharedPreferences o en un archivo, o en algún otro medio no volátil).

Respecto a system.exit (0):

Si decide usar system.exit (0) para cerrar su aplicación con una finalidad grosera (p. Ej., Como resultado de presionar un botón de retroceso final), le advierto que aunque para mí esto "funciona", y en algunos Los casos han sido la única forma en que he podido cerrar una aplicación sin dejar rastro de ella, hay un pequeño problema que se produce en Jelly Bean cuando utiliza este enfoque.

Específicamente, si usa la lista de aplicaciones recientes para abrir su aplicación, y luego usa el botón de retroceso para cerrar la aplicación (con ese cierre implementado a través de system.exit (0)), la lista de aplicaciones recientes se volverá a ver, como lo hará Nunca se han cerrado. Si luego toca la entrada de su aplicación en esa lista para ejecutarla por segunda vez desde la misma lista de aplicaciones recientes, que ya está abierta, no habrá respuesta.

Sospecho que la causa de esto es que la lista de aplicaciones recientes mantiene una referencia a su aplicación que se ha vuelto no funcional debido a que cerró la aplicación usando system.exit (0). Un cierre más civilizado de su aplicación utilizando finish () podría haber informado al sistema operativo de una manera que le hubiera permitido actualizar su lista de aplicaciones recientes, pero aparentemente system.exit (0) no lo hace.

Esto no es un gran problema en sí mismo, ya que muy pocas personas abrirán una aplicación desde Aplicaciones recientes, luego la cerrarán y la abrirán de nuevo desde la misma lista abierta de Aplicaciones recientes. Y si tocan el botón de inicio y luego vuelven a abrir la lista de Aplicaciones recientes, la entrada de su aplicación estará allí, y será completamente funcional. Pero creo que muestra que el uso de system.exit (0) puede interferir con la comunicación adecuada entre su aplicación y el sistema operativo, y esto sugiere que puede haber otras consecuencias más serias, posiblemente sutiles, de usar este enfoque.

Casi el 99% de las veces no es necesario que una aplicación de Android se haga cargo de su propio ciclo de vida. La mayoría de las veces se reduce a una mejor planificación o un diseño más inteligente de la aplicación. Por ejemplo, en lugar de crear un servicio interno (no exportado) para manejar descargas, etc., o diseñar acciones y tareas en torno al flujo de trabajo del usuario.

Pero dicho esto, donde hay una voluntad hay un camino. Android proporciona, a través de la clase android.os.Process, una API mucho mejor que Java para controlar el proceso subyacente. Y a diferencia de Java, no trata al desarrollador como un imbécil escondiéndolo todo detrás de una simple llamada java.lang.System.exit ().

Entonces, ¿cómo le pides a tu aplicación que se suicide en Android? Bueno, el truco es simple:

Cree su propia clase de aplicación de Android heredando de la clase de aplicación android.app.application (recuerde declararla en el archivo AndroidManifest.xml).

Reemplace el método onCreate () y almacene el ID de proceso que inició su aplicación:

this.pid = android.os.Process.myPid(); // Save for later use.

Ahora para matar tu aplicación, proporciona un método kill ():

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Ahora, cuando necesite que su aplicación se suicide, simplemente escriba el contexto de la aplicación y llame a su método de eliminación.

((MySuicidalApp) context.getApplicationContext()).kill()

Solo recuerde que debido a las políticas de administración de procesos en Android, específicamente relacionadas con los servicios, Android puede optar por reiniciar su servicio (consulte No debe usar asesinos de tareas en Android ).

Como una aplicación en un contexto de Android es solo un conjunto de actividades vagamente relacionadas, abandonar una aplicación realmente no tiene mucho sentido. Puede finalizar () una actividad y se dibujará la vista de la actividad anterior en la pila de actividades.

Consideraría leer "Desarrollo de aplicaciones inalámbricas para Android" publicado por Addison-Wesley. Solo lo estoy terminando y es MUY concienzudo.

Parece que tienes algunos malentendidos fundamentales de la plataforma Android. Yo también estaba un poco frustrado al principio con el ciclo de vida de las aplicaciones de las aplicaciones de Android, pero después de llegar a un mayor entendimiento, he llegado a disfrutar realmente de este enfoque. Este libro responderá todas sus preguntas y mucho más. Realmente es el mejor recurso que he encontrado para los nuevos desarrolladores de Android.

Además, creo que debe dejar de lado un puerto línea por línea de la aplicación existente. Para poder portar su aplicación a la plataforma Android, parte del diseño de la aplicación va a cambiar. El ciclo de vida de la aplicación utilizado es necesario, ya que los dispositivos móviles tienen recursos muy limitados en relación con los sistemas de escritorio y permiten que los dispositivos Android ejecuten varias aplicaciones de manera ordenada y con recursos. Estudie más a fondo la plataforma y creo que se dará cuenta de que lo que desea hacer es completamente factible. La mejor de las suertes.

Por cierto, no estoy afiliado a Addison-Wesley ni a ninguna persona u organización asociada con este libro. Después de releer mi publicación siento que me salí un poco fanático. Realmente lo disfruté y lo encontré extremadamente útil. :)

Creo que el punto es que no hay necesidad de salir de la aplicación a menos que tenga un software con errores. Android cierra la aplicación cuando el usuario no la está utilizando y el dispositivo necesita más memoria. Si tiene una aplicación que necesita ejecutar un servicio en segundo plano, es probable que desee una forma de desactivar el servicio.

Por ejemplo, Google Listen continúa reproduciendo podcast cuando la aplicación no está visible. Pero siempre está el botón de pausa para apagar el podcast cuando el usuario termina con él. Si recuerdo correctamente, escucha, incluso coloca un acceso directo en la barra de notificaciones para que siempre puedas acceder rápidamente al botón de pausa. Otro ejemplo es una aplicación como una aplicación de twitter, por ejemplo, que sondea constantemente un servicio en Internet. Estos tipos de aplicaciones realmente deberían permitir al usuario elegir con qué frecuencia sondear el servidor, o incluso si sondear en un hilo de fondo.

Si necesita tener un código que se ejecute al salir, puede anular onPause (), onStop () o onDestroy () según corresponda. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

El kernel de Linux tiene una función llamada " Out-of-memory killer" (como se mencionó anteriormente, las políticas son configurables en el nivel del espacio de usuario, y el kernel no es óptimo, pero de ninguna manera es innecesario).

Y es muy utilizado por Android:

OOM killer no es para espacio de usuario
Notas de Android (OOM Killer Info: donde puede configurar la función OOM en Android)
Portabilidad de Android en Real Target

Algunas aplicaciones de espacio de usuario están disponibles para ayudar con estas aplicaciones de eliminación, por ejemplo:

Autokiller / Configurando el destructor de tareas interno de Android

Espero que las cosas cambien con el tiempo. El usuario debe poder detener una aplicación o un proceso si el proceso de la aplicación está correctamente aislado en el espacio aislado. Existe la idea de que las aplicaciones deben escribirse perfectamente o el usuario usará solo las aplicaciones que siguen todas las recomendaciones de SDK. Creo que es una tarea difícil.

Estoy de acuerdo con Ted. Entiendo que salir de la aplicación no es la "forma de Android", pero no parece que deba excluirse. Aquí hay tres razones por las que podría querer una salida real a la aplicación (no solo la actividad):

El usuario puede querer cierto control sobre qué aplicación se elimina en el caso de poca memoria. Si la aplicación importante A se está ejecutando en segundo plano, es posible que desee salir de la aplicación B cuando haya terminado con ella para que el sistema operativo no anule la aplicación A.
Si su aplicación tiene datos confidenciales almacenados en la memoria caché, es posible que desee eliminarla para que una aplicación de virus / gusano / pícaro no pueda acceder a ella. Sé que el modelo de seguridad debe evitar eso, pero por si acaso ...
Si su aplicación utiliza recursos (como red, CPU, sensores, etc.) que podrían afectar negativamente al teléfono, entonces una forma de asegurarse de que esos recursos se liberen es salir de la aplicación. Entiendo que las aplicaciones de buen comportamiento deberían liberar recursos cuando no son necesarios. Pero nuevamente, salir de la aplicación parece ser una forma razonable de asegurar eso.

Hay un diseño (relativamente) simple que le permitirá sortear el enigma de "salida". Haga que su aplicación tenga un estado "base" (actividad) que es solo una pantalla en blanco. En el primer onCreate de la actividad, puede iniciar otra actividad en la que se encuentre la funcionalidad principal de su aplicación. La "salida" se puede realizar al finalizar () esta segunda actividad y volver a la base de una pantalla en blanco. El sistema operativo puede mantener esta pantalla en blanco en la memoria todo el tiempo que quiera ...

En esencia, debido a que no puede salir al sistema operativo, simplemente se transforma en una nada creada por uno mismo.

Para cerrar una aplicación en cualquier punto, use la FLAG_ACTIVITY_CLEAR_TOPbandera en Intención y luegosystem.exit();

O hay una forma similar, pero sin system.exit()cuando quieres salir, llama a este método:

public void exit() { startActivity(new Intent(this, HomeActivity.class). setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true)); }

En su HomeActivity.onCreate()código siguiente de añadir

protected void onCreate(Bundle savedInstanceState) { if (getIntent().getBooleanExtra(EXIT_FLAG, false)) { if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) { finish(); } } ......................

Esto funcionará sin romper el ciclo de vida de Android.

Publicación en el blog Cuándo incluir un botón de salida en las aplicaciones de Android (Sugerencia: nunca) lo explica mucho, mucho mejor que yo. Deseo que todos los desarrolladores de Android ya lo hayan leído.

Extractos:

En mi experiencia, lo que [los usuarios] realmente quieren es: una forma inequívoca de garantizar que una aplicación deje de consumir recursos (batería, ciclos de CPU, transferencia de datos, etc.).
Muchos usuarios perciben que un botón de salida implementa este requisito y solicitan que se agregue. Los desarrolladores, que buscan complacer a sus usuarios, agregan uno. Poco después, ambos fallan.
En la mayoría de los casos, el botón de salida simplemente llama Activity.finish(). Esto es exactamente equivalente a pulsar el botón Atrás. Exactamente.Los servicios siguen funcionando y las encuestas siguen sucediendo. Los usuarios pueden pensar que han matado la aplicación pero no lo han hecho, y pronto estarán aún más molestos.
El comportamiento de salida ahora es ambiguo. ¿Debería su botón de salida simplemente cerrar la Actividad, o también debería detener todos los Servicios, Receptores y Alarmas asociados? ¿Qué debería Backhacer? ¿Qué pasa si golpean en su Homelugar? ¿Qué pasa si tu aplicación tiene un widget? ¿Debería el botón de salida evitar que se actualice también?
La solución es hacer que el botón Atrás se comporte como esperaría que lo haga el botón Salir. Mejor aún, simplemente deje de consumir recursos cuando la aplicación no esté visible.

Anímate y lee el artículo completo.