La chiusura di una domanda è disapprovata?

Andando avanti nel mio tentativo di imparare Android, ho appena letto quanto segue :

Domanda: l'utente può scegliere di uccidere l'applicazione a meno che non inseriamo un'opzione di menu per ucciderla? Se tale opzione non esiste, in che modo l'utente termina l'applicazione?

Risposta: (Romain Guy): l'utente no, il sistema lo gestisce automaticamente. Questo è lo scopo del ciclo di vita delle attività (in particolare onPause / onStop / onDestroy). Non importa quello che fai, non mettere un pulsante di applicazione "esci" o "esci". È inutile con il modello di applicazione di Android. Ciò è anche contrario al modo in cui funzionano le applicazioni principali.

Hehe, per ogni passo che faccio nel mondo Android mi imbatto in una sorta di problema = (

Apparentemente, non puoi uscire da un'applicazione in Android (ma il sistema Android può distruggere completamente la tua app ogni volta che ne hai voglia). Cosa succede con quello? Sto iniziando a pensare che sia impossibile scrivere un'app che funzioni come una "normale app" - che l'utente può chiudere l'app quando decide di farlo. Questo non è qualcosa da fare affidamento sul sistema operativo.

L'applicazione che sto cercando di creare non è un'applicazione per Android Market. Non è un'applicazione per un "ampio uso" da parte del pubblico, è un'app aziendale che verrà utilizzata in un campo aziendale molto ristretto.

Non vedevo davvero l'ora di sviluppare per la piattaforma Android, poiché risolve molti problemi che esistono in Windows Mobile e .NET. Tuttavia, l'ultima settimana è stata un po 'una svolta per me ... Spero di non dover abbandonare Android, ma in questo momento non sembra molto buono = (

C'è un modo per me di chiudere davvero l'applicazione?

Questo alla fine arriverà alla tua domanda, ma voglio prima affrontare una serie di problemi che sollevi nei tuoi vari commenti alle varie risposte già fornite al momento della stesura di questo scritto. Non ho intenzione di cambiare idea - piuttosto, questi sono qui per gli altri che verranno a leggere questo post in futuro.

Il punto è che non posso consentire ad Android di determinare quando verrà terminata la mia app. quella deve essere la scelta dell'utente.

Milioni di persone sono perfettamente soddisfatte del modello in cui l'ambiente chiude l'applicazione in base alle esigenze. Questi utenti semplicemente non pensano a "terminare" l'app per Android, non più di quanto non pensino a "terminare" una pagina Web o "terminare" un termostato.

Gli utenti di iPhone sono più o meno allo stesso modo, in quanto premendo il pulsante iPhone non si "sente" necessariamente che l'app è stata terminata, dal momento che molte app per iPhone riprendono da dove si era interrotto l'utente, anche se l'app era davvero chiusa (dal momento che solo iPhone consente al momento un'app di terze parti alla volta).

Come ho detto sopra, ci sono molte cose che stanno succedendo nella mia app (i dati vengono SPINTI sul dispositivo, elenchi con attività che dovrebbero sempre essere lì, ecc.).

Non so che cosa significhi "elenchi con attività che dovrebbero sempre essere presenti", ma i "dati che vengono spinti sul dispositivo" sono una finzione piacevole e non dovrebbero essere svolti da un'attività in ogni caso. Utilizzare un'attività pianificata (tramite AlarmManager) per aggiornare i dati per la massima affidabilità.

I nostri utenti accedono e non possono farlo ogni volta che ricevono una telefonata e Android decide di uccidere l'app.

Ci sono molte applicazioni iPhone e Android che si occupano di questo. Di solito, è perché mantengono le credenziali di accesso, anziché forzare gli utenti ad accedere ogni volta manualmente.

Ad esempio, vogliamo verificare gli aggiornamenti all'uscita dall'applicazione

Questo è un errore su qualsiasi sistema operativo. Per quanto ne sai, il motivo per cui la tua applicazione viene "chiusa" è perché il sistema operativo si sta spegnendo e quindi il processo di aggiornamento fallirà a metà flusso. In generale, non è una buona cosa. Controlla gli aggiornamenti all'avvio o controlla gli aggiornamenti in modo totalmente asincrono (ad esempio, tramite un'attività pianificata), mai all'uscita.

Alcuni commenti suggeriscono che premere il pulsante Indietro non uccide affatto l'app (vedi link nella mia domanda sopra).

La pressione del pulsante INDIETRO non "uccide l'app". Termina l'attività visualizzata sullo schermo quando l'utente preme il pulsante INDIETRO.

