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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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".

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.

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.

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.

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:

• OOM killer no es para el espacio de usuario

• Notas de Android ( Información de OOM Killer - donde puede configurar la función OOM en Android)

• Portado de Android en destino real

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

• Autokiller / Configuración del asesino de tareas interno de Android

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.

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.

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.

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.

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.

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.

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.

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.

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í :)

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

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);
            }
        });
    }
}