versiones - android wikipedia




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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Entonces, cuando escribes:

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

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


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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

Entonces, mi último consejo:

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

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


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

`YourActivityname.this.finish()`;

Ejemplo:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

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

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

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


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

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

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

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

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

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

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


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


Hmmmm ...

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

  • Haga las actividades de la aplicación guardar / restaurar el estado como se recomienda en la documentación del ciclo de vida del desarrollador.

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

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

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

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


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

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

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


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

Crear una matriz estática en application classoconstants class.

Constantes

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

MainActivity Agregar referencia de actividad actual en esta matriz

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

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

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

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}

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

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


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

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

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

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

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

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

Respecto a system.exit (0):

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

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

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

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


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


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

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

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

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


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

Y es muy utilizado por Android:

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


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


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

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


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

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

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

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

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

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







android