Dovrebbe terminare solo quando gli utenti vogliono terminarlo, mai e poi mai in altro modo. Se non riesci a scrivere app che si comportano così in Android, penso che Android non possa essere utilizzato per scrivere app reali = (

Quindi nemmeno le applicazioni Web possono farlo. O WebOS , se capisco correttamente il loro modello (non ho ancora avuto modo di giocarci con uno). In tutti questi, gli utenti non "terminano" nulla - se ne vanno e basta. iPhone è un po 'diverso, in quanto attualmente consente di eseguire solo una cosa alla volta (con poche eccezioni), quindi l'atto di partire implica una chiusura abbastanza immediata dell'app.

C'è un modo per me di chiudere davvero l'applicazione?

Come tutti gli altri ti hanno detto, gli utenti (tramite BACK) o il tuo codice (tramite finish()) possono chiudere l'attività attualmente in esecuzione. Gli utenti in genere non hanno bisogno di nient'altro, per le applicazioni scritte correttamente, non più di quanto abbiano bisogno di un'opzione "quit" per l'utilizzo delle applicazioni Web.

Non esistono due ambienti applicativi uguali, per definizione. Ciò significa che puoi vedere le tendenze negli ambienti quando ne sorgono di nuove e altre vengono seppellite.

Ad esempio, c'è un movimento crescente per cercare di eliminare la nozione di "file". La maggior parte delle applicazioni Web non obbliga gli utenti a pensare ai file. Le app per iPhone in genere non obbligano gli utenti a pensare ai file. Le app Android in genere non obbligano gli utenti a pensare ai file. E così via.

Allo stesso modo, c'è un movimento crescente per cercare di eliminare l'idea di "terminare" un'app. La maggior parte delle applicazioni Web non obbliga l'utente a disconnettersi, ma piuttosto a disconnettersi in modo implicito dopo un periodo di inattività. Stessa cosa con Android e, in misura minore, iPhone (e forse WebOS).

Ciò richiede una maggiore enfasi sulla progettazione delle applicazioni, concentrandosi sugli obiettivi aziendali e non attenersi a un modello di implementazione legato a un precedente ambiente applicativo. Gli sviluppatori che non hanno il tempo o la tendenza a farlo saranno frustrati da ambienti più nuovi che rompono il loro modello mentale esistente. Non è colpa di nessuno dei due ambienti, non più di quanto sia colpa di una montagna per i temporali che vi circolano piuttosto che attraverso.

Ad esempio, in alcuni ambienti di sviluppo, come Hypercard e Smalltalk, l'applicazione e gli strumenti di sviluppo sono stati riuniti in un'unica configurazione. Questo concetto non ha attirato molto, al di fuori delle estensioni linguistiche alle app (ad esempio, VBA in Excel , Lisp in AutoCAD ). Gli sviluppatori che hanno escogitato modelli mentali che presumevano l'esistenza di strumenti di sviluppo nell'app stessa, quindi, hanno dovuto cambiare il loro modello o limitarsi agli ambienti in cui il loro modello sarebbe stato vero.

Quindi, quando scrivi:

Insieme ad altre cose disordinate che ho scoperto, penso che lo sviluppo della nostra app per Android non accadrà.

Sembrerebbe essere il meglio, per te, per ora. Allo stesso modo, ti consiglierei di non tentare di eseguire il porting della tua applicazione sul Web, poiché alcuni degli stessi problemi che hai segnalato con Android troverai anche nelle applicazioni Web (ad esempio, nessuna "terminazione"). O, al contrario, un giorno se si fa porta la vostra applicazione per il Web, è possibile che il flusso dell'applicazione Web può essere una migliore corrispondenza per Android, ed è possibile rivedere una porta Android a quel tempo.

Vorrei solo aggiungere una correzione qui per i futuri lettori di questa discussione. Questa particolare sfumatura è sfuggita alla mia comprensione da molto tempo, quindi voglio assicurarmi che nessuno di voi commetta gli stessi errori:

System.exit()non uccide la tua app se hai più di un'attività in pila. Ciò che realmente accade è che il processo viene interrotto e riavviato immediatamente con una minore attività nello stack. Questo è anche ciò che accade quando l'app viene interrotta dalla finestra di dialogo Forza chiusura o anche quando si tenta di interrompere il processo da DDMS. Questo è un fatto del tutto privo di documenti, per quanto ne sappia.

La risposta breve è che, se si desidera uscire dall'applicazione, è necessario tenere traccia di tutte le attività nel proprio stack e di finish()TUTTE quando l'utente desidera uscire (e no, non è possibile eseguire iterazioni nello stack delle attività , quindi devi gestire tutto questo da solo). Anche questo non uccide effettivamente il processo o eventuali riferimenti penzolanti che potresti avere. Termina semplicemente le attività. Inoltre, non sono sicuro che Process.killProcess(Process.myPid())funzioni meglio; Non l'ho provato.

Se, d'altra parte, ti va bene avere attività rimanenti nel tuo stack, c'è un altro metodo che ti semplifica le cose: Activity.moveTaskToBack(true)ti basterà semplicemente sullo sfondo del tuo processo e mostrerà la schermata principale.

La lunga risposta implica una spiegazione della filosofia alla base di questo comportamento. La filosofia nasce da una serie di presupposti:

1. Innanzitutto, ciò accade solo quando l'app è in primo piano. Se è in background, il processo terminerà correttamente. Tuttavia, se è in primo piano, il sistema operativo presuppone che l'utente voglia continuare a fare qualunque cosa stia facendo. (Se stai cercando di terminare il processo da DDMS, dovresti prima premere il pulsante Home, quindi ucciderlo)
2. Presuppone inoltre che ogni attività sia indipendente da tutte le altre attività. Questo è spesso vero, ad esempio nel caso in cui l'app avvii l'attività del browser, che è completamente separata e non è stata scritta da te. L'attività del browser può o non può essere creata sulla stessa attività, a seconda dei suoi attributi manifest.
3. Presuppone che ciascuna delle tue attività sia completamente autosufficiente e possa essere uccisa / ripristinata in un attimo. (Non mi piace questo particolare presupposto, dal momento che la mia app ha molte attività che si basano su una grande quantità di dati memorizzati nella cache, troppo grandi per essere serializzati in modo efficiente durante onSaveInstanceState, ma cosa farebbe?) Per la maggior parte delle app Android ben scritte questo dovrebbe essere vero, poiché non sai mai quando la tua app verrà uccisa in background.
4. Il fattore finale non è tanto un presupposto, quanto piuttosto una limitazione del sistema operativo: uccidere l'app in modo esplicito è lo stesso del crash dell'app, e anche lo stesso di Android che uccide l'app per recuperare memoria. Questo culmina nel nostro colpo di grazia: poiché Android non può dire se l'app è uscita o si è arrestata in modo anomalo o è stata uccisa in background, si presume che l'utente voglia tornare da dove era stato interrotto, quindi ActivityManager riavvia il processo.

Quando ci pensi, questo è appropriato per la piattaforma. Innanzitutto, questo è esattamente ciò che accade quando il processo viene interrotto in background e l'utente ritorna su di esso, quindi deve essere riavviato da dove era stato interrotto. In secondo luogo, questo è ciò che accade quando l'app si arresta in modo anomalo e presenta la temuta finestra di dialogo Forza chiusura.

Di 'che voglio che i miei utenti siano in grado di scattare una foto e caricarla. Avvio l'attività della fotocamera dalla mia attività e chiedo di restituire un'immagine. La fotocamera viene inserita nella parte superiore della mia attività corrente (anziché essere creata nella sua stessa attività). Se la videocamera ha un errore e si arresta in modo anomalo, ciò dovrebbe provocare il crash dell'intera app? Dal punto di vista dell'utente, solo la fotocamera ha fallito e dovrebbero essere riportati alla loro attività precedente. Quindi riavvia il processo con tutte le stesse attività nello stack, meno la videocamera. Dal momento che le tue attività dovrebbero essere progettate in modo tale da poter essere uccise e ripristinate in un attimo, questo non dovrebbe essere un problema. Sfortunatamente, non tutte le app possono essere progettate in questo modo, quindi lo èun problema per molti di noi, non importa quello che ti dice Romain Guy o chiunque altro. Quindi, dobbiamo usare soluzioni alternative.

Quindi, il mio consiglio di chiusura:

• Non tentare di interrompere il processo. Chiamare finish()tutte le attività o chiamare moveTaskToBack(true).
• Se il tuo processo si arresta in modo anomalo o viene interrotto e se, come me, hai bisogno dei dati che erano in memoria che ora sono persi, dovrai tornare all'attività di root. Per fare questo, dovresti chiamare startActivity()con un Intento che contiene il Intent.FLAG_ACTIVITY_CLEAR_TOPflag.
• Se vuoi uccidere la tua app dalla prospettiva DDMS di Eclipse, è meglio che non sia in primo piano o si riavvierà da sola. Devi prima premere il pulsante Home, quindi terminare il processo.

Tutte le mie applicazioni hanno pulsanti di chiusura ... e molto spesso ricevo commenti positivi dagli utenti a causa di ciò. Non mi interessa se la piattaforma è stata progettata in modo che le applicazioni non dovrebbero averne bisogno. Dire "non metterli lì" è ridicolo. Se l'utente vuole uscire ... Fornisco loro l'accesso per fare esattamente questo. Non penso che riduca il funzionamento di Android e sembra una buona pratica. Capisco il ciclo di vita ... e la mia osservazione è stata che Android non fa un buon lavoro nel gestirlo .... ed è un dato di base.

Smetti di pensare alla tua applicazione come a un'applicazione monolitica. È una serie di schermate dell'interfaccia utente che l'utente può interagire con la tua "applicazione" e le "funzioni" fornite tramite i servizi Android.

Non sapere cosa "fa" la tua misteriosa app non è molto importante. Supponiamo che tunnel in qualche intranet aziendale super sicura, eseguendo un po 'di monitoraggio o interazione e rimanga connesso fino a quando l'utente "esce dall'applicazione". Poiché il tuo reparto IT lo comanda, gli utenti devono essere molto consapevoli di quando sono IN o OUT della rete Intranet. Da qui la tua mentalità sul fatto che è importante che gli utenti "smettano".

Questo è semplice Crea un servizio che inserisca una notifica in corso nella barra di notifica dicendo "Sono nell'Intranet o sono in esecuzione". Chiedi a quel servizio di eseguire tutte le funzionalità necessarie per la tua applicazione. Avere attività che si legano a quel servizio per consentire ai tuoi utenti di accedere ai bit dell'interfaccia utente di cui hanno bisogno per interagire con la tua "applicazione". E disponi di un pulsante Menu Android -> Esci (o disconnetti, o altro) che dice al servizio di uscire, quindi chiude l'attività stessa.

Questo è, a tutti gli effetti, esattamente quello che dici di volere. Fatto in modo Android. Guarda Google Talk o Google Maps Navigation per esempi di questa "uscita" è possibile mentalità. L'unica differenza è che la pressione del pulsante Indietro al di fuori dell'attività potrebbe lasciare in sospeso il processo UNIX nel caso in cui l'utente desideri ripristinare l'applicazione. Questo non è davvero diverso da un moderno sistema operativo che memorizza nella cache i file a cui è stato effettuato l'accesso di recente. Dopo aver chiuso il programma Windows, molto probabilmente le risorse necessarie sono ancora in memoria, in attesa di essere sostituite da altre risorse in quanto vengono caricate ora che non sono più necessarie. Android è la stessa cosa.

Davvero non vedo il tuo problema.

Questa è una discussione interessante e approfondita con tanti esperti che contribuiscono. Sento che questo post dovrebbe essere rinviato all'interno del sito Web principale di sviluppo Android, perché ruota attorno a uno dei progetti principali del sistema operativo Android.

Vorrei anche aggiungere i miei due centesimi qui.

Finora sono rimasto impressionato dal modo in cui Android gestisce gli eventi del ciclo di vita, portando il concetto di un'esperienza simile al Web nelle app native.

Detto questo, credo ancora che dovrebbe esserci un Quitpulsante. Perché? ... non per me, Ted o nessuno dei guru della tecnologia qui, ma al solo scopo di soddisfare una richiesta dell'utente finale.

Anche se non sono un grande fan di Windows, ma molto tempo fa hanno introdotto un concetto al quale la maggior parte degli utenti finali è abituata (un pulsante X) ... "Voglio smettere di eseguire un widget quando" Voglio ".

Ciò non significa che qualcuno (OS, sviluppatore?) Se ne occuperà a sua discrezione ... significa semplicemente "dov'è il mio pulsante X rosso a cui sono abituato". La mia azione dovrebbe essere analoga a "terminare una chiamata premendo un pulsante", "spegnere il dispositivo premendo un pulsante" e così via e così via ... è una percezione. È di per sé una soddisfazione che la mia azione abbia effettivamente raggiunto il suo scopo.

Anche se uno sviluppatore può falsificare questo comportamento usando i suggerimenti forniti qui, la percezione rimane comunque, cioè un'applicazione dovrebbe cessare completamente di funzionare (ora), da una fonte indipendente, affidabile e neutra (OS) su richiesta dell'utente finale.

È possibile uscire, premendo il Backtasto o chiamando finish()nel vostro Activity. Chiama finish()da a MenuItemse vuoi ucciderlo esplicitamente.

Romain non sta dicendo che non può essere fatto, solo che è inutile: gli utenti non devono preoccuparsi di smettere o salvare il loro lavoro o altro, poiché il modo in cui funziona il ciclo di vita delle applicazioni ti incoraggia a scrivere software intelligente che salva automaticamente e ripristina il suo stato, qualunque cosa accada.

Questo dibattito si riduce alla secolare domanda se gli sviluppatori conoscano meglio o se l'utente sappia meglio. Progettisti professionisti in tutti i settori dei fattori umani lottano con questo ogni giorno.

Ted ha sottolineato che una delle app più scaricate sul mercato è "App Killer". Le persone ottengono un po 'di serotonina extra quando abbandonano le applicazioni. Ci sono abituati con un desktop / laptop. Mantiene le cose in rapido movimento. Mantiene il processore freddo e la ventola si accende. Usa meno energia.

Se consideri che un dispositivo mobile è una nave molto più piccola, puoi apprezzare in particolare il loro incentivo a "gettare in mare ciò che non ti serve più". Ora gli sviluppatori di Android hanno affermato che il sistema operativo lo sa meglio e che uscire da un'app è antico. Lo sostengo con tutto il cuore.

Tuttavia, credo anche che non dovresti frustrare l'utente, anche se quella frustrazione è nata dalla sua stessa ignoranza. Per questo motivo, concludo che avere un'opzione 'Esci' è un buon design, anche se si tratta principalmente di un pulsante placebo che non fa altro che chiudere una vista.

Ted, ciò che stai cercando di realizzare può essere fatto, forse non proprio come lo stai pensando in questo momento.

Ti suggerisco di leggere su attività e servizi. Smetti di usare il termine "app" e inizia a fare riferimento ai componenti, ad esempio Attività, Servizio. Penso che devi solo saperne di più sulla piattaforma Android; è un cambiamento nella mentalità da un'app PC standard. Il fatto che nessuno dei tuoi post contenga la parola "Attività" (a meno di una citazione delle FAQ, cioè non le tue parole) mi dice che devi leggere ancora.

Post sul blog Quando includere un pulsante di uscita nelle app Android (Suggerimento: mai) spiega molto, molto meglio di me. Vorrei che ogni sviluppatore Android lo avesse già letto.

estratti:

Nella mia esperienza ciò che [gli utenti] vogliono veramente è: un modo inequivocabile per garantire che un'app smetta di consumare risorse (batteria, cicli della CPU, trasferimento dei dati, ecc.).

Molti utenti percepiscono che un pulsante di uscita implementa questo requisito e ne chiedono l'aggiunta. Gli sviluppatori, cercando di soddisfare i propri utenti, ne aggiungono obbligatoriamente uno. Poco dopo falliscono entrambi.

• Nella maggior parte dei casi il pulsante di uscita chiama semplicemente Activity.finish(). Questo è esattamente equivalente a premere il pulsante Indietro. Esattamente. I servizi continuano a funzionare e il polling continua ad accadere. Gli utenti potrebbero pensare di aver ucciso l'app ma non l'hanno fatto e presto saranno ancora più infastiditi.
• Il comportamento di uscita è ora ambiguo. Il tuo pulsante di uscita dovrebbe semplicemente chiudere l'Attività o dovrebbe anche arrestare tutti i Servizi, i Ricevitori e gli Allarmi associati? Cosa dovrebbe Backfare? Cosa succede se colpiscono Homeinvece? Cosa succede se la tua app ha un widget? Anche il pulsante di uscita dovrebbe interrompere l'aggiornamento?

La soluzione è fare in modo che il pulsante Indietro si comporti come ci si aspetterebbe dal pulsante di uscita. Meglio ancora, basta smettere di consumare risorse ogni volta che l'app non è visibile.

Vai avanti e leggi l'articolo completo.

Risposta: (Romain Guy): l'utente no, il sistema lo gestisce automaticamente. Questo è lo scopo del ciclo di vita delle attività (in particolare onPause / onStop / onDestroy). Non importa quello che fai, non mettere un pulsante di applicazione "esci" o "esci". È inutile con il modello di applicazione di Android. Ciò è anche contrario al modo in cui funzionano le applicazioni principali.

1: uscire completamente da un'applicazione può essere generalmente non obbligatorio, ma non è inutile. E se Windows non avesse un'opzione di uscita? Il sistema sarebbe troppo lento poiché la memoria era piena e il sistema operativo doveva indovinare con quali programmi era finito. Non mi interessa cosa dicono Romain Guy o persino Larry Page e Sergey Brin: questi sono fatti indiscutibili: i sistemi funzionano più lentamente quando devono uccidere i compiti per ottenere la memoria prima che una nuova app possa essere lanciata. Non puoi dirmi che non ci vuole tempo per uccidere un'app! Anche la luce proveniente da stelle lontane prendere tempo ... V'è un certo uso nel permettere all'utente di chiudere completamente le applicazioni.

2: Contrariamente a come funzionano le applicazioni principali? Cosa dovrebbe significare? Quando ho finito di eseguire un'app per ora, non sta più facendo alcun lavoro ... Sta solo aspettando di essere ucciso dal sistema operativo quando è necessaria la sua memoria.

In sintesi, c'è una netta differenza tra minimizzare ed uscire, e nessuno dei due pizzichi colpisce bene per l'altro. Lasciamo un cacciavite in ogni vite? O una chiave in ogni porta? Lasciamo tutti i nostri apparecchi in alto fino a quando l'interruttore non scoppia e dobbiamo accendere un altro apparecchio? Lasciamo la lavastoviglie piena di piatti e ne tiriamo fuori abbastanza ogni volta per fare spazio a quelli nuovi sporchi? Lasciamo tutte le macchine che corrono nel vialetto fino a quando ... oh, non importa.

Se l'utente desidera ridurre a icona un'app, la cosa migliore è minimizzarla. Se un utente vuole uscire da un'app, allora è meglio uscire.

È accigliato? Questa è la visione di Android: si accigliano. E molti sviluppatori indipendenti di rookie Android non vedono l'ora.

Ma quando si arriva proprio a questo, c'è una buona codifica e una cattiva codifica. Esistono buoni modelli di flusso di programma e ci sono cattivi modelli di flusso di programma.

Lasciare i programmi in memoria quando l'utente sa che hanno finito con loro semplicemente non è un buon flusso di programma. Non serve assolutamente a nulla e rallenta le cose quando si avviano nuove app o quando si eseguono app allocare più memoria.

È un po 'come la tua auto: ci sono momenti in cui la lasci accesa, come fermarti a un semaforo, o forse il fast food attraversare o fermarti al bancomat. Ma ci sono altre situazioni in cui vuoi spegnerlo, come quando vai al lavoro, al supermercato o persino a casa.

Allo stesso modo, se stai giocando e il telefono squilla, sì. Metti in pausa il gioco e continua a funzionare. Ma se l'utente ha finito di giocare per un po ', allora lascialo uscire.

Il pulsante di uscita su alcune applicazioni dovrebbe essere più evidente rispetto ad altri. I giochi, ad esempio, oi programmi in cui è probabile che l'utente voglia uscire completamente, dovrebbero avere un'uscita ovvia. Altri programmi, come, forse, programmi di posta elettronica, dove uscire è un desiderio improbabile (in modo che possa continuare a controllare la posta elettronica) - questi programmi non dovrebbero sprecare lo spazio dello schermo di input di controllo principale con un'opzione di uscita, ma per un buon flusso di programma, esso dovrebbe avere un'opzione di uscita. Che cosa succede se qualcuno decide che non desidera che il proprio programma di posta tenti di controllare la posta elettronica quando si trova in un'area con scarsa copertura, o magari in una chiamata Skype o altro? Lasciali uscire dal programma di posta elettronica, se lo desiderano!

Sospendere ed uscire sono due compiti fondamentali e nessuno dei due svolge il ruolo dell'altro.

Penso che il punto sia che non è necessario uscire dall'app a meno che non si disponga di un software difettoso. Android esce dall'app quando l'utente non la utilizza e il dispositivo ha bisogno di più memoria. Se hai un'app che deve eseguire un servizio in background, probabilmente vorrai un modo per disattivare il servizio.

Ad esempio, Google Listen continua a riprodurre podcast quando l'app non è visibile. Ma c'è sempre il pulsante di pausa per disattivare il podcast quando l'utente ha finito con esso. Se ricordo bene, Ascolta, inserisce anche un collegamento nella barra delle notifiche in modo da poter sempre accedere rapidamente al pulsante di pausa. Un altro esempio è un'app come un'app di Twitter, ad esempio, che esegue costantemente il polling di un servizio su Internet. Questi tipi di app dovrebbero davvero consentire all'utente di scegliere la frequenza con cui eseguire il polling del server o se anche eseguire il polling in un thread in background.

Se è necessario disporre di codice che viene eseguito all'uscita, è possibile sovrascrivere onPause (), onStop () o onDestroy () come appropriato. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Se non riesci a capire come rendere persistenti i tuoi dati / connessioni (e quindi la tua "applicazione"), non sarai in grado di fare ciò che "devi" fare con Android.

Coloro che scaricano quei piccoli killer app carini di solito scoprono che non aiutano la durata della batteria o l'utilizzo della memoria, ma impediscono al sistema operativo di fare il suo compito di gestire la memoria in modo efficiente ...

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

Vorrei prendere in considerazione la lettura di "Sviluppo di applicazioni wireless Android" pubblicato da Addison-Wesley. Lo sto solo finendo ed è MOLTO accurato.

Sembra che tu abbia alcuni fraintendimenti fondamentali sulla piattaforma Android. Anch'io ero un po 'frustrato all'inizio con il ciclo di vita delle applicazioni Android, ma dopo aver compreso meglio, sono arrivato a godermi davvero questo approccio. Questo libro risponderà a tutte le tue domande e molto altro ancora. È davvero la migliore risorsa che ho trovato per i nuovi sviluppatori Android.

Inoltre, penso che sia necessario rilasciare una porta line-to-line dell'app esistente. Per trasferire la tua applicazione sulla piattaforma Android, parte del design dell'applicazione cambierà. Il ciclo di vita delle applicazioni utilizzato è necessario in quanto i dispositivi mobili dispongono di risorse molto limitate rispetto ai sistemi desktop e consentono ai dispositivi Android di eseguire diverse applicazioni in modo ordinato e consapevole delle risorse. Fai uno studio più approfondito della piattaforma e penso che ti renderai conto che ciò che vuoi fare è del tutto fattibile. Buona fortuna.

A proposito, non sono in alcun modo affiliato con Addison-Wesley o qualsiasi persona o organizzazione associata a questo libro. Dopo aver riletto il mio post, mi sento un po 'fanboy. Mi è davvero piaciuto moltissimo e l'ho trovato estremamente utile. :)

