FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
amigo jhonalone algunas versiones de android tiene las opcion de aumentar el numero de aplicaciones que se puede tener en segundo plano verifica si tu terminal tiene esas opcionees
y para dec quisiera saber si el componente Websocket es un componente nativo o de tercero pues me llego la idea de incluirlo en las aplicaciones lo use o no ya que has dicho que las aplicaciones duran mas para cerrar |
#2
|
||||||
|
||||||
Hola a todos,
Cita:
Yo creo que esto debe estar documentado en algún lado. Si bien no todos los criterios pormenorizados, al menos un detalle de los mismos, así como indicaciones para los desarrolladores. Lamento no poder enlazar a ningún sitio ahora mismo, pero, creo yo que debe ser así. No se trata de evitarlo: es el "ciclo de vida" de las aplicaciones, es algo que se hace para mejorar la experiencia del usuario, para que la batería no dure "un suspiro", por ejemplo, sino que dure lo máximo posible. Por eso no se trata de evitarlo, sino de lidiar con ello, de tenerlo en cuenta. Por ejemplo, respondiendo a un mensaje tuyo en otro hilo, no es que debamos o sea menester guardar el estado de toda nuestra aplicación, y, después recuperar dicho estado "completamente". Esto, seguramente, no tiene sentido. Más bien hemos de ponernos en el caso de que un usuario esté rellenando algún formulario de nuestra aplicación, y, de repente, pase a otra aplicación, por ejemplo, porque le llaman por teléfono. Lo que acaso debemos guardar nosotros (si lo consideramos necesario, y, por favorecer al usuario) son los datos del formulario en cuestión, lo que ya hubiese escrito el usuario, de modo que, cuando vuelva a reactivar la aplicación, si es necesario (si se desactivó antes) volver a rellenar los datos del formulario, para que el usuario no tenga que escribirlos de nuevo. Pero no se trata de guardar más allá de eso... claro que dependerá de la aplicación, pero, lo que quiero decir es que no se trata de guardar "todo" lo de nuestra aplicación, para recuperarlo después. Nuestra aplicación tendrá un "ciclo de vida", que debemos controlar, pero, no hay que llegar a esos extremos. Un juego, por ejemplo, podrá guardar la partida en curso, si se quiere, pero, no necesitará ir más allá... podrá dar al usuario la opción de lanzar de nuevo la partida "cortada", o bien hacerlo de forma automática, pero, no tiene porqué haber guardado nada más que eso. Cita:
Cita:
Tampoco sé muy bien si estas aplicaciones que acompañan al sistema operativo tienen ya algún tipo de "prioridad" especial, o, tal vez, acaso, que su "reinicio" no sea exactamente igual que en el caso de las aplicaciones Delphi, es decir, que, aunque se reinicien, el proceso es aún más transparente: no se muestra una posible "splash screen" de nuevo, etc. De modo que a nosotros nos parece que estas aplicaciones están funcionando en "background", pero, en realidad no sea así. Por ejemplo, en el caso de la aplicación que desarrollo, los "reinicios" son bastante claros: porque se muestra una "splash screen". Pero esto es algo que tiene que ver con esta aplicación en concreto y con el entorno de desarrollo empleado, etc. Tal vez la calculadora y el reloj se reinicien igualmente, pero, "no se note", como si mostrasen un "splash screen" cada vez que se inician "desde cero". Cita:
Cita:
Cita:
Última edición por dec fecha: 25-07-2017 a las 12:00:34. |
#3
|
||||
|
||||
Tal y como dice dec, y el dibujito que he puesto antes, el ciclo de vida de una aplicación android NO es como una de windows. Cuando sales del programa (o se "duerme") debes programar lo que necesites en los "eventos" activity_pause y activity_resume.
|
#4
|
|||
|
|||
Gracias a todos por vuestro interés, vuestro tiempo y vuestro esfuerzo.
Después de buscar y rebuscar, trastear y trastear con el móvil parece que la solución es bastante sencilla. Se trata de desactivar la opción de "No mantener actividades", tal y como puede verse en la imagen adjunta. Espero os sirva a todos. Saludos a todos.
__________________
"Pedid y se os dará; buscad y hallaréis ..." (Lc 11,9-10) "...si no tengo caridad, nada soy..." (1 Cor 13,1-13) |
#5
|
||||
|
||||
Hola a todos,
Cita:
|
#6
|
|||
|
|||
Bueno, dec, siempre será mejor algo que nada.
Como mucho se le puede pedir al usuario que la active. Ah! por cierto, es una solución parcial, pues estoy comprobando, que cuando recuperas la App al poco tiempo, la mantiene intacta, pero (y esto lo sospecho, no estoy seguro) cuando pasa el tiempo seleccionado para la desactivación de la pantalla sigue "matando" la App y cuando intentas recuperarla, se reinicia. ¡Y yo que pensaba que había resuelto el problema...! Seguiremos investigando.... Saludos a todos.
__________________
"Pedid y se os dará; buscad y hallaréis ..." (Lc 11,9-10) "...si no tengo caridad, nada soy..." (1 Cor 13,1-13) |
#7
|
||||
|
||||
Hola a todos,
Cita:
Cita:
En definitiva, que no estamos ante un problema que haya que solucionar, sino ante cómo Android trata a las aplicaciones, no sólo la tuya, de modo que tenemos que adaptarnos a ese trato. |
#8
|
|||
|
|||
Sé estás haciendo un gran esfuerzo, David.
El "tiempo de gracia" al que te refieres, sólo existe haciendo el cambio propuesto en modo desarrollador, si no haces este cambio, no hay "tiempo de gracia" que valga. Mira, el programa en cuestión consiste en en una agenda para usuarios autónomos donde se gestiona desde el aviso del cliente hasta la emisión de la factura. Como cualquier programa que se precie, tendrá unas cuantas variables globales, para no estar repitiendo en cada Unit, y porque son utilizadas y modificadas por otras units. Creo que no será el único programa que se haya "cargado" Android al optimizar el uso de los nuevos terminales, que, por cierto, tienen menos necesidad de recursos que los antiguos, pues disponen de bastante más memoria y almacenamiento que los anteriores. (Repito en los anteriores no pasaba esto) Esta optimización, la entendería más en los antiguos terminales que en los nuevos. En cualquier caso, "matar las aplicaciones" sin permiso del usuario me parece una acto de una dictadura absolutista sin ningún respeto. Recordemos lo del cambio de función de los botones o el problema generado en TMemo con el texto predictivo y ¡quién sabe cuantas cosas más nos iremos encontrando...! Cuanto más lo pienso más grave veo el alcance del problema. Android es un caprichoso dictador, que lo menos que se le podría pedir al desarrollar cada nueva versión es que respetara la compatibilidad con las anteriores. Creo yo. Bueno, que me salgo del tema, espero que alguien pueda ayudarme, (y creo que no soy el único que necesita, o va a necesitar, esta ayuda) A ver si entre todos conseguimos minimizar los efectos de la dictadura (dura) de Android. Seguiremos trabajando. Saludos a todos.
__________________
"Pedid y se os dará; buscad y hallaréis ..." (Lc 11,9-10) "...si no tengo caridad, nada soy..." (1 Cor 13,1-13) Última edición por jhonalone fecha: 25-07-2017 a las 14:35:01. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Dejar una aplicación siempre en primer plano | Kalikatres | Desarrollo en Delphi para Android | 19 | 28-11-2015 16:48:47 |
Buscar Aplicacion en Ejecucion y traerla al frente | Enan0 | Varios | 0 | 29-09-2012 13:52:25 |
Aplicación en primer plano | jordillussa | Varios | 4 | 20-03-2007 19:58:43 |
Ejecutar aplicacion externa y que este en primer plano | Lorenzati | API de Windows | 11 | 06-07-2004 18:22:10 |
Aplicación siempre en primer plano | Novás | Varios | 2 | 08-03-2004 09:31:09 |
|