¿Salir de una aplicación está mal visto?

1153

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

Pregunta: ¿El usuario tiene la opción de eliminar la aplicación a menos que agreguemos una opción de menú para eliminarla? Si no existe tal opción, ¿cómo termina el usuario la aplicación?

Respuesta: (Romain Guy): El usuario no lo hace, 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 un botón de "salir" o "salir" de la aplicación. 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 salir de la aplicación cuando decida hacerlo. Eso no es algo que deba confiarse en el sistema operativo.

La aplicación que estoy tratando de crear no es una aplicación para Android Market. No es una aplicación de "uso amplio" para el público en general, es una aplicación de negocios que se va a usar en un campo de negocios muy estrecho.

Realmente tenía muchas ganas de desarrollar para la plataforma Android, ya que aborda muchos problemas que existen en Windows Mobile y .NET. Sin embargo, la última semana ha sido un poco desagradable 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?

Ted
fuente

Respuestas:

1286

Esto eventualmente responderá 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, sino que 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 va a cerrar mi aplicación. esa debe ser la elección del usuario.

Millones de personas están perfectamente contentas 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 de iPhone no necesariamente se "siente" que la aplicación se cerró, ya que muchas aplicaciones de iPhone continúan donde el usuario la dejó, incluso si la aplicación realmente se cerró (ya que solo el iPhone permite una aplicación de terceros a la vez, en la actualidad).

Como dije anteriormente, hay muchas cosas que suceden en mi aplicación (datos que se EMPUJAN al dispositivo, listas con tareas que siempre deberían estar allí, etc.).

No sé qué significa "listas con tareas que siempre deberían estar allí", pero los "datos que se EMPUJAN en el dispositivo" son una ficción agradable y no deben ser realizados por una actividad en ningún caso. Use una tarea programada (vía AlarmManager) para actualizar sus datos para una confiabilidad máxima.

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

Hay muchas aplicaciones para iPhone y Android que se ocupan de esto. Por lo general, se debe a que conservan las credenciales de inicio de sesión, en lugar de obligar a los usuarios a iniciar sesión cada vez de forma manual.

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

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

Algunos comentarios sugieren que presionar el botón Atrás no mata la aplicación (ver el enlace en mi pregunta anterior).

Al presionar el botón ATRÁS no se "mata la aplicación". Termina 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 ninguna otra manera. Si no puede escribir aplicaciones que se comporten así en Android, entonces creo que Android no se puede usar 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 ellos, 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 acto de abandonar implica una finalizació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 BACK) o su código (a través de finish()) pueden cerrar su actividad actualmente en ejecución. Los usuarios generalmente no necesitan nada más, para aplicaciones correctamente escritas, más de lo que necesitan una opción de "cerrar" para usar aplicaciones web.


No hay dos entornos de aplicación iguales, por definición. Esto significa que puede ver las tendencias en los 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 los archivos. Las aplicaciones de iPhone generalmente 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í.

Del mismo modo, hay un movimiento creciente para tratar de eliminar la noción de "finalizar" 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 más énfasis en el diseño de la aplicación, enfocándose en los objetivos comerciales 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 sentirán frustrados con los entornos más nuevos que rompen su modelo mental existente. Esto no es culpa de ninguno de los entornos, como tampoco es culpa de una montaña por las tormentas que fluyen a su alrededor en lugar de atravesarla.

Por ejemplo, algunos entornos de desarrollo, como Hypercard y Smalltalk, tenían la aplicación y las herramientas de desarrollo combinadas en una sola configuración. Este concepto no cogió mucho, fuera de las extensiones de lenguaje para aplicaciones (por ejemplo, VBA en Excel , Lisp en AutoCAD ). Los desarrolladores que idearon modelos mentales que suponían la existencia de herramientas de desarrollo en la propia aplicación, por lo tanto, tuvieron que cambiar su modelo o limitarse a entornos donde su modelo fuera válido.

Entonces, cuando escribes:

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

Eso parecería ser lo mejor, para ti, por ahora. Del mismo modo, le aconsejarí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 se encontrarán en las aplicaciones web (por ejemplo, sin "terminación"). O, por el contrario, algún día si haces puerto de su aplicación a la Web, es posible que el flujo de la aplicación web puede ser un mejor partido para Android, y se puede volver a un puerto de Android en ese momento.

CommonsWare
fuente
21
Un pensamiento que me llegó a la cabeza: si solo reescribiera toda la aplicación como un Servicio y tratara ese Servicio como la aplicación real, ¿tal vez eso funcionaría mejor? Entonces podría "tonificar" las Actividades (tal como Android las quiere) para presentar los datos contenidos en el Servicio. En ese caso, tal vez podría mantener el estado de inicio de sesión y otras cosas allí. Usando startForeground (int, Notification) casi puedo evitar que Android mate el Servicio ...?
Ted
66
"Tenga en cuenta que mis usuarios son profesionales, que usan el dispositivo con el único propósito de usar la aplicación que estoy tratando de portar a Android". En realidad, ha indicado lo contrario ("no se puede hacer eso cada vez que reciben una llamada telefónica" - una "llamada telefónica" no es su aplicación). Además, a menos que esté creando su propio dispositivo, no puede evitar que las personas instalen otras aplicaciones si así lo desean.
CommonsWare
25
@SomeCallMeTim: No, esa no es una razón válida para usar killProcess(). Es una razón válida para escribir un mejor código de iOS.
CommonsWare
24
@CommonsWare: Lo siento, pero esa es una respuesta trivial que no me sirve. Estoy transfiriendo el código que me pagan al puerto. ¿Debería pasar el doble de tiempo haciendo el puerto, reescribiendo su código, o hacerlo de una manera que reduzca los costos para mi empleador, permitiéndoles poner más juegos en Android antes? De todos modos, es una pregunta completamente académica: no quieren que haga cambios tan importantes en su motor, ya que no puedo probar los cambios en iOS. Y simplemente está mal: no hay nada "malo" en usar patrones Singleton para los objetos apropiados. Android es solo aplicaciones rotas WRT NDK.
SomeCallMeTim
10
@Ted para una reinicialización más confiable, tal vez podría minimizar la cantidad de estado que se almacena en la Actividad o el Servicio en sí. En su lugar, coloque la mayor parte del estado y el código en una clase separada que vuelva a crear "desde cero" cada vez que se inicie la Actividad o el Servicio.
Qwertie
290

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

System.exit()no mata su aplicación si tiene más de una actividad en la pila. Lo que realmente sucede es que el proceso se cierra y se reinicia inmediatamente 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 completamente indocumentado, que yo sepa.