Quasi il 99% delle volte non è necessario che un'applicazione Android assuma il proprio ciclo di vita. Il più delle volte si tratta di una migliore pianificazione o di una progettazione più intelligente dell'applicazione. Ad esempio, piuttosto creare un servizio interno (non esportato) per gestire download, ecc. O progettare azioni e attività attorno al flusso di lavoro dell'utente.

Detto questo, dove c'è una volontà c'è un modo. Android fornisce, attraverso la classe android.os.Process, un'API molto migliore di Java per controllare il processo sottostante. E a differenza di Java non tratta lo sviluppatore come un idiota nascondendolo tutto dietro una semplice chiamata java.lang.System.exit ().

Quindi, come chiedi alla tua applicazione di suicidarsi in Android? Bene, il trucco è semplice:

Crea la tua classe di applicazione Android ereditando dalla classe standard android.app.Application (ricorda di dichiararla nel file AndroidManifest.xml).

Sostituisci il metodo onCreate () e archivia l'ID processo che ha avviato l'applicazione:

this.pid = android.os.Process.myPid(); // Save for later use.

Ora per terminare l'applicazione, fornire un metodo kill ():

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Ora, ogni volta che hai bisogno della tua app per suicidarti, digita il cast del contesto dell'applicazione e chiama il tuo metodo kill!

