Pregunta ¿Dejar de usar una aplicación desaprobada?


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

Pregunta: ¿El usuario tiene la opción de matar la aplicación?   a menos que pongamos una opción de menú para matarlo? 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 coloque un botón de la aplicación "salir" o "salir". Es inútil con el modelo de aplicación de Android. Esto también es contrario a cómo funcionan las aplicaciones principales.

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

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

La aplicación que intento crear no es una aplicación para Android Market. No es una aplicación de "amplio uso" para el público en general, es una aplicación de negocios que se utilizará en un campo comercial muy limitado.

Realmente estaba deseando desarrollar para la plataforma Android, ya que aborda una gran cantidad de problemas que existen en Windows Mobile y .NET. Sin embargo, la última semana ha sido algo así como un desvío para mí ... Espero no tener que abandonar Android, pero ahora no se ve muy bien = (

¿Hay alguna manera de que yo De Verdad salir de la aplicación?


1037


origen


Respuestas:


Con el tiempo, esta será la respuesta a su pregunta, pero primero quiero abordar una serie de cuestiones que plantea en sus diversos comentarios sobre las diversas respuestas ya dadas en el momento de redactar este documento. 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   Android para determinar cuándo mi aplicación es   va a ser terminado. eso debe ser   la elección del usuario.

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

Los usuarios de iPhone son más o menos de la misma manera, al presionar el botón de iPhone no necesariamente "se siente" como la aplicación se terminó, ya que muchas aplicaciones de iPhone retoman donde lo dejó el usuario, incluso si la aplicación realmente se apagó (ya que solo iPhone permite una aplicación de terceros a la vez, en este momento).

Como dije antes, hay una gran cantidad de   cosas que están sucediendo en mi aplicación (siendo los datos   EMPUJADO al dispositivo, listas con tareas   que siempre debería estar ahí, etc.).

No sé qué significa "listas con tareas que siempre deberían estar ahí", pero los "datos que se EMPUJAN para el dispositivo" son una ficción agradable y, en cualquier caso, no se deben hacer con una actividad. Use una tarea programada (a través de AlarmManager) para actualizar sus datos para la máxima fiabilidad.

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

Hay muchas aplicaciones de iPhone y Android que se ocupan de esto. Por lo general, es porque 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 cual su aplicación se está "abandonando" es porque el sistema operativo se está apagando, y luego su proceso de actualización fallará a mitad de la transmisión. En general, eso no es algo bueno. Revise las actualizaciones al inicio o revise las actualizaciones de manera totalmente asincrónica (por ejemplo, a través de una tarea programada), nunca al salir.

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

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

Solo debe terminar cuando el   los usuarios quieren terminarlo, nunca   siempre de otra manera. Si no puedes escribir   aplicaciones que se comportan 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 esos casos, los usuarios no "cancelan" nada, simplemente se van. iPhone es un poco diferente, ya que solo permite que una cosa se ejecute a la vez (con algunas excepciones), por lo que el acto de irse implica una terminación bastante inmediata de la aplicación.

¿Hay alguna manera de dejarlo realmente?   ¿la aplicación?

Como todos los demás te dijeron, los usuarios (a través de BACK) o tu código (a través de finish()) puede cerrar su actividad actualmente en ejecución. Los usuarios generalmente no necesitan nada más, para aplicaciones escritas correctamente, del mismo modo que no necesitan una opción de "abandono" para usar aplicaciones web.


No hay dos entornos de aplicaciones iguales, por definición. Esto significa que puede ver las tendencias en los entornos a medida que surgen otros nuevos y otros quedan enterrados.

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

Del mismo modo, hay un movimiento creciente para tratar de eliminar la noción de "terminar" una aplicación. La mayoría de las aplicaciones web no obligan al usuario a desconectarse, sino que implícitamente desconecta al usuario 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 aplicaciones, centrándose en los objetivos de negocio y no se queda con un modelo de implementación vinculado a un entorno de aplicación anterior. Los desarrolladores que no tienen el tiempo o la inclinación para hacerlo se sentirán frustrados con 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 a través de ella.

Por ejemplo, algunos entornos de desarrollo, como Hypercard y Smalltalk, tenían la aplicación y las herramientas de desarrollo mezcladas en una configuración. Este concepto no atrapó mucho, fuera de las extensiones de idioma de las aplicaciones (por ejemplo, VBA en Sobresalir, 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 en los que su modelo sería cierto.

Entonces, cuando escribes:

Junto con otras cosas desordenadas   descubierto, creo que el desarrollo   nuestra aplicación para Android no va a   ocurrir.

Eso parece 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 los encontrará en las aplicaciones web (por ejemplo, sin "finalización"). O, por el contrario, algún día si hacer transfiera su aplicación a la Web, puede descubrir que el flujo de la aplicación web puede ser una mejor opción para Android, y puede volver a visitar un puerto Android en ese momento.


1216



Me gustaría agregar una corrección aquí para los futuros lectores de este hilo. Este matiz en particular ha escapado a mi comprensión por un largo tiempo, así que quiero asegurarme de que ninguno de ustedes cometa los mismos errores:

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

La respuesta corta es que, si quiere salir de su aplicación, debe hacer un seguimiento de todas las actividades en su pila y finish() TODOS cuando el usuario quiere salir (y no, no hay forma de iterar a través de la pila de actividades, por lo que tiene que administrar todo esto por su cuenta). Incluso esto en realidad no mata el proceso o cualquier referencia colgante que pueda tener. Simplemente termina las actividades. Además, no estoy seguro si Process.killProcess(Process.myPid()) funciona mejor; No lo he probado.

Si, por otro lado, está bien que tengas actividades en tu pila, hay otro método que te facilita las cosas: Activity.moveTaskToBack(true) simplemente hará un seguimiento 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 tu 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 asume que el usuario desea seguir haciendo lo que estaba haciendo. (Si está intentando eliminar el proceso de DDMS, primero debe presionar el botón de inicio y luego eliminarlo)
  2. También asume que cada actividad es independiente de todas las otras actividades. Esto es a menudo 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 de manifiesto.
  3. Asume que cada una de tus actividades es completamente autosuficiente y puede ser eliminada / restaurada en cualquier momento. (No me agrada esta suposición en particular, ya que mi aplicación tiene muchas actividades que dependen de una gran cantidad de datos almacenados en caché, demasiado grandes para ser serializados eficientemente durante onSaveInstanceState, pero ¿qué vas 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 eliminará tu aplicación en segundo plano.
  4. El último factor no es tanto una suposición, sino más bien una limitación del sistema operativo: matar a la aplicación explícitamente es lo mismo que la falla de la aplicación, y también lo mismo que Android matando la aplicación para reclamar memoria.  Esto culmina con nuestro golpe de gracia: dado que Android no puede decir si la aplicación salió o se colgó o se mató en segundo plano, supone que el usuario desea regresar donde lo dejó, por lo que el ActivityManager reinicia el proceso.

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

Supongamos que quiero que mis usuarios puedan tomar una foto y cargarla. Lanzo la Actividad de cámara de 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 crearse en su propia tarea). Si la cámara tiene un error y falla, ¿debería ocasionar que se bloquee la aplicación? Desde el punto de vista del usuario, solo la cámara falló y deben regresar a su actividad anterior. Por lo tanto, solo reinicia el proceso con todas las mismas actividades en la pila, menos la cámara. Desde tus actividades debería estar diseñado para que puedan ser asesinados y restaurados en un abrir y cerrar de ojos, esto no debería ser un problema. Desafortunadamente, no todas las aplicaciones se pueden diseñar de esa manera, por lo que es un problema para muchos de nosotros, no importa lo que Romain Guy o cualquier otra persona te diga. Entonces, necesitamos usar soluciones temporales.

Entonces, mi último consejo:

  • No trates de matar el proceso. O llama finish() en todas las actividades o llamada moveTaskToBack(true).
  • Si su proceso falla o es asesinado, y si, como yo, necesita los datos que estaban perdidos en la memoria, tendrá que regresar a la actividad raíz. Para hacer esto, debes llamar startActivity() con un Intento que contiene el Intent.FLAG_ACTIVITY_CLEAR_TOP bandera.
  • Si desea eliminar su aplicación desde la perspectiva de Eclipse DDMS, es mejor que no esté en primer plano, o se reiniciará. Primero debe presionar el botón Inicio, y entonces mata el proceso.

280



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


168



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

No saber lo que su misteriosa aplicación "hace" no es realmente importante. Supongamos que entra en túneles en una intranet corporativa súper segura, realizando alguna supervisión o interacción, y permanece registrada hasta que el usuario "abandone 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 "dejen de fumar".

Esto es simple. Realice un servicio que incluya una notificación continua en la barra de notificaciones que diga "Estoy en la intranet o estoy corriendo". Haga que ese servicio realice toda la funcionalidad que necesita para su aplicación. Tenga actividades que se vinculen a ese servicio para permitir que los usuarios accedan a los bits de la interfaz de usuario que necesitan para interactuar con su "aplicación". Y tenga un menú de Android -> Salir (o cerrar sesión, o lo que sea) botón que le dice al servicio que se cierre, luego cierra la actividad en sí.

Esto es, para todos los intentos y propósitos, exactamente lo que dices que quieres. Hecho de 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 Atrás fuera de su actividad puede dejar su proceso de UNIX al acecho en caso de que el usuario quiera revivir su aplicación. Esto realmente no es diferente de un sistema operativo moderno que almacena en caché los archivos recientemente accedidos en la memoria. Después de salir de su programa de Windows, la mayoría de los recursos 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.


134



Esta es una discusión interesante y perspicaz con la contribución de tantos expertos. Siento que esta publicación debe enviarse desde el sitio web principal de desarrollo de Android, ya que 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 el momento, me ha impresionado la forma en que Android maneja los eventos del ciclo de vida, llevando el concepto de una experiencia similar a la web a las aplicaciones nativas.

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

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

Eso no significa que alguien (¿SO, desarrollador?) Se encargará de eso a su discreción ... simplemente significa "¿dónde está mi botón Rojo X 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. Me trae una satisfacción per se que mi acción logre su propósito.

Aunque un desarrollador puede suplantar este comportamiento utilizando las sugerencias que se dan aquí, la percepción aún permanece, es decir, una aplicación debería dejar de funcionar completamente (ahora), por una fuente (SO) independiente, fiable y neutral bajo demanda del usuario final.


68



poder salir, presionando Espalda botón o llamando finish() en tus Activity. Solo llama finish() a partir de una MenuItem si quieres matarlo explícitamente.

Romain no dice que no se puede hacer, solo que no tiene sentido: los usuarios no necesitan preocuparse por dejar 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 restaura su estado sin importar lo que pase.


35



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 factores humanos luchan con esto todos los días.

Ted ha señalado que una de las aplicaciones más descargadas en Market es el 'App Killer'. Las personas obtienen un poco de serotonina adicional cuando abandonan las aplicaciones. Están acostumbrados a eso con una computadora de escritorio / portátil. Mantiene las cosas moviéndose rápido. Mantiene el procesador fresco y el ventilador encendido. Usa menos energía.

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

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


31



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

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 saber más sobre la plataforma Android; es un cambio en la mentalidad de una aplicación de PC estándar. El hecho de que ninguna de sus publicaciones haya tenido la palabra "Actividad" (a excepción de una cita de Preguntas Frecuentes, es decir, no sus palabras) en ellas me dice que necesita leer un poco más.


28



Entrada en el blog Cuándo incluir un botón de salida en las aplicaciones de Android (sugerencia: nunca) lo explica todo, lejos mejor que yo. Ojalá todos los desarrolladores de Android lo hayan leído ya.

Extractos:

En mi experiencia, lo que [los usuarios] realmente quieren es:    Una forma inequívoca de garantizar que una aplicación deje de consumir recursos (batería, ciclos de CPU, transferencia de datos, etc.).

Muchos usuarios perciben que un botón de salida implementa este requisito   y pide que se agregue. Desarrolladores, buscando complacer a sus usuarios,   agregar amablemente uno. Poco después, ambos fracasan.

  • 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 a la aplicación pero no lo han hecho, y pronto   estarán aún más molestos.
  • El comportamiento de salida ahora es ambiguo. ¿Debería su botón de salida simplemente cerrar la Actividad o debería detener todos los Servicios, Receptores y Alarmas asociados? Que debería Espalda ¿hacer? Qué pasa si golpean Casa ¿en lugar? ¿Qué sucede si tu aplicación tiene un widget? ¿Debería el botón de salida dejar de actualizar también?

La solución es hacer que el botón de retroceso se comporte como es de esperar   salir del botón para. Mejor aún, simplemente deja de consumir recursos cada vez que   la aplicación no es visible

Adelante, lee el artículo completo.


23