La respuesta corta es, si desea salir de su aplicación, debe realizar un seguimiento de todas las actividades en su pila y finish()TODAS ellas cuando el usuario quiera salir (y no, no hay forma de iterar a través de la pila de Actividad , así que debes manejar todo esto tú mismo). Incluso esto en realidad no mata el proceso ni ninguna referencia pendiente 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 tenga actividades restantes en su pila, hay otro método que le facilita las cosas: Activity.moveTaskToBack(true)simplemente hará un fondo de su 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:

  1. En primer lugar, esto solo ocurre cuando su aplicación está en primer plano. Si está en segundo plano, el proceso terminará bien. Sin embargo, si está en primer plano, el sistema operativo supone que el usuario quiere 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)
  2. 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 está completamente separada y no fue escrita por usted. La actividad del navegador puede o no crearse en la misma tarea, dependiendo de sus atributos manifiestos.
  3. Asume que cada una de sus actividades es completamente autosuficiente y puede ser asesinada / restaurada en cualquier momento. (Más bien no me gusta esta suposición particular, ya que mi aplicación tiene muchas actividades que dependen de una gran cantidad de datos en caché, demasiado grandes para ser serializados de manera eficiente onSaveInstanceState, pero ¿qué va a hacer?) Para la mayoría de las aplicaciones de Android bien escritas, esto debería ser cierto, ya que nunca se sabe cuándo se va a eliminar su aplicación en segundo plano.
  4. El factor final no es tanto una suposición, sino más bien una limitación del sistema operativo: matar la aplicación explícitamente es lo mismo que la aplicación se bloquea, y también lo mismo que Android que mata la aplicación para recuperar memoria. Esto culmina con nuestro golpe de gracia: dado que Android no puede saber si la aplicación se cerró o se bloqueó o se eliminó en segundo plano, se supone que el usuario desea volver a donde la dejó, por lo que ActivityManager reinicia el proceso.

Cuando lo piensas, esto es apropiado para la plataforma. Primero, esto es exactamente lo que sucede cuando el proceso se detiene 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. Lanzo 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 ser creada en su propia tarea). Si la cámara tiene un error y se bloquea, ¿eso debería provocar el bloqueo de toda la aplicación? Desde el punto de vista del usuario, solo la Cámara falló, y deberían volver a su actividad anterior. Por lo tanto, simplemente reinicia el proceso con las mismas actividades en la pila, menos la cámara. Dado que sus Actividades deben diseñarse de modo que puedan ser asesinadas y restauradas 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 esun problema para muchos de nosotros, no importa lo que Romain Guy o alguien más les diga. Entonces, necesitamos usar soluciones alternativas.

Entonces, mi consejo final:

  • No intentes matar el proceso. Llama finish()a todas las actividades o llama moveTaskToBack(true).
  • Si su proceso se bloquea o se mata, y si, como yo, necesita los datos que estaban en la memoria que ahora se pierde, deberá volver a la actividad raíz. Para hacer esto, debe llamar startActivity()con una intención que contenga la Intent.FLAG_ACTIVITY_CLEAR_TOPbandera.
  • Si desea eliminar su aplicación desde la perspectiva Eclipse DDMS, es mejor que no esté en primer plano, o se reiniciará por sí misma. Primero debe presionar el botón Inicio y luego finalizar el proceso.
Neil Traft
fuente
8
En realidad, desde que comencé con Android nuevamente, estoy terminando todas las actividades (solo una actividad está activa en cualquier momento), y luego llamo a System.exit (0); en mi servicio, y eso funciona tal como yo lo quiero también. Sé que la mayoría de las personas dicen "no hagas eso", pero obtengo exactamente el comportamiento que quiero con ese movimiento ...
Ted
13
Eliminar el proceso es muy útil a veces, por ejemplo al escribir juegos que usan código nativo. Matar el proceso significa liberar toda la memoria asignada al sistema, de inmediato.
Sulthan
10
Para cualquiera que le importe, Process.killProcess demuestra exactamente el mismo comportamiento que System.exit ()
PacificSky
66
Derive todas las actividades de un AtivityBase común. Luego mantenga presionada una bandera para forzar el cierre de la aplicación, en onResume verifique si la bandera de forzar cierre está activada. Si es así, llame a System.exit (0); Esto pasará por toda la pila de actividades y finalmente la aplicación se cerrará por completo.
Nar Gar
12
Gracias por proporcionar respuestas reales ( moveTaskToBack()era lo que estaba buscando). Mucha gente simplemente dice "No, eres un idiota por querer salir de tu aplicación". sin siquiera considerar que puede haber casos en los que lo desee (por ejemplo, inicios de sesión fallidos).
Timmmm
180

Todas mis aplicaciones tienen botones para salir ... y con frecuencia recibo comentarios positivos de los usuarios debido a ello. No me importa si la plataforma se diseñó de manera tal que las aplicaciones no las necesiten. Decir "no los pongas allí" es algo ridículo. Si el usuario quiere salir ... Les proporciono el acceso para hacer exactamente eso. No creo que reduzca la forma en que Android funciona 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 al manejarlo ... y eso es un hecho básico.

androidworkz
fuente
15
+1 porque desafortunadamente no hace un buen trabajo en este momento (pero todavía quiero intentar hacer las cosas según lo diseñado, por lo que me pone en apuros)
Richard Le Mesurier
25
¿Qué mecanismo utilizas para dejar de fumar?
Gary Rudolph
44
@Igor finish (): las actividades no eliminan la aplicación (extiende la aplicación). Entonces, incluso cuando ninguna de las actividades estaba activa, la configuración sigue siendo activa y real, de modo que cuando las actividades intenten acceder a ellas, serán las que se usaron antes. System.exit (0); por otro lado, mata la aplicación, de modo que cuando se inicia nuevamente, la aplicación tendrá que inicializar la configuración de nuevo. Eso es lo que necesito al actualizar mi aplicación manualmente, porque con frecuencia cambio el formato de los datos y necesito que se reinicien de inmediato.
Nar Gar
1
Bueno, esa es la única forma de lograr lo que necesito en este momento. Uso system.exit cuando se actualiza la aplicación (de lo contrario, obtendré excepciones de serialización o de conversión de clases basadas en los cambios de mi código). Sin embargo, debo mencionar que no le doy al usuario un identificador de interfaz de usuario para matar la aplicación a través de system.exit: está reservado para mí como ingeniero de la aplicación que se utilizará solo cuando la aplicación necesite descargarse por completo. El resto del tiempo se usa un acabado simple () (o la operación predeterminada del botón Atrás).
Nar Gar
13
Sí ... al diablo con 'no estándar de Android' ... Android es poderoso porque permite a las personas experimentar ... Si proporciona API para hacer algo, ¿cómo se puede decir que no es estándar de Android? No puedo digerir todas esas respuestas 'filosóficas'. Haces que la aplicación tenga en cuenta a tus usuarios. si están contentos o si quieren ver esta característica, entonces está absolutamente bien implementar eso, incluso si los llamados filósofos están en contra de ella ...
Rahul
144

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

No saber qué "hace" su misteriosa aplicación no es realmente importante. Supongamos que hace un túnel en una intranet corporativa súper segura, realiza un poco de monitoreo o interacción y permanece conectado hasta que el usuario "salga de la aplicación". Debido a que su departamento de TI lo ordena, los usuarios deben ser muy conscientes de cuándo están dentro o fuera de la intranet. De ahí su mentalidad de que es importante que los usuarios "abandonen".