((MySuicidalApp) context.getApplicationContext()).kill()

Ricorda solo che, a causa delle politiche di gestione dei processi in Android, specificamente correlate ai servizi, Android potrebbe semplicemente scegliere di riavviare il servizio (vedi Non utilizzare Task Killer su Android ).

Quando concepisco un'applicazione in Android, la vedo in questo modo:

• Stai lavorando con la tua applicazione
• Il telefono squillò
• Prendi la chiamata
• Alla fine della chiamata, torni alla tua domanda nello stesso posto in cui ti trovavi

Per fare ciò, hai solo bisogno del Backpulsante o del Homepulsante del telefono (premendo brevemente o a lungo) e la barra di notifica.

Quando Backesco dall'applicazione, utilizzo il pulsante solo fino a quando non ne esco o il Homepulsante.

Ecco come penso che la maggior parte delle applicazioni siano concepite. Ma se ho bisogno di una sorta di sessione o connessione, l'ho chiarito all'utente con un pulsante di accesso / logout e una notifica (barra del titolo o altro). Questo è uno stile piuttosto diverso dalla pura applicazione di stile "exit".

Su PC, hai un desktop multi-GUI e su Android, ovviamente hai multi-task, ma visualizzi solo un'app alla volta (non considero i widget qui ^^). E su un telefono cellulare, in qualsiasi momento, potresti ricevere una notifica per qualcosa di più importante di quello che stai facendo.