Esto es simple. Realice un servicio que coloque una notificación continua en la barra de notificaciones diciendo "Estoy en la intranet o estoy corriendo". Haga que ese servicio realice todas las funciones que necesita para su aplicación. Tenga actividades que se unan a ese servicio para permitir a sus usuarios acceder a los bits de la interfaz de usuario que necesitan para interactuar con su "aplicación". Y tenga un botón de Menú de Android -> Salir (o cerrar sesión, o lo que sea) que le indica al servicio que cierre, luego cierra la actividad en sí.

Esto es, para todos los efectos exactamente lo que dices que quieres. Hecho a la manera de Android. Mire Google Talk o Google Maps Navigation para ver ejemplos de esta mentalidad de "salida". La única diferencia es que presionar el botón de retroceso de su actividad puede dejar su proceso UNIX al acecho en caso de que el usuario quiera revivir su aplicación. Esto no es realmente diferente de un sistema operativo moderno que almacena en caché los archivos a los que se accedió recientemente en la memoria. Después de salir de su programa de Windows, los recursos más probables que necesitaba todavía 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.

Eric
fuente
3
@Eric, no ves el problema porque estás huyendo de él. Simplemente utilizó otro programa que se ejecuta en el antiguo "modelo de programa" para hacer lo que no puede hacer el "modelo de Android". Para ver el problema con el "modelo de Android", debe imaginar que no puede darse el lujo de delegar tareas en cuadros de Linux / Windows. Tiene que imaginar que se ve obligado a hacer todo, desde el frontmostend hasta el backmostend con solo cajas que ejecutan el "modelo de Android". Luego, verá que las limitaciones del "modelo de Android" son tan claras como el cielo.
Pacerier
Piense en su aplicación como una aplicación monolítica. Está escrito en Java, que se ejecuta mediante un solo proceso JVM (Java Virtual Machine). System.exit () sale de la JVM y termina completamente y por completo todas las pantallas de la interfaz de usuario y todo. La excepción a esto es SI el programador se toma la molestia de configurar múltiples subprocesos que se ejecutan en múltiples procesos, pero de forma predeterminada, ese NO es el caso, y según Google, no debería hacerse normalmente.
Jesse Gordon
@JesseGordon Esto simplemente no es cierto. System.exit()solo elimina una actividad de la pila. La JVM se reinicia de inmediato. Mira esta respuesta .
forresthopkinsa
1
@forresthopkinsa OK Lo he probado en Android 7.0. Una aplicación simple de un solo subproceso todavía se ejecuta en su propia instancia JVM dedicada, ejecutándose como un ID de usuario único para esa aplicación. Todavía no probé una aplicación multiproceso para esta prueba. Y System.exit () TODAVÍA mata toda la JVM para esa aplicación. Si se llama a System.exit () desde la actividad primaria, simplemente se cierra. Si se llama a System.exit () desde una subactividad, la JVM aún se elimina, pero Android lo reinicia con una nueva ID de proceso en la actividad principal / primera. android.os.Process.killProcess (android.os.Process.myPid ()); y kill <pid> funciona de la misma manera.
Jesse Gordon
1
Interesante ... Mirando la respuesta que vinculó, @forresthopkinsa, parece que Android está haciendo como los navegadores web, restaurando las actividades después de un sistema. Salir para que el usuario no note que salió, pero excluye la actividad que causó la salida. .? Extraño. Pero de todos modos, System.exit () hace cerca de todas las actividades y free () 's la memoria y termina la JVM para esa aplicación. Pero no tengo idea de qué tipo de travesuras hace Android para reiniciarlo / restaurarlo. ¿Es para frustrar las aplicaciones asesinas de aplicaciones? Así que supongo que si alguien quiere un botón de salida, debe ponerlo en la actividad principal.
Jesse Gordon
71

Esta es una discusión interesante y perspicaz con tantos expertos que contribuyen. Siento que esta publicación debe ser devuelta desde el sitio web principal de desarrollo de Android, porque gira en torno a uno de los diseños principales del sistema operativo Android.

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

Hasta ahora, 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.

Habiendo dicho eso, todavía creo que debería haber un Quitbotón. ¿Por qué? ... no para mí o Ted o cualquiera de los gurús de la tecnología aquí, sino con el único propósito de satisfacer la demanda de un usuario final.

Aunque no soy un gran admirador de Windows, hace mucho tiempo que 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 'Quiero'".

Eso no significa que alguien (¿SO, 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 'finalizar una llamada al presionar un botón', 'apagar el dispositivo presionando un botón', y así sucesivamente ... es una percepción. Trae una satisfacción per se de que mi acción efectivamente logre su propósito.

A pesar de que un desarrollador puede burlar este comportamiento utilizando las sugerencias dadas aquí, la percepción aún permanece, es decir, una aplicación debería dejar de funcionar por completo (ahora), por una fuente (SO) independiente, confiable y neutral a pedido del usuario final.

Paul
fuente
2
Derecha. El buen Windows Mobile ofreció el mismo botón X que las PC con Windows, excepto que en realidad no cerró la aplicación, simplemente la "minimizó de manera inteligente". Muchos usuarios probablemente nunca descubrieron que la aplicación realmente no se cerró. (El enfoque funcionó muy bien, aunque si usó .NET Compact Framework, la aplicación no fue notificada de que esto había sucedido y, por lo tanto, no tenía la opción de liberar recursos o realmente dejar de fumar)
Qwertie
3
Realmente, esto equivale a mentir a tus usuarios para darles una sensación cálida y difusa. En última instancia, es mejor dejar que las reliquias del pasado se desvanezcan, para que no sigan siendo elementos permanentes de la tecnología. Los dispositivos móviles y la web son plataformas nuevas y no se espera que se comporten de la misma manera que los equipos de escritorio. Y anecdóticamente, al menos, las decisiones del ciclo de vida de Android parecen estar alcanzando a los usuarios: a medida que mi aplicación más grande pasa su segundo aniversario, he notado que el flujo de solicitudes de los usuarios finales de botones de "salida" se está agotando a medida que se acostumbran a nueva plataforma
Jon O
2
@ Jon ¿Qué me recomiendan? ¿No ofrece una opción de 'salida' en ninguna parte de la aplicación?
IgorGanapolsky
Bueno, cuando un usuario solicitaba un botón de salida, les explicaba exactamente cómo funcionaban las cosas de manera diferente que en un escritorio (que es la misma explicación que les doy cuando mencionan asesinos de tareas). Ahora, la información parece haberse puesto al día, y ya no recibo esas solicitudes. Por lo tanto, le recomiendo que lo explique varias veces (tal vez presente una respuesta enlatada) y deje de lado el botón. O coloque un botón de salida falso que muestre un cuadro de diálogo que explique por qué no hay más botones de salida. : D (también en Android 4+ un usuario puede deslizar una aplicación "fuera" de la pantalla multitarea para "matarla").
Jon O
3
Tampoco he encontrado el razonamiento detrás de todos los consejos que dicen "no matar el proceso". En mi opinión, el cliente siempre tiene razón, entonces, ¿qué hay de malo en proporcionar un botón de salida después de haberlo solicitado y "mentir a sus usuarios para darles una sensación cálida y difusa", si eso es lo que quieren? Esto es en parte de lo que se trata escribir buenas aplicaciones. La mayoría de los usuarios no saben ni les importa lo que realmente sucede debajo del capó, pero si les gusta su aplicación y hace lo que quieren y esperan, volverán y comprarán más de sus aplicaciones. Eso es lo que todos queremos, ¿no? ¿O me estoy perdiendo algo?
DDSports
37

Usted puede dejar de fumar, o bien pulsando el Backbotón o llamando finish()en su Activity. Solo llama finish()desde unMenuItem si desea eliminarlo explícitamente.

Romain no dice que no se puede hacer, solo que no tiene sentido: los usuarios no necesitan 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 guarde y guarde automáticamente restaura su estado pase lo que pase.

Christopher Orr
fuente
55
No tiene sentido si cumple un propósito, y en nuestra aplicación hace exactamente eso. Por ejemplo, queremos verificar las actualizaciones al salir de la aplicación. No podemos salir de la aplicación, entonces no se puede realizar ninguna actualización. Algunos comentarios sugieren que presionar el botón Atrás no mata la aplicación en absoluto (ver el enlace en mi pregunta anterior).
Ted
2
Como dice Romain, no es así como funcionan las aplicaciones principales. Entonces, si los usuarios están acostumbrados a presionar "Atrás" para salir de una aplicación, entonces parece probable que continúen haciéndolo con su aplicación en lugar de elegir explícitamente ¿Salir? Puede hacer una verificación de actualización al inicio, o en Destroy (), o usando una alarma que se repite ... no parece ser algo que deba ser activado por un usuario.
Christopher Orr el
1
Tom: Llevo casi 5 años codificando para Windows Mobile. Eso es un teléfono con "recursos limitados". No existe tal comportamiento allí, y tampoco hay problemas que tampoco actúen en esa forma de "hermano mayor". "Aplicaciones reales" = donde el programador tiene mucho más control sobre él, es decir, dejar de fumar, cuando se elimina la GUI, etc ...
Ted
1
Jay: porque si todavía está en la memoria, no puedo actualizar la aplicación, estoy pensando. No puedo eliminar archivos que están en uso, ¿verdad? Quiero actualizar al salir porque no podemos obligar a nuestros usuarios a actualizar al inicio. Eso tiene que ver con cómo funcionan y qué necesitan. No está bien que se vean obligados a una actualización al comienzo de su turno por diferentes razones. Es un poco complicado.
Ted
1
Jay: No, como dije anteriormente, NO es una aplicación de mercado, y tampoco será eso. Es una aplicación muy especializada, no para uso general.
Ted
31

Este debate se reduce a la antigua pregunta de si los desarrolladores saben mejor o si el usuario sabe mejor. Los 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 extra cuando dejan las aplicaciones. Están acostumbrados 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, 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 sabe mejor 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. Por eso, concluyo que tener una opción de '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.

Peter Mortensen
fuente
8
Sí, tener un botón 'Salir' es realmente fácil de usar. ¿De qué otra forma el usuario saldría de la aplicación si tiene 5 actividades en profundidad? Claro que pueden presionar varias veces, pero no creo que les guste eso.
IgorGanapolsky
44
¿Solo 5? El navegador web Android 2.2 me hace pasar unos minutos tocando el botón Atrás hasta que finalmente salgo
Joe Plante
3
Comenzaría a escuchar a los desarrolladores de Android cuando desarrollen el administrador de memoria que FUNCIONA. A partir de Froyo, funcionó extremadamente mal, eliminando aplicaciones aleatorias, reiniciando aplicaciones que no necesitan ser (y no tienen Intentos para iniciarlas legítimamente), y OTOH, disminuyendo a un rastreo COMPLETO cuando la memoria alcanza los 50 MB libres.
DVK
10
Cuando su religión dice que Android Task Killer es "innecesario", pero el uso de ATK para eliminar las tareas tontas que no tienen que ejecutarse hace que el sistema operativo se arrastre a ~ 1-5% de la velocidad normal de nuevo al 100% de la velocidad normal ( medido) 100% del tiempo en miles de usos de ATK durante 2 años cada vez que el sistema alcanza los 50 MB de gama baja libre, su religión está equivocada
DVK
@JoePlante Puedes cerrar todas las pestañas y ventanas abiertas primero y luego simplemente presionar el botón Atrás una vez para salir :) Al menos en mi GS2.
señora
29

Ted, lo que estás tratando de lograr se puede hacer, quizás no solo como 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 de una aplicación de PC estándar. El hecho de que ninguna de sus publicaciones haya tenido la palabra "Actividad" (menos una cita de preguntas frecuentes, es decir, no sus palabras) en ellas me dice que necesita leer más.

Peter Mortensen
fuente
He leído la mayoría de las cosas en android.com =) y puedo vincularme a varias de mis preguntas donde hablo de Actividades, por lo que no es cierto (por ejemplo: stackoverflow.com/questions/2032335/… o stackoverflow.com/questions/ 2032335 / ... etc ...) Sin embargo, podría darle una última oportunidad e intentar crear la "aplicación" who como Servce ...
Ted
44
Una aplicación puede contener servicios y actividades, y parece que su aplicación puede necesitar ambos. La actividad es solo la parte de la interfaz de usuario.
Aaron
23

Publicación de 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 manera 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 presionar 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 cerrar la Actividad, o también debería detener todos los Servicios, Receptores y Alarmas asociados? Que debe Backhacer ¿Qué pasa si golpean en su Homelugar? ¿Qué sucede 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 cabría esperar. Mejor aún, simplemente deje de consumir recursos cuando la aplicación no esté visible.

Continúa y lee el artículo completo.

Dheeraj VS
fuente
3
Salir y Atrás no siempre se usan para el mismo propósito. Tomemos, por ejemplo, Pandora. Cuando presionas para salir de esta aplicación, no sale de la aplicación (la mantiene en segundo plano como un servicio).
IgorGanapolsky
@IgorG. Una aplicación de reproductor de música necesita un botón "Parar" para dejar de reproducir música, no un botón "Salir" para salir de la aplicación.
Dheeraj Vepakomma
¿Alguna vez ha usado Pandora, iHeartRadio, Spotify, Jango y otras aplicaciones de transmisión de música? Todos tienen un botón para salir. Detener la reproducción de música NO ES LO MISMO que salir de una aplicación. Especialmente si tiene un servicio ejecutándose en la barra de notificaciones.
IgorGanapolsky
2
Míticos o no, usuarios primitivos o no, pero casi todos los programas de interfaz de usuario jamás escritos, en cualquier plataforma y sistema operativo, implementan un botón para salir / cerrar / salir. ¿De qué otra manera lo implementaría?
IgorGanapolsky
3
@ DheerajV.S., ¿Simplemente deja de consumir recursos cuando la aplicación no está visible? Mal consejo. Muy. Muy x99. Cada vez que intento enviarme una foto por correo electrónico, tengo que mantener la aplicación visible durante 5 minutos completos porque si la minimizo, deja de enviarla por correo electrónico. Correcto, no puedo usar mi teléfono durante 5 minutos completos solo porque un desarrollador cree que las aplicaciones deberían ejecutarse solo cuando estén visibles. Ahora imagine enviar un archivo más grande como video .....
Pacerier
21