Quindi l'intero concetto di un'applicazione si basa su qualcosa di diverso che "entra nell'applicazione - lavora - esce dall'applicazione".

Hmmmm ...

Penso che semplicemente non vedi l'app per Android nel modo giusto. Puoi fare qualcosa di simile a quello che vuoi facilmente:

• Le attività dell'app salvano / ripristinano lo stato come è incoraggiato nella documentazione del ciclo di vita degli sviluppatori.

• Se durante la fase di ripristino sono necessari alcuni accessi (non sono disponibili informazioni di accesso / sessione), procedere.

• Alla fine aggiungi un pulsante / menu / timeout, nel qual caso lo farai finish()senza salvare il login e altre informazioni sulla sessione, rendendo implicitamente la fine della sessione dell'app: quindi se l'app viene avviata / riportata in primo piano, inizierà una nuova sessione.

In questo modo non ti interessa davvero se l'app viene davvero rimossa dalla memoria o meno.

Se si vuole veramente per rimuoverlo dalla memoria (questo è scoraggiato, e BTW per quale scopo?) Si può uccidere è condizionatamente alla fine di onDestroy()con java.lang.System.exit(0)(o forse restartPackage(..)?). Ovviamente fallo solo nel caso in cui desideri "terminare davvero l'app", perché onDestroy()fa parte del normale ciclo di vita delle attività e non finisce affatto con un'app.