Respuesta: (Romain Guy): El usuario no lo hace, 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 un botón de "salir" o "salir" de la aplicación. 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 por completo de una aplicación puede ser generalmente obligatorio, pero no es inútil. ¿Qué pasa si Windows no tiene la opción de salida? El sistema sería lento ya que la memoria estaba llena y el sistema operativo tenía que adivinar con 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 matar tareas para recuperar su memoria antes de que se pueda lanzar una nueva aplicación. ¡No puedes decirme que no lleva tiempo matar una aplicación! Incluso la luz de las estrellas distantes lleva tiempo ... Es útil permitir que el usuario cierre completamente las aplicaciones.

2: ¿Contrariamente 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 a que el sistema operativo la elimine cuando se necesite su memoria.

En resumen, existe una clara diferencia entre minimizar y salir, y ninguno de los dos pellizcos golpea bien al otro. ¿Dejamos un destornillador en cada tornillo? ¿O una llave en cada puerta? ¿Dejamos todos nuestros electrodomésticos en alto hasta que el interruptor explote y necesitemos encender otro electrodoméstico? ¿Dejamos el lavavajillas lleno de platos y solo sacamos suficiente cada vez para dejar espacio para algunos nuevos y sucios? ¿Dejamos todos los autos corriendo en el camino de entrada hasta ... oh, no importa.

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

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

Pero a fin de cuentas, 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 sirve para nada en absoluto, y ralentiza las cosas cuando se inician nuevas aplicaciones o cuando las aplicaciones se asignan más memoria.

Es algo así como su automóvil: hay momentos en que lo deja en funcionamiento, como detenerse en un semáforo, o tal vez la comida rápida conduce o detenerse en el cajero automático. Pero hay otras situaciones en las que desea apagarlo, como cuando llega al trabajo, a la tienda de comestibles o incluso a su casa.

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

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

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

Jesse Gordon
fuente
2
"Si el usuario quiere minimizar una aplicación, lo mejor es minimizarla. Si un usuario quiere salir de una aplicación, entonces, por supuesto, es mejor salir". - Hay una cosa (basada en más de esa década de experiencia): los usuarios rara vez saben lo que quieren. Si no los ayuda, tendrá que cambiarlo. Acerca de las muestras anteriores: déjame darte otra muestra: estás trabajando en un automóvil y tienes una mesa a mano para las cosas. ¿Siempre guarda para colocar correctamente todas las herramientas necesarias para el gabinete o tiene a mano las más usadas? ¿Y solo guardaste una grande usada tarde para tener lugar para otras nuevas?
HoGo
44
HoGo, gracias por tu comentario. Naturalmente, no estoy de acuerdo. Específicamente, lo mejor que puedo decir, su opinión es que, dado que algunos usuarios no saben lo que deben hacer, por lo tanto, no dejen que ningún usuario haga lo que debe hacer, ni siquiera los que saben lo que deben hacer. Si Android tenía una manera de saber con precisión si debería terminar una aplicación en lugar de minimizarla, entonces está bien. Pero no es así, y obligar a todos los usuarios a vivir siempre con la minimización cuando desean salir conduce a un bajo rendimiento del dispositivo.
Jesse Gordon
La cosa es que el sistema sabe que cuando inicias una aplicación y no hay memoria, debería matar a la última. El usuario no debería saber eso. Solo lo quieres porque eres un humano al que le gusta la sensación de tener el control, es solo una estúpida memoria muscular, incluso su control sin sentido tiene que cerrar programas. Las computadoras se inventaron para automatizar, me gustaría más que Windows funcione como Android y solo se cierre automáticamente para mí, pero tengo que recordar guardar y salir, eso es una tontería, ¿por qué debería hacerlo el usuario? las computadoras deben administrar su memoria, tengo otras cosas que administrar.
Luiz Felipe
En realidad no cierro programas en mi máquina Windows, tengo 32 GB de RAM, simplemente dejo todo en funcionamiento, los cierro cuando termino mi trabajo. Por qué cerrar el programa, abrirlo nuevamente 5 minutos después, esto no tiene sentido. Piense en un gran proyecto de C ++ que tarda 2 minutos en responder, simplemente dejo el Visual Studio abierto para siempre. Y espero que tampoco se bloquee después de 15 días de estar abierto (y sí, uso la memoria ECC para eso).
Luiz Felipe
La analogía con el taller de máquinas es buena, también dejo las herramientas más usadas encima de mi escritorio, no escojo la herramienta, la uso y la vuelvo a colocar cada vez. Además, no comienzo el día, enciendo la computadora, espero a que comience, abro IDE, lo que sea. Solo lo dejo en funcionamiento, la computadora moderna puede estar inactiva a 40w, ¿por qué cerrar? también usa menos componentes (sin corriente de entrada, EE lo sabe :))
Luiz Felipe
19

Creo que el punto es que no hay necesidad de salir de la aplicación a menos que tenga un software defectuoso. Android cierra la aplicación cuando el usuario no la está usando 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 podcasts cuando la aplicación no está visible. Pero siempre existe el botón de pausa para apagar el podcast cuando el usuario haya terminado con él. Si no recuerdo mal, Escucha, incluso pone un acceso directo en la barra de notificaciones para que siempre puedas acceder al botón de pausa rápidamente. Otro ejemplo es una aplicación como una aplicación de Twitter, por ejemplo, que sondea constantemente un servicio en Internet. Este tipo de aplicaciones realmente debería permitir al usuario elegir con qué frecuencia sondear el servidor, o incluso si sondear en un hilo de fondo.

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

Jay Askren
fuente
55
Junto con otras cosas desordenadas que descubrí, creo que desarrollar nuestra aplicación para Android no va a suceder. Es demasiado "hermano mayor", algo que está sucediendo, donde Android me dice qué aplicación debería ejecutarse o no. Yo como programador debería tener esa opción, no google o android = (
Ted
3
Sus actividades, la interfaz de usuario activa, desaparecen cuando aparece otra aplicación en la parte superior o cuando presiona hacia atrás o lo que sea. El usuario no interactúa con ellos, por lo que es más seguro guardar el estado en caso de que el usuario no regrese por mucho tiempo, y así sucesivamente, como usted sabe. No hay nada que le Serviceimpida escribir un pensamiento para mantener el trabajo en curso en segundo plano, como recibir actualizaciones de datos o lo que sea. Google Talk no deja de funcionar cuando usa una aplicación diferente. Lo mismo con el reproductor de música. Mira las otras aplicaciones y cómo funcionan.
Christopher Orr el
3
Debería poder guardar las credenciales para que los usuarios no necesiten iniciar sesión cada vez que reciben una llamada telefónica o se van de su aplicación. Recomendaría mirar el ciclo de vida de Android. Cuando la aplicación se detiene, se detiene o se destruye, puede guardar todos los datos relevantes para que cuando la aplicación se abra de nuevo, sea como la dejaron. El usuario ni siquiera necesita saber que la aplicación se detuvo alguna vez.
Jay Askren
1
Me imagino que un usuario puede querer abandonar algunas aplicaciones realmente intensivas en recursos. Tal vez debería reducir el uso de recursos cuando está en pausa, pero eso no siempre es posible
Casebash
1
Todavía veo estas preguntas vivas, 4 años después de que lo mencioné =) Realmente lo ejecuté como un servicio en segundo plano, pero agregué el botón para salir, ya que todavía siento, 4 años después, que es necesario e importante Y veo más y más aplicaciones que también tienen eso (Skype, por ejemplo).
Ted
19

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

Aquellos que descargan esos pequeños y divertidos App Killers generalmente encuentran que no ayudan con la duración de la batería o el uso de la memoria, sino que impiden 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

Dan
fuente
Mientras hablamos de asesinos de tareas, hace unos días apareció una publicación muy esclarecedora en el reddit de Android. Lo esencial es usar los asesinos de tareas con cuidado o podría terminar dañando la duración de la batería: reddit.com/r/Android/comments/cwhm6/…
Neil Traft
@Neil Traft, los comentarios en la publicación me parecieron muy esclarecedores. Los representantes de ventas en las tiendas recomiendan e instalan asesinos de tareas para sus clientes :)
dipu
3
@Dan, ¿cómo es posible que haya salido por completo de una aplicación con la que he terminado durante una semana para impedir el funcionamiento del sistema operativo Android? Entonces hay más memoria libre. ¡Eso no puede obstaculizar Android! ¡Sin embargo, podría acelerar las cosas más tarde! Si sé que he terminado con la aplicación por un tiempo, no sirve para nada. Solo ocupa memoria, y tarde o temprano, lanzaré una nueva aplicación y el sistema operativo tendrá un retraso adicional porque tiene que ir a matar algunas aplicaciones que conocí hace SEMANAS.
Jesse Gordon el
@Jesse Gordon, ¿Has visto los procesos reales después de matar una aplicación? Se reinician, el sistema operativo asume que hubo un problema ... El sistema operativo matará las aplicaciones cuando necesite memoria. ¿Leíste algo publicado en los artículos mencionados aquí?
Dan
@Dan, pensar que Android haría algo como esto ... realmente necesita una seria reeducación de blanqueamiento.
Pacerier
18

Consideraría leer "Desarrollo de aplicaciones inalámbricas de Android" publicado por Addison-Wesley. Estoy terminando y es MUY minucioso.

Parece que tienes algunos malentendidos fundamentales de la plataforma Android. Al principio, yo también estaba un poco frustrado con el ciclo de vida de las aplicaciones de Android, pero después de comprenderlo mejor, realmente he disfrutado 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 soltar un puerto línea por línea de la aplicación existente. Para 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 conocimiento de los recursos. Haga un estudio más profundo de la plataforma, y ​​creo que se dará cuenta de que lo que quiere 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 volver a leer mi publicación, siento que salí un poco fanboy. Realmente, realmente lo disfruté y lo encontré extremadamente útil. :)

Peter Mortensen
fuente
2
Gracias por el consejo del libro. Lo veré si puedo y si decido moverme en el puerto de Android. Sin embargo, solo para decirlo de nuevo: nuestros usuarios no están muy actualizados cuando se trata de computadoras. Seré muy difícil para ellos usar, por ejemplo, la barra de notificaciones en Android. Demasiado pequeño (tienen GRANDES dedos jeje). Es un mundo diferente para ellos, por lo que debemos mantenerlo simple y sin opciones para el usuario. Creamos nuestra solución .NET con eso en mente - no les dé una opción =)
Ted
Escuche eso. Debe suponer que la mayoría de los usuarios no son muy inteligentes en tecnología.
Andy
8
Me canso tanto del mantra de cuán pocos "recursos" tiene un dispositivo móvil. Despierta, están funcionando a más de 500Mhz y tiene mucha memoria. Mi viejo Dell Axim tenía 128 MB de RAM. ¡Los dispositivos actuales tienen más de 512RAM y funcionan a 1 GHz! Eso es 10 veces más que mi antiguo Pentium 90Mhz, y no escuché a la gente decir "los recursos muy limitados" esto y aquello. Es hora de despertarse y oler el café: ahora estamos en el 2010, no en los 80.
Ted
16

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

Pero dicho esto, donde hay 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 al ocultarlo 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 estándar android.app.Application (recuerde declararla en el archivo AndroidManifest.xml).

Anule 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 eliminar su aplicación, proporcione 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 matar.