Poiché un'applicazione in un contesto Android è solo un mucchio di attività vagamente correlate, uscire da un'applicazione non ha molto senso. È possibile terminare () un'attività e verrà disegnata la vista dell'attività precedente nello stack Attività.

Sono d'accordo con Ted. Capisco che uscire dall'applicazione non sia il "modo Android", ma non sembra che debba essere precluso. Ecco tre motivi per cui potresti voler uscire davvero dall'applicazione (non solo dall'attività):

1. L'utente potrebbe desiderare un po 'di controllo su quale app viene uccisa in caso di memoria insufficiente. Se un'app importante A è in esecuzione in background, potresti voler uscire dall'app B quando hai finito in modo che l'app A non venga uccisa dal sistema operativo.

2. Se la tua applicazione ha dati sensibili memorizzati nella cache, potresti voler uccidere l'app in modo che un'app virus / worm / canaglia non riesca a raggiungerla. So che il modello di sicurezza dovrebbe prevenirlo, ma per ogni evenienza ...

3. Se l'applicazione utilizza risorse (come rete, CPU, sensori, ecc.) Che potrebbero influire negativamente sul telefono, un modo per garantire che tali risorse vengano liberate è uscire dall'applicazione. Comprendo che le app ben educate dovrebbero liberare risorse quando non sono necessarie. Ma ancora una volta, uscire dall'applicazione sembra un modo ragionevole per garantirlo.