((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 ).

Andries
fuente
sí, solo vine aquí porque quería cerrar mi aplicación en una situación que tiene sentido, mi caché de datos OBB está corrupta y necesito reiniciar toda la aplicación
Luiz Felipe
14

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

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

Para hacer eso, solo necesitas el Backbotón o elHome botón de su teléfono (ya sea presionando breve o prolongadamente) y la barra de notificaciones.

Cuando salgo de mi aplicación, solo uso el Backbotón hasta que me quede fuera de ella oHome botón.

Así es como se concibe 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 / 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 de "salida".

En las PC, tiene un escritorio multi-GUI, y en Android, obviamente tiene múltiples tareas, pero solo muestra una aplicación a la vez (no considero widgets aquí ^^). Y en un teléfono móvil, en cualquier momento, puede recibir una notificación por 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 aplicación - trabajo - salga de la aplicación".

Solostaran14
fuente
12

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:

  • ¿Las actividades de la aplicación guardan / restauran el estado como se recomienda en la documentación del ciclo de vida del desarrollador?

  • Si se necesita un inicio de sesión en la etapa de restauración (no hay información de inicio de sesión / sesión disponible), hágalo.

  • Finalmente, agregue un botón / menú / tiempo de espera, en cuyo caso lo hará finish()sin guardar el inicio de sesión y otra información de la sesión, lo que implícitamente es el final de la sesión de la aplicación: por lo tanto, si la aplicación se inicia / trae al frente nuevamente, comenzará una nueva sesión.

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

Si realmente desea eliminarlo de la memoria (esto se desaconseja, y por cierto ¿para qué?), Puede matarlo condicionalmente al final de onDestroy()with java.lang.System.exit(0)(¿o tal vez restartPackage(..)?). Por supuesto, hágalo solo en el caso en que desee "finalizar realmente la aplicación", porque onDestroy()es parte del ciclo de vida normal de las actividades y no una aplicación finaliza en absoluto.

Slig
fuente
11

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

Al sr
fuente
2
Salir de una aplicación seguramente puede tener sentido en algunas situaciones. Si es un programa que utiliza varias veces al mes durante unos minutos, existe un beneficio indudable al salir completamente de la aplicación. Ese beneficio es que el sistema operativo no tendrá que tomarse el tiempo para salir de esa aplicación una semana más tarde cuando se quede sin memoria y suene su teléfono y haya presionado el botón de respuesta, y esté esperando que Android libere algo de memoria para que pueda responder su llamada, por ejemplo. O tal vez recibió un correo electrónico y desea leerlo: cualquier aplicación que necesite más memoria se iniciará más rápido si el sistema operativo no lo libera primero.
Jesse Gordon el
3
Lo que dijo @JesseGordon, y otro aspecto de esta razón por la cual dejar de fumar tiene sentido: si no salgo de esta aplicación que consume muchos recursos, sé que no la volveré a usar durante un mes, el sistema operativo a veces mata erróneamente alguna otra aplicación cuando los recursos escasean, mientras se deja esta aplicación inútil de recursos en ejecución ... haciendo que la otra aplicación tarde más en reanudarse de lo que debería.
Don Hatch
10

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 es posible que desee una salida real a la aplicación (no solo la actividad):

  1. El usuario puede querer tener algún control sobre qué aplicación se mata 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 para que el sistema operativo no elimine la aplicación A.

  2. Si su aplicación tiene datos sensibles almacenados en la memoria caché, es posible que desee eliminar la aplicación para que una aplicación de virus / gusano / canalla no pueda acceder a ella. Sé que se supone que el modelo de seguridad evitará eso, pero por si acaso ...

  3. Si su aplicación utiliza recursos (como red, CPU, sensores, etc.) que podrían afectar negativamente al teléfono, entonces una forma de garantizar que esos recursos se liberen es salir de la aplicación. Entiendo que las aplicaciones con buen comportamiento deberían liberar recursos cuando no se necesitan. Pero, de nuevo, salir de la aplicación parece una forma razonable de garantizarlo.

Burke
fuente
66
¿Qué crees que representa la "aplicación"? Si abro la aplicación de Facebook y configuro una nueva foto de perfil, se inician las aplicaciones de mi cámara o galería. Como usuario, sigo realizando la misma tarea (usando Facebook). Si luego decido cerrar Facebook, mis aplicaciones de cámara y galería también deben cerrarse (ya que son actividades lanzadas desde Facebook) ... ¿Qué pasaría si estuviera en medio de la edición de algunas de mis otras fotos y solo tuviera la intención de cerrar Facebook? ? Hubiera cambiado el problema a una posible pérdida de datos.
seanhodges
Bueno, no creo que pueda llegar tan lejos como la pérdida de datos. Si tiene una actividad de terceros que se ejecuta en la misma tarea que su propia actividad, y su propia actividad es la que tiene el botón de salida, entonces el usuario debe realizar finish()la actividad de terceros antes de poder presionar el botón de salida. Y la actividad de terceros debería estar guardando cualquier información no guardada en ese momento. No creo que pueda usar el conmutador de aplicaciones para volver a la actividad del botón de salida a menos que se ejecute en una tarea separada. Y si es una tarea separada, es un proceso separado y, por lo tanto, no se eliminará con el botón de salida.
Neil Traft
2
1. Creo que el 99.99% de los usuarios de Android no deberían preocuparse por cómo el sistema operativo administra las aplicaciones detrás de las cortinas. El resto son geeks y encontrarán herramientas avanzadas que hacen que el sistema se comporte exactamente como quieren. 2. Siempre puede descargar datos confidenciales cuando la actividad se detiene o detiene. 3. Igual que el anterior, los recursos se pueden liberar en los métodos de devolución de llamada del ciclo de vida. Cuando se reanuda la actividad, los recursos se pueden asignar nuevamente.
Zsolt Török
44
Creo que es bastante interesante que tantos usuarios de Android estén instalando "Advanced Task Killer", una aplicación que cierra otras aplicaciones ya que normalmente no puede hacerlo usted mismo. Lo uso todo el tiempo yo mismo. Salir de una aplicación no es algo sin lo que pueda prescindir.
Ted
2
@ ZsoltTörök, el 99.99% de las personas manejan computadoras / teléfonos lentos y se ven obligadas a elegir preocuparse acerca de cómo el sistema operativo maneja las aplicaciones detrás de las cortinas.
Pacerier
10

El kernel de Linux tiene una característica llamada asesino sin memoria falta (como se mencionó anteriormente, las políticas son configurables a nivel de espacio de usuario y el kernel no es óptimo, pero de ninguna manera innecesario).

Y es muy utilizado por Android:

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

Peter Teoh
fuente
9

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á cada vez que 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, querrá restablecer el estado de la aplicación a su estado normal en el momento en que se ejecuta por primera vez después de un arranque del dispositivo, justo antes para llamar a finish () en todas sus actividades. De esa manera, si el usuario selecciona su aplicación nuevamente, parecerá que se ha ejecutado "fresco", sin que quede ningún estado desde el punto anterior a la "salida" simulada.

Si hay algunas acciones especiales que solo deberían ocurrir en la "salida", 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 vuelven a visitar, por lo que no están acostumbrados a la modalidad de "salir" de una aplicación. En cambio, apoyaría una función "clara" que un usuario puede invocar para restablecer la aplicación a un estado inicial predeterminado, sin la necesidad de "dejarla" en el proceso.

La única excepción sería cuando el usuario ha presionado el botón Atrás un número suficiente de veces para hacer que la aplicación se cierre. En esa situación, no hay expectativas por parte del usuario de que el estado se habrá guardado (y si hay un estado no guardado en la aplicación, entonces, 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).

En cuanto a system.exit (0):

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

Específicamente, si usa la lista de Aplicaciones recientes para abrir su aplicación, y luego usa el botón Atrás para cerrar la aplicación (con ese cierre implementado a través de system.exit (0)), la lista de Aplicaciones recientes volverá a ser visible, como lo hará. Nunca he estado 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 ya 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 no funciona debido a que ha cerrado la aplicación usando system.exit (0). Un cierre más civilizado de su aplicación usando finish () podría haber informado al sistema operativo de una manera que le hubiera permitido actualizar su lista de aplicaciones recientes, pero system.exit (0) aparentemente no hace esto.

Este 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 e inmediatamente la abrirán nuevamente 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.

Carl
fuente
¿Quizás podría eliminar la entrada de aplicaciones recientes antes de llamar a terminar ()? Esto es algo que probaré cuando el tiempo lo permita. Tengo un servicio en primer plano con una pequeña actividad de iniciador. Como la actividad es muy pequeña, no es gran cosa si no se mata y se entierra, pero tiene sentido decirle a Android que puede tomar esta antes que el resto, si es posible.
nsandersen 05 de
9

Espero que las cosas cambien con el tiempo. El usuario debería poder eliminar una aplicación o proceso si el sistema operativo encajona correctamente el proceso de la aplicación. Existe la idea de que las aplicaciones deben escribirse perfectamente o el usuario usará solo las aplicaciones que siguen todas las recomendaciones del SDK. Creo que es una tarea difícil.

dipu
fuente
Lo sé. Los productos de Apple son buenos para algunos consumidores. No son buenos para los desarrolladores. El sistema operativo Android tiene todo el potencial para convertirse en el "sistema operativo Windows del mundo de las PC" para teléfonos móviles. puede ser aún mejor Ya está más abierto que las ventanas del mundo de las PC, excepto que no nos permite escribir un administrador de tareas.
dipu
7

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 lograr al terminar () esta segunda actividad y volver a la base de solo 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.

qwerty_ca
fuente
2
Buena idea. Sin embargo, incluso terminar una actividad (o servicio) no detiene el sistema operativo. Oh, no, incluso después de que se haya ejecutado onDestroy, todas las variables y demás siguen ahí. Acabo de ver que en un Servicio, todo es igual a pesar de que se llamó a onDestroy ...
Ted
2
... y así System.exit (0) ayudó =)
Ted
7

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 necesita permitir que el usuario cambie dinámicamente los datos dinámicamente 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 mi aplicación se reiniciara por sí misma. El sistema operativo Android tiene un ciclo de vida de aplicación de diseño muy malo.