Il kernel di Linux ha una funzione chiamata killer di memoria insufficiente (come menzionato sopra, i criteri sono configurabili a livello di spazio utente e il kernel non è ottimale, ma non è assolutamente necessario).

Ed è ampiamente utilizzato da Android:

• OOM Killer non è per userspace

• Note Android (OOM Killer Info - dove puoi configurare la funzione OOM su Android)

• Porting Android su target reale

Alcune app per lo spazio utente sono disponibili per aiutare con queste app kill, ad esempio:

• Autokiller / Configurazione del task killer interno di Android

Apparentemente hai trovato la risposta che desideri nel comando finish (). Questo non rimuoverà la tua app dalla memoria, ma Android lo farà ogni volta che ha bisogno delle risorse, quindi non fa alcuna differenza che non lo farai esplicitamente.

Vorrei solo aggiungere che per ottenere il pieno effetto che normalmente avrebbe un'uscita da un'applicazione, si vorrebbe ripristinare lo stato dell'app a qualunque sia il suo stato normalmente nel momento in cui viene eseguito per la prima volta dopo l'avvio del dispositivo, appena prima alla chiamata di finish () su tutte le tue attività. In questo modo, se l'utente seleziona di nuovo la tua app, sembrerà che sia stata eseguita "nuova", senza alcuno stato lasciato dal punto prima dell'uscita simulata.

Se ci sono alcune azioni speciali che dovrebbero verificarsi solo in "uscita", come il salvataggio del lavoro dell'utente o altro, è possibile anche eseguirle prima della parte di reinizializzazione della routine precedente.

Questo approccio consente di raggiungere l'obiettivo di disporre di un comando "exit" senza violare la filosofia di Android di lasciare la gestione delle risorse del sistema operativo, inclusa la chiusura delle app, nelle mani del sistema operativo.

Personalmente, non userei questo approccio, perché gli utenti Android si aspettano che un'app conservi la sua continuità quando la rivisitano, e quindi non sono abituati alla modalità di "uscita" di un'app. Vorrei invece supportare una funzione "chiara" che un utente può invocare per ripristinare l'app a uno stato iniziale predefinito, senza la necessità di "lasciarla" nel processo.

L'unica eccezione sarebbe quando l'utente ha premuto il pulsante Indietro un numero sufficiente di volte per far chiudere l'app. In tale situazione, non ci sono aspettative da parte dell'utente che lo stato sarà stato salvato (e se c'è stato non salvato nell'app, allora tu, come sviluppatore, dovresti avere il codice che gestisce il pulsante Indietro che rileva quei dati non salvati, e richiede all'utente di salvarlo su SharedPreferences o su un file o su un altro supporto non volatile).

Per quanto riguarda system.exit (0):

Se decidi di utilizzare system.exit (0) per chiudere la tua app con maleducata finalità (ad es. A seguito di una pressione finale del pulsante Indietro), ti avvertirei che sebbene per me questo "funzioni" e in alcuni casi è stato l'unico modo in cui sono stato in grado di chiudere un'app senza che rimanga traccia di essa, c'è un piccolo inconveniente che si verifica in Jelly Bean quando usi questo approccio.

In particolare, se si utilizza l'elenco App recenti per aprire l'app, quindi si utilizza il pulsante Indietro per chiudere l'app (con la chiusura implementata tramite system.exit (0)), l'elenco App recenti diventerà nuovamente visibile, così come sarà mai stato chiuso. Se poi tocchi la voce della tua app in quell'elenco per eseguirla una seconda volta dallo stesso, già aperto, Elenco app recenti, non ci sarà risposta.

Ho il sospetto che la causa di ciò sia che l'elenco delle app recenti sta trattenendo un riferimento all'app che è diventata non funzionale a causa della chiusura dell'app tramite system.exit (0). Una chiusura più civile della tua app usando finish () avrebbe potuto informare il sistema operativo in un modo che avrebbe permesso di aggiornare il suo elenco di app recenti, ma apparentemente system.exit (0) non lo fa.

Questo non è un grosso problema in sé e per sé, poiché pochissime persone apriranno un'app dalle App recenti, quindi la chiuderanno e la riapriranno immediatamente dallo stesso elenco di App recenti recenti. E se toccano il pulsante Home e riaprono l'elenco delle app recenti, la voce della tua app sarà lì e sarà perfettamente funzionante. Ma penso che dimostri che l'uso di system.exit (0) può interferire con la corretta comunicazione tra la tua app e il sistema operativo, e ciò suggerisce che potrebbero esserci altre, più gravi, forse sottili, conseguenze dell'uso di questo approccio.

Spero che le cose cambino nel tempo. L'utente dovrebbe essere in grado di uccidere un'app o un processo se il processo dell'app è sottoposto a sandbox correttamente dal sistema operativo. Si ritiene che le app debbano essere scritte perfettamente o che l'utente utilizzerà solo le app che seguono tutti i consigli dell'SDK. Penso che sia un ordine elevato.

C'è un design (relativamente) semplice che ti permetterà di aggirare l'enigma "exit". Rendi la tua app uno stato (attività) "base" che è solo uno schermo vuoto. Al primo onCreate dell'attività, puoi avviare un'altra attività in cui si trova la funzionalità principale della tua app. L'uscita può quindi essere eseguita completando () la seconda attività e tornando alla base di uno schermo vuoto. Il sistema operativo può mantenere questo schermo vuoto in memoria per tutto il tempo che desidera ...

In sostanza, poiché non è possibile uscire dal sistema operativo, si trasforma semplicemente in un nulla creato da sé.

Senza una funzione di uscita per lo sviluppatore dell'applicazione per uccidere la propria applicazione è un pessimo design.

La mia applicazione deve consentire all'utente di modificare dinamicamente i dati in modo dinamico durante il runtime e l'utente deve riavviare l'applicazione per rendere l'effetto di modifica, ma Android non ha consentito il riavvio dell'applicazione da solo. Il sistema operativo Android ha un ciclo di vita dell'applicazione di progettazione pessimo.

Per chiudere un'app in qualsiasi momento usa FLAG_ACTIVITY_CLEAR_TOPflag in Intent e poisystem.exit();

Oppure c'è un modo simile, ma senza system.exit()quando vuoi uscire chiama questo metodo:

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

Nel tuo HomeActivity.onCreate()seguente codice aggiunto

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

Funzionerà senza interrompere il ciclo di vita di Android.

Prima di tutto, mai e poi mai usare System.exit (0). È come far dormire una persona dandogli un pugno in testa!

Secondo: sto affrontando questo problema. Prima di condividere la mia soluzione a, voglio condividere i miei pensieri.

Penso che un "pulsante di uscita" sia stupido. Davvero davvero stupido. E penso che anche gli utenti (consumatori) che chiedono un pulsante di uscita per la tua applicazione siano stupidi. Non capiscono come funziona il sistema operativo e come gestisce le risorse (e fa un ottimo lavoro).

Penso che se scrivi un buon pezzo di codice che fa le cose giuste (aggiornamenti, salvataggi e push) al momento e nelle condizioni giuste e usando le cose giuste (Servizio e Ricevitore) funzionerà abbastanza bene e nessuno si lamenterà .

Ma per farlo devi studiare e imparare come funzionano le cose su Android. Ad ogni modo, questa è la mia soluzione per fornire agli utenti un "pulsante di uscita".

Ho creato un menu Opzioni sempre visibile in ogni attività (ho un'attività super che lo fa).

Quando l'utente fa clic su quel pulsante, ecco cosa succede:

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

Quindi sto salvando in SharedPreferences che voglio uccidere la mia app e inizio un Intento. Si prega di guardare quelle bandiere; quelli cancelleranno tutto il mio backstack chiamando la mia attività DashBoard che è la mia attività "home".

Quindi nella mia Dashboard Activity eseguo questo metodo in 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();
    }
}

E funzionerà abbastanza bene.

L'unica cosa che non capisco perché sta accadendo è che quando faccio l'ultimo traguardo (e ho controllato: sta seguendo tutto il flusso corretto di onPause → onStop → onDestroy) l'applicazione è ancora sull'attività recente (ma è vuoto).

Sembra che l'ultimo intento (che ha avviato DashboardActivity) sia ancora nel sistema.

Devo scavare di più per rimuoverlo.

Il ciclo di vita delle applicazioni Android è progettato per gli utenti di telefoni cellulari, non per gli utenti di computer.

Il ciclo di vita dell'app è il paradigma brutalmente semplicistico necessario per trasformare un server Linux in un dispositivo consumer.

Android è Java su Linux, un vero sistema operativo server multipiattaforma. È così che si è diffuso così rapidamente. Il ciclo di vita dell'app incapsula la realtà sottostante del sistema operativo.

Per gli utenti mobili, le app sono appena installate o non installate. Non esiste il concetto di correre o uscire. In effetti, i processi delle app devono essere eseguiti fino a quando il sistema operativo non li rilascia per le risorse trattenute.

Poiché si tratta di Stack Overflow, chiunque legga questo è un utente di computer e deve disattivare il 90% delle proprie conoscenze per comprendere il ciclo di vita delle app mobili.

Mi ci è voluto più tempo per leggere queste domande e risposte che per implementare effettivamente un ciclo di vita delle applicazioni Android semi-corretto.

È un'app GPS che esegue il polling dei punti e invia la posizione corrente a un servizio web ogni pochi secondi usando un thread ... Questo potrebbe essere il polling ogni 5 minuti nel caso di Ted per un aggiornamento, quindi onStop può semplicemente avviare l'attività di aggiornamento Ted era così preoccupato se ne venisse trovato uno (Ted asincrono, non scrivere codice come un programmatore di Windows o i tuoi programmi funzioneranno come programmi Windows ... eww, non è poi così difficile).

Ho fatto un po 'di codice iniziale in onCreate per impostare cose per la durata dell'attività, incluso 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();
}

Questo codice potrebbe essere completamente sbagliato, ma funziona. Questa è una delle mie prime applicazioni Android.

Voilà, un'applicazione che non consuma CPU quando è in background, ma è immediatamente pronta per riaprire perché è in RAM (anche se non contiene RAM come il ciclo di vita di Android) ... un'app è sempre pronta, è un telefono , ragazzi / ragazze. Se un'app utilizzava tutta la RAM e non poteva essere chiusa dal sistema operativo, la cosa potrebbe smettere di squillare = P Ecco perché il sistema operativo deve essere in grado di chiudere l'app quando è in background (se l'applicazione non è un porco di risorse non sarà chiuso BTW), quindi scriviamo solo applicazioni migliori.

Ogni volta che si passa alla pagina successiva tramite l'intento, utilizzare:

`YourActivityname.this.finish()`;

Esempio:

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

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

In modo che nessuna attività venga eseguita in background e quando si desidera uscire dall'app, utilizzare:

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

Questa uscita ha funzionato come un incanto per me :)

In ogni caso, se si desidera terminare l'applicazione, è sempre possibile chiamare System.exit(0);.

Se hai 10,20 .. attività multiple in esecuzione e vuoi terminarle tutte e uscire dal sistema.

Crea un array statico in application classoconstants class.

costanti

public class Constants {

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

}

MainActivity Aggiungi riferimento all'attività corrente in questo array

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