Peter Mortensen
fuente
99
public void appRestart () {Intent i = new Intent (getBaseContext (), MyActivity.class); i.addFlags (Intent.FLAG_ACTIVITY_CLEAR_TOP); startActivity (i); }
androidworkz
2
El código de este comentario anterior realmente funciona bien. Al menos puede pasar a la primera actividad en lugar de salir por completo de la aplicación. :)
Harpreet
7

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

O hay una forma similar, pero sin system.exit()cuándo 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()agregar el siguiente código

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.

Lemberg
fuente
7

En primer lugar, nunca, nunca, nunca use System.exit (0).¡Es como hacer que una persona duerma golpeándolo en la cabeza!

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

Creo que un "botón de salida" es estúpido. Muy, muy, 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 y cómo administra los recursos (y hace un gran trabajo).

Creo que si escribe un buen código que haga las cosas correctas (actualizaciones, guardados y actualizaciones) en el momento y las condiciones correctas y use 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 Intent. Por favor mira esas banderas; esos borrarán todo mi backstack llamando a mi DashBoard Activity que es mi actividad "en casa".

Entonces, en mi Dashboard Activity 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 hago el último final (y lo he comprobado: sigue todo el flujo correcto de onPause → onStop → onDestroy) la aplicación todavía está en la actividad reciente (pero Está en blanco).

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

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

StErMi
fuente
8
No muchos consumidores saben qué es un sistema operativo y mucho menos cómo funciona, esto no los hace estúpidos. Querer un botón Salir / Salir / Desactivar los hace normales. Cuando sale de una habitación apaga las luces, lo que es más importante cuando sale de su casa, cierra la puerta con llave y aquí es donde veo el problema con la incapacidad de salir correctamente de un programa. Dejar el programa vivo en segundo plano es un gran riesgo de seguridad.
Squiggles
44
"Creo que un" botón de salida "es estúpido". La mayoría de las aplicaciones de software proporcionan un botón de salida.
IgorGanapolsky
Usted dijo "// AQUÍ DETENGA TODOS SUS SERVICIOS" y luego usó terminar (). Los servicios de Android no tienen un método acabado (). Tienen unbindService (mConnection);
IgorGanapolsky
@Squiggles Si tiene una habitación que apaga automáticamente todas sus luces y cierra la puerta al salir, no necesita preocuparse por eso.
Seshu Vinay
7

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 de consumo.

Android es Java sobre Linux, un verdadero sistema operativo de servidor multiplataforma. 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 existe el concepto de correr o salir. De hecho, los procesos de la aplicación están destinados a ejecutarse hasta que el sistema operativo los libere para sus recursos retenidos.

Como se trata de Stack Overflow, cualquiera 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.

Dominic Cerisano
fuente
No sigo tu salto a "los usuarios de computadoras deben apagar el 90% de su conocimiento". Sí, eso es lo que dice Romain Guy, pero eso no lo hace realidad. Me parece que una sección de "Opciones avanzadas para usuarios de computadoras", con un botón "Salir", satisfaría las necesidades de todos.
Don Hatch
No tengo idea de quién es este "chico Romain", o por qué me está citando. Cerrar las tareas recientes cerrará la aplicación, al igual que detenerse en la información de la aplicación. ADB permite el acceso de shell para usuarios avanzados.
Dominic Cerisano
6

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

Es una aplicación de GPS que sondea los puntos y envía la ubicación actual a un servicio web cada pocos segundos usando un hilo ... Esto podría sondear cada 5 minutos en el caso de Ted para una actualización, luego onStop puede simplemente comenzar 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 un código inicial en onCreate para configurar cosas para la vida útil de la actividad, incluyendo 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 que al instante está lista para volver a abrir porque está en RAM (aunque no tiene RAM como es el ciclo de vida de Android) ... una aplicación siempre está lista, es un teléfono chicos / chicas Si una aplicación usara toda la RAM y el sistema operativo no pudiera cerrarla, entonces la cosa podría dejar de sonar = P Es por eso que el sistema operativo debe poder cerrar su aplicación cuando está en segundo plano (si su aplicación no está t un recurso acaparador no se cerrará BTW), así que vamos a escribir mejores aplicaciones.

Brant
fuente
No deberías llamar a super.onStop desde el método onPause ... Parece que arruinaría las cosas principalmente.
Matt Wolfe el
1
Después de leer más de 20 respuestas filosóficas que simplemente esquivan la pregunta ... +1 por tener algún código.
Pacerier
6

Cada vez que pase a la página siguiente por 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í :)

GaneshKumar
fuente
1
No sale de la aplicación, sino que se trata de Mainactivity.
Sharath
1
Pero tenga cuidado: onPause () NO se llama en el caso de killProcess y System.exit. Tuvimos algunos problemas con eso.
Pavel Biryukov
4

En cualquier caso, si desea finalizar su solicitud, siempre puede llamar System.exit(0);.

Tasos Kleisas
fuente
55
System.exit()NO mata su aplicación si tiene más de una actividad en la pila. Un desarrollador de Android que lo utiliza no ha entendido el ciclo de vida básico de la aplicación de Android. Lee esta respuesta .
Dheeraj Vepakomma
Solución completa con System.exit(0); stackoverflow.com/questions/2033914/…
Sohail Zahid
2
En realidad, System.exit () no matar a su aplicación. Sin embargo, si se llamó a System.exit () desde otro lugar que no sea la actividad principal, Android reiniciará la aplicación con una actividad menos en la pila. Para mí, eso parece una respuesta ridícula a un sistema limpio e intencional. Quiero decir, si se tratara de un div0 o algún accidente no intencional, tal vez sería educado reiniciar. Pero eso ni siquiera causa el relanzamiento automático, según recuerdo. Pero, en cualquier caso, se mata la aplicación . Puede reiniciarse, pero eso no significa que no se haya eliminado.
Jesse Gordon
3

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);
            }
        });
    }
}
Sohail Zahid
fuente
1
Esto puede bloquear su aplicación cuando los usuarios presionan un botón dos veces, especialmente cuando el sistema está bajo una gran carga por cualquier motivo. Esto puede evitarse eliminando las actividades de la matriz.
HopefulHelpful