Saya mencoba untuk menulis aplikasi yang melakukan sesuatu yang spesifik ketika dibawa kembali ke latar depan setelah beberapa waktu. Apakah ada cara untuk mendeteksi kapan aplikasi dikirim ke latar belakang atau dibawa ke latar depan?
android
background
foreground
iHorse
sumber
sumber
Jawaban:
Metode
onPause()
danonResume()
dipanggil ketika aplikasi dibawa ke latar belakang dan ke latar depan lagi. Namun, mereka juga dipanggil ketika aplikasi dimulai untuk pertama kalinya dan sebelum dimatikan. Anda dapat membaca lebih lanjut di Activity .Tidak ada pendekatan langsung untuk mendapatkan status aplikasi saat berada di latar belakang atau latar depan, tetapi bahkan saya telah menghadapi masalah ini dan menemukan solusinya dengan
onWindowFocusChanged
danonStop
.Untuk detail lebih lanjut, periksa di sini Android: Solusi untuk mendeteksi ketika aplikasi Android pergi ke latar belakang dan kembali ke latar depan tanpa getRunningTasks atau getRunningAppProcesses .
sumber
2018: Android mendukung ini secara alami melalui komponen siklus hidup.
PEMBARUAN Maret 2018 : Sekarang ada solusi yang lebih baik. Lihat ProcessLifecycleOwner . Anda perlu menggunakan komponen arsitektur baru 1.1.0 (terbaru saat ini) tetapi dirancang khusus untuk melakukan ini.
Ada contoh sederhana yang disediakan dalam jawaban ini tetapi saya menulis contoh aplikasi dan posting blog tentang itu.
Sejak saya menulis ini kembali pada tahun 2014, berbagai solusi muncul. Beberapa bekerja, beberapa dianggap bekerja , tetapi memiliki kekurangan (termasuk saya!) Dan kami, sebagai komunitas (Android) belajar untuk hidup dengan konsekuensinya dan menulis solusi untuk kasus-kasus khusus.
Jangan pernah menganggap satu cuplikan kode adalah solusi yang Anda cari, tidak mungkin demikian; lebih baik lagi, cobalah untuk memahami apa yang dilakukannya dan mengapa ia melakukannya.
The
MemoryBoss
kelas tidak pernah benar-benar digunakan oleh saya seperti yang tertulis di sini, itu hanya bagian dari kode semu yang terjadi dengan pekerjaan.Kecuali ada alasan yang sah bagi Anda untuk tidak menggunakan komponen arsitektur baru (dan ada beberapa, terutama jika Anda menargetkan apis super lama), maka lanjutkan dan gunakan. Mereka jauh dari sempurna, tetapi juga tidak
ComponentCallbacks2
.PEMBARUAN / CATATAN (November 2015) : Orang-orang telah membuat dua komentar, pertama adalah yang
>=
harus digunakan alih-alih==
karena dokumentasi menyatakan bahwa Anda tidak harus memeriksa nilai yang tepat . Ini bagus untuk sebagian besar kasus, tetapi ingatlah bahwa jika Anda hanya peduli melakukan sesuatu ketika aplikasi pergi ke latar belakang, Anda harus menggunakan == dan juga menggabungkannya dengan solusi lain (seperti callback Daur Hidup Aktivitas), atau Anda mungkin tidak mendapatkan efek yang Anda inginkan. Contohnya (dan ini terjadi pada saya) adalah jika Anda ingin mengunciaplikasi Anda dengan layar kata sandi ketika pergi ke latar belakang (seperti 1 Kata sandi jika Anda terbiasa dengan itu), Anda mungkin secara tidak sengaja mengunci aplikasi Anda jika kehabisan memori dan tiba-tiba menguji>= TRIM_MEMORY
, karena Android akan memicuLOW MEMORY
panggilan dan itu lebih tinggi dari milikmu. Jadi berhati-hatilah bagaimana / apa yang Anda uji.Selain itu, beberapa orang bertanya tentang cara mendeteksi ketika Anda kembali.
Cara paling sederhana yang dapat saya pikirkan dijelaskan di bawah ini, tetapi karena beberapa orang tidak terbiasa dengan itu, saya menambahkan beberapa kode pseudo di sini. Dengan asumsi Anda memiliki
YourApplication
danMemoryBoss
kelas - kelas, diclass BaseActivity extends Activity
(Anda perlu membuat satu jika Anda tidak memilikinya).Saya merekomendasikan onStart karena Dialog dapat menjeda suatu kegiatan, jadi saya yakin Anda tidak ingin aplikasi Anda berpikir "itu pergi ke latar belakang" jika semua yang Anda lakukan adalah menampilkan dialog layar penuh, tetapi jarak tempuh Anda mungkin bervariasi.
Dan itu saja. Kode di blok if akan hanya akan dieksekusi sekali , bahkan jika Anda pergi ke kegiatan lain, yang baru (yang juga
extends BaseActivity
) akan melaporkanwasInBackground
inifalse
sehingga tidak akan mengeksekusi kode, sampaionMemoryTrimmed
disebut dan bendera diatur ke benar lagi .Semoga itu bisa membantu.
UPDATE / CATATAN (April 2015) : Sebelum Anda pergi semua Salin dan Tempel pada kode ini, perhatikan bahwa saya telah menemukan beberapa contoh di mana itu mungkin tidak 100% dapat diandalkan dan harus dikombinasikan dengan metode lain untuk mencapai hasil terbaik. Khususnya, ada dua contoh yang diketahui di mana
onTrimMemory
panggilan kembali tidak dijamin akan dieksekusi:Jika ponsel Anda mengunci layar saat aplikasi Anda terlihat (mis. Perangkat Anda mengunci setelah beberapa menit), panggilan balik ini tidak dipanggil (atau tidak selalu) karena layar kunci hanya di atas, tetapi aplikasi Anda masih "berjalan" walaupun tertutup.
Jika perangkat Anda relatif rendah pada memori (dan di bawah tekanan memori), Sistem Operasi tampaknya mengabaikan panggilan ini dan langsung ke tingkat yang lebih kritis.
Sekarang, tergantung seberapa penting bagi Anda untuk mengetahui kapan aplikasi Anda pergi ke latar belakang, Anda mungkin atau mungkin tidak perlu memperluas solusi ini bersama dengan melacak siklus hidup aktivitas dan yang lainnya.
Ingatlah selalu hal di atas dan miliki tim QA yang baik;)
AKHIR PEMBARUAN
Mungkin terlambat tetapi ada metode yang dapat diandalkan di Ice Cream Sandwich (API 14) dan di atasnya .
Ternyata ketika aplikasi Anda tidak memiliki UI yang lebih terlihat, panggilan balik dipicu. Callback, yang dapat Anda terapkan dalam kelas khusus, disebut ComponentCallbacks2 (ya, dengan dua). Callback ini hanya tersedia di API Level 14 (Ice Cream Sandwich) dan di atasnya.
Anda pada dasarnya mendapat panggilan ke metode:
Levelnya adalah 20 atau lebih khusus
Saya telah menguji ini dan selalu berhasil, karena level 20 hanyalah "saran" agar Anda ingin melepaskan beberapa sumber daya karena aplikasi Anda tidak lagi terlihat.
Mengutip dokumen resmi:
Tentu saja, Anda harus menerapkan ini untuk benar-benar melakukan apa yang dikatakannya (membersihkan memori yang belum pernah digunakan dalam waktu tertentu, membersihkan beberapa koleksi yang telah duduk tidak digunakan, dll. Kemungkinannya tidak terbatas (lihat dokumen resmi untuk kemungkinan lainnya lebih lanjut) level kritis ).
Tapi, yang menarik, OS memberitahu Anda: HEY, aplikasi Anda pergi ke latar belakang!
Itulah yang ingin Anda ketahui sejak awal.
Bagaimana Anda menentukan kapan Anda kembali?
Yah itu mudah, saya yakin Anda memiliki "BaseActivity" sehingga Anda dapat menggunakan onResume () Anda untuk menandai fakta bahwa Anda kembali. Karena satu-satunya saat Anda mengatakan Anda tidak kembali adalah ketika Anda benar-benar menerima panggilan ke
onTrimMemory
metode di atas .Berhasil. Anda tidak mendapatkan positif palsu. Jika suatu kegiatan dilanjutkan, Anda kembali, 100% dari waktu. Jika pengguna kembali ke belakang, Anda mendapat
onTrimMemory()
panggilan lain .Anda harus memasukkan Aktivitas Anda (atau lebih baik, kelas khusus).
Cara termudah untuk menjamin bahwa Anda selalu menerima ini adalah dengan membuat kelas sederhana seperti ini:
Untuk menggunakan ini, dalam implementasi Aplikasi Anda ( Anda memilikinya, KANAN? ), Lakukan sesuatu seperti:
Jika Anda membuat,
Interface
Anda bisa menambahkanelse
ituif
dan menerapkanComponentCallbacks
(tanpa 2) yang digunakan dalam apa pun di bawah API 14. Callback itu hanya memilikionLowMemory()
metode dan tidak dipanggil ketika Anda pergi ke latar belakang , tetapi Anda harus menggunakannya untuk memangkas memori .Sekarang luncurkan Aplikasi Anda dan tekan home. Anda
onTrimMemory(final int level)
Metode harus dipanggil (petunjuk: tambahkan logging).Langkah terakhir adalah membatalkan registrasi dari callback. Mungkin tempat terbaik adalah
onTerminate()
metode Aplikasi Anda, tetapi metode itu tidak dipanggil di perangkat nyata:Jadi, kecuali Anda benar-benar memiliki situasi di mana Anda tidak lagi ingin didaftarkan, Anda dapat dengan aman mengabaikannya, karena proses Anda sedang sekarat di tingkat OS.
Jika Anda memutuskan untuk membatalkan registrasi di beberapa titik (jika Anda, misalnya, memberikan mekanisme mematikan aplikasi untuk membersihkan dan mati), Anda dapat melakukan:
Dan itu saja.
sumber
level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN
yang menghindari masalah dalam pembaruan Anda, poin 2. Mengenai poin 1, itu bukan masalah bagi saya, karena aplikasi tidak benar-benar pergi ke latar belakang, jadi itulah cara yang seharusnya berfungsi.Begini cara saya berhasil menyelesaikan ini. Ini berfungsi pada premis bahwa menggunakan referensi waktu antara transisi aktivitas kemungkinan besar akan memberikan bukti yang memadai bahwa aplikasi telah "dilatar belakangi" atau tidak.
Pertama, saya telah menggunakan contoh android.app.Application (sebut saja MyApplication) yang memiliki Timer, TimerTask, konstanta untuk mewakili jumlah milidetik maksimum yang dapat diambil oleh transisi dari satu aktivitas ke aktivitas lainnya (saya pergi dengan nilai 2s), dan boolean untuk menunjukkan apakah aplikasi tersebut "di latar belakang":
Aplikasi ini juga menyediakan dua metode untuk memulai dan menghentikan timer / tugas:
Bagian terakhir dari solusi ini adalah untuk menambahkan panggilan ke masing-masing metode ini dari peristiwa onResume () dan onPause () dari semua aktivitas atau, lebih disukai, dalam Kegiatan dasar yang mewarisi semua Aktivitas konkret Anda:
Jadi dalam kasus ketika pengguna hanya menavigasi antara aktivitas aplikasi Anda, onPause () dari aktivitas yang berangkat memulai timer, tetapi hampir segera aktivitas yang dimasukkan membatalkan timer sebelum dapat mencapai waktu transisi maks. Dan begitu pula InBackground akan salah .
Di sisi lain ketika suatu Kegiatan datang ke latar depan dari Peluncur, bangun perangkat, mengakhiri panggilan telepon, dll., Kemungkinan besar tugas penghitung waktu dieksekusi sebelum acara ini, dan dengan demikian InBackground disetel ke true .
sumber
Sunting: komponen arsitektur baru membawa sesuatu yang menjanjikan: ProcessLifecycleOwner , lihat jawaban @ vokilam
Solusi aktual menurut Google I / O talk :
Iya. Saya tahu sulit untuk percaya solusi sederhana ini bekerja karena kami memiliki begitu banyak solusi aneh di sini.
Tapi ada harapan.
sumber
ProcessLifecycleOwner
tampaknya menjadi solusi yang menjanjikan juga.Implementasi bisa sesederhana
Menurut kode sumber, nilai penundaan saat ini adalah
700ms
.Juga menggunakan fitur ini memerlukan
dependencies
:sumber
implementation "android.arch.lifecycle:extensions:1.0.0"
danannotationProcessor "android.arch.lifecycle:compiler:1.0.0"
dari repositori Google (mis.google()
)Berdasarkan jawaban Martín Marconcinis (terima kasih!) Saya akhirnya menemukan solusi yang andal (dan sangat sederhana).
Kemudian tambahkan ini ke onCreate () dari kelas Aplikasi Anda
sumber
Kami menggunakan metode ini. Kelihatannya terlalu sederhana untuk bekerja, tetapi telah teruji dengan baik di aplikasi kami dan ternyata bekerja dengan sangat baik dalam semua kasus, termasuk pergi ke layar beranda dengan tombol "home", dengan tombol "kembali", atau setelah kunci layar. Cobalah.
Gagasannya adalah, ketika di latar depan, Android selalu memulai aktivitas baru sebelum menghentikan yang sebelumnya. Itu tidak dijamin, tapi begitulah cara kerjanya. BTW, Flurry tampaknya menggunakan logika yang sama (hanya tebakan, saya tidak memeriksa itu, tapi itu mengait pada acara yang sama).
Sunting: sesuai komentar, kami juga pindah ke onStart () di versi kode yang lebih baru. Juga, saya menambahkan panggilan super, yang hilang dari posting awal saya, karena ini lebih merupakan konsep daripada kode yang berfungsi.
sumber
onStop is called when the activity is no longer visible to the user
,.Jika aplikasi Anda terdiri dari beberapa aktivitas dan / atau aktivitas bertumpuk seperti widget tab bar, maka mengesampingkan onPause () dan onResume () tidak akan berfungsi. Yaitu ketika memulai aktivitas baru, aktivitas saat ini akan dijeda sebelum yang baru dibuat. Hal yang sama berlaku ketika menyelesaikan (menggunakan tombol "kembali") suatu kegiatan.
Saya telah menemukan dua metode yang tampaknya berfungsi seperti yang diinginkan.
Yang pertama membutuhkan izin GET_TASKS dan terdiri dari metode sederhana yang memeriksa apakah aktivitas yang berjalan paling atas di perangkat milik aplikasi, dengan membandingkan nama paket:
Metode ini ditemukan dalam kerangka Droid-Fu (sekarang disebut Ignition).
Metode kedua yang saya terapkan sendiri tidak memerlukan izin GET_TASKS, yang bagus. Sebaliknya itu sedikit lebih rumit untuk diterapkan.
Di kelas MainApplication Anda, Anda memiliki variabel yang melacak jumlah aktivitas yang berjalan di aplikasi Anda. Di onResume () untuk setiap aktivitas Anda meningkatkan variabel dan di onPause () Anda menguranginya.
Ketika jumlah aktivitas yang berjalan mencapai 0, aplikasi diletakkan di latar belakang JIKA kondisi berikut ini benar:
Ketika Anda dapat mendeteksi bahwa aplikasi telah mengundurkan diri ke latar belakang, mudah dideteksi ketika dibawa kembali ke latar depan juga.
sumber
getRunnintTasks()
Buat kelas yang diperluas
Application
. Kemudian di dalamnya kita dapat menggunakan metode override-nya,onTrimMemory()
,.Untuk mendeteksi jika aplikasi pergi ke latar belakang, kami akan menggunakan:
sumber
FragmentActivity
Anda juga mungkin ingin menambahkanlevel == ComponentCallbacks2.TRIM_MEMORY_COMPLETE
juga.Pertimbangkan untuk menggunakan onUserLeaveHint. Ini hanya akan dipanggil ketika aplikasi Anda masuk ke latar belakang. onPause akan memiliki kasus sudut untuk ditangani, karena dapat dipanggil karena alasan lain; misalnya jika pengguna membuka aktivitas lain di aplikasi Anda seperti halaman pengaturan Anda, metode onPause aktivitas utama Anda akan dipanggil meskipun mereka masih di aplikasi Anda; melacak apa yang terjadi akan mengarah ke bug ketika Anda bisa menggunakan callback onUserLeaveHint yang melakukan apa yang Anda minta.
Ketika pada UserLeaveHint dipanggil, Anda dapat mengatur flag boolean inBackground menjadi true. Saat onResume dipanggil, anggap saja Anda kembali ke latar depan jika flag inBackground diatur. Ini karena onResume juga akan dipanggil pada aktivitas utama Anda jika pengguna hanya di menu pengaturan Anda dan tidak pernah meninggalkan aplikasi.
Ingat bahwa jika pengguna menekan tombol beranda saat di layar pengaturan Anda, onUserLeaveHint akan dipanggil dalam aktivitas pengaturan Anda, dan ketika mereka kembali onResume akan dipanggil dalam aktivitas pengaturan Anda. Jika Anda hanya memiliki kode deteksi ini di aktivitas utama Anda, Anda akan kehilangan use case ini. Untuk memiliki kode ini di semua aktivitas Anda tanpa kode duplikat, miliki kelas aktivitas abstrak yang memperluas Aktivitas, dan masukkan kode umum Anda di dalamnya. Maka setiap aktivitas yang Anda miliki dapat memperluas aktivitas abstrak ini.
Sebagai contoh:
sumber
ActivityLifecycleCallbacks mungkin menarik, tetapi tidak didokumentasikan dengan baik.
Padahal, jika Anda memanggil registerActivityLifecycleCallbacks (), Anda harus bisa mendapatkan panggilan balik untuk saat Aktivitas dibuat, dihancurkan, dll. Anda dapat memanggil getComponentName () untuk Aktivitas.
sumber
The android.arch.lifecycle menyediakan paket kelas dan interface yang memungkinkan Anda membangun komponen siklus hidup-sadar
Aplikasi Anda harus mengimplementasikan antarmuka LifecycleObserver:
Untuk melakukan itu, Anda perlu menambahkan ketergantungan ini ke file build.gradle Anda:
Seperti yang direkomendasikan oleh Google, Anda harus meminimalkan kode yang dieksekusi dalam metode aktivitas siklus hidup:
Anda dapat membaca lebih lanjut di sini: https://developer.android.com/topic/libraries/architecture/lifecycle
sumber
Di Aplikasi Anda, tambahkan panggilan balik dan periksa aktivitas root dengan cara seperti ini:
sumber
Saya telah membuat proyek di Github app-foreground-background-listen
Buat BaseActivity untuk semua Kegiatan di aplikasi Anda.
Sekarang gunakan BaseActivity ini sebagai kelas super dari semua Aktivitas Anda seperti MainActivity meluas BaseActivity dan onAppStart akan dipanggil ketika Anda memulai aplikasi Anda dan onAppPause () akan dipanggil ketika aplikasi pergi latar belakang dari layar apa pun.
sumber
Ini cukup mudah ProcessLifecycleOwner
Tambahkan dependensi ini
Di Kotlin :
Kemudian dalam aktivitas dasar Anda:
Lihat artikel saya tentang topik ini: https://medium.com/@egek92/how-to-actual-detect-foreground-background-changes-in-your-android-application-without-wanting-9719cc822c48
sumber
Anda dapat menggunakan ProcessLifecycleOwner melampirkan pengamat siklus hidup untuk itu.
maka pada
onCreate()
kelas Aplikasi Anda, Anda menyebutnya:dengan ini Anda akan dapat menangkap peristiwa
ON_PAUSE
danON_STOP
aplikasi Anda yang terjadi ketika berjalan di latar belakang.sumber
Tidak ada metode siklus langsung untuk memberi tahu Anda ketika seluruh Aplikasi berjalan latar / latar depan.
Saya telah melakukan ini dengan cara sederhana. Ikuti instruksi di bawah ini untuk mendeteksi fase latar belakang / latar depan aplikasi.
Dengan sedikit penyelesaian, itu mungkin. Di sini, ActivityLifecycleCallbacks datang untuk menyelamatkan. Biarkan saya berjalan selangkah demi selangkah.
Pertama, buat kelas yang memperluas aplikasi android.app.plikasi dan mengimplementasikan antarmuka ActivityLifecycleCallbacks . Di Application.onCreate (), daftarkan callback.
Daftarkan kelas "Aplikasi" di Manifest seperti di bawah ini
<application android:name=".App"
,.Akan ada setidaknya satu Kegiatan di negara mulai ketika aplikasi di latar depan dan tidak akan ada Kegiatan di negara mulai ketika aplikasi berada di latar belakang.
Deklarasikan 2 variabel seperti di bawah ini di kelas "Aplikasi".
activityReferences
akan menyimpan hitungan jumlah aktivitas dalam kondisi awal .isActivityChangingConfigurations
adalah tanda untuk menunjukkan jika Aktivitas saat ini mengalami perubahan konfigurasi seperti sakelar orientasi.Dengan menggunakan kode berikut, Anda dapat mendeteksi jika Aplikasi datang di latar depan.
Ini adalah cara mendeteksi jika Aplikasi berjalan latar.
Bagaimana itu bekerja:
Ini adalah sedikit trik yang dilakukan dengan cara metode Siklus Hidup disebut secara berurutan. Biarkan saya menelaah sebuah skenario.
Asumsikan bahwa pengguna meluncurkan Aplikasi dan Kegiatan Peluncur A diluncurkan. Panggilan Siklus Hidup akan menjadi,
Sekarang Aktivitas A memulai Kegiatan B.
Kemudian pengguna menavigasi kembali dari Kegiatan B,
Kemudian pengguna menekan tombol Home,
Dalam hal ini, jika pengguna menekan tombol Beranda dari Aktivitas B dan bukan tombol Kembali, tetap saja akan sama dan aktivitas referensi akan
0
. Oleh karena itu, kita dapat mendeteksi sebagai Aplikasi memasuki Latar Belakang.Jadi, apa perannya
isActivityChangingConfigurations
? Dalam skenario di atas, anggap Kegiatan B mengubah orientasi. Urutan panggilan balik akan menjadi,Itu sebabnya kami memiliki pemeriksaan tambahan
isActivityChangingConfigurations
untuk menghindari skenario ketika Aktivitas melalui Konfigurasi berubah.sumber
Saya menemukan metode yang baik untuk mendeteksi aplikasi apakah masuk foreground atau latar belakang. Ini kode saya . Semoga ini bisa membantu Anda.
}
sumber
Kamu bisa menggunakan:
Untuk membedakan antara mulai baru dan mulai ulang.
sumber
Sunting 2: Apa yang saya tulis di bawah ini sebenarnya tidak akan berfungsi. Google telah menolak aplikasi yang menyertakan panggilan ke ActivityManager.getRunningTasks (). Dari dokumentasi , jelas bahwa API ini hanya untuk tujuan debugging dan pengembangan. Saya akan memperbarui posting ini segera setelah saya punya waktu untuk memperbarui proyek GitHub di bawah ini dengan skema baru yang menggunakan timer dan hampir sama baiknya.
Sunting 1: Saya telah menulis posting blog dan membuat repositori GitHub sederhana untuk membuatnya sangat mudah.
Jawaban yang diterima dan diberi peringkat teratas bukanlah pendekatan yang terbaik. Implementasi jawaban teratas dari isApplicationBroughtToBackground () tidak menangani situasi di mana Aktivitas utama Aplikasi menghasilkan ke Aktivitas yang didefinisikan dalam Aplikasi yang sama, tetapi memiliki paket Java yang berbeda. Saya datang dengan cara untuk melakukan ini yang akan berhasil dalam kasus itu.
Panggil ini di onPause (), dan itu akan memberi tahu Anda jika aplikasi Anda masuk ke latar belakang karena aplikasi lain telah dimulai, atau pengguna telah menekan tombol beranda.
sumber
Jawaban yang benar di sini
Buat kelas dengan nama MyApp seperti di bawah ini:
Lalu, di mana pun Anda inginkan (aktivitas pertama yang lebih baik diluncurkan di aplikasi), tambahkan kode di bawah ini:
Selesai! Sekarang ketika aplikasi di latar belakang, kita mendapatkan log
status : we are out
dan ketika kita masuk aplikasi, kita mendapatkan logstatus : we are out
sumber
Solusi saya terinspirasi oleh jawaban @ d60402 dan juga bergantung pada jendela waktu, tetapi tidak menggunakan
Timer
:di mana
SingletonApplication
merupakan perluasanApplication
kelas:sumber
Saya menggunakan ini dengan Google Analytics EasyTracker, dan itu berhasil. Bisa diperluas untuk melakukan apa yang Anda cari menggunakan integer sederhana.
sumber
Saya tahu ini sedikit terlambat tetapi saya pikir semua jawaban ini memiliki beberapa masalah sementara saya melakukannya seperti di bawah ini dan itu bekerja dengan sempurna.
buat callback daur hidup aktivitas seperti ini:
dan cukup daftarkan di kelas aplikasi Anda seperti di bawah ini:
sumber
Ini tampaknya menjadi salah satu pertanyaan paling rumit di Android karena (saat tulisan ini dibuat) Android tidak memiliki padanan
applicationDidEnterBackground()
atauapplicationWillEnterForeground()
panggilan balik iOS . Saya menggunakan Perpustakaan AppState yang disatukan oleh @jenzz .Ternyata ini adalah persis apa yang saya butuhkan, terutama karena aplikasi saya memiliki beberapa kegiatan sehingga hanya memeriksa
onStart()
atauonStop()
pada suatu kegiatan tidak akan memotongnya.Pertama saya menambahkan dependensi ini ke gradle:
Maka itu masalah sederhana menambahkan baris ini ke tempat yang sesuai dalam kode Anda:
Bergantung pada bagaimana Anda berlangganan yang diamati, Anda mungkin harus berhenti berlangganan untuk menghindari kebocoran memori. Lagi info lebih lanjut di halaman github .
sumber
Ini adalah versi jawaban @ d60402 yang dimodifikasi: https://stackoverflow.com/a/15573121/4747587
Lakukan semua yang disebutkan di sana. Tetapi alih-alih memiliki
Base Activity
dan menjadikannya sebagai orangtua untuk setiap aktivitas dan yang menimpaonResume()
danonPause
, lakukan di bawah ini:Di kelas aplikasi Anda, tambahkan baris:
registerActivityLifecycleCallbacks (Application.ActivityLifecycleCallbacks callback);
Ini
callback
memiliki semua metode siklus aktivitas dan sekarang Anda dapat menggantionActivityResumed()
danonActivityPaused()
.Lihatlah Gist ini: https://gist.github.com/thsaravana/1fa576b6af9fc8fff20acfb2ac79fa1b
sumber
Anda dapat mencapai ini dengan mudah dengan bantuan
ActivityLifecycleCallbacks
danComponentCallbacks2
sesuatu seperti di bawah ini.Buat kelas yang
AppLifeCycleHandler
mengimplementasikan antarmuka di atas.Di kelas Anda yang meluas
Application
implementAppLifeCycleCallback
untuk mendapatkan callback ketika aplikasi beralih antara latar depan dan latar belakang. Sesuatu seperti di bawah ini.Semoga ini membantu.
EDIT Sebagai alternatif, Anda sekarang dapat menggunakan komponen arsitektur sadar siklus hidup.
sumber
Karena saya tidak menemukan pendekatan apa pun, yang juga menangani rotasi tanpa memeriksa perangko waktu, saya pikir saya juga membagikan bagaimana kami sekarang melakukannya di aplikasi kami. Satu-satunya tambahan untuk jawaban ini https://stackoverflow.com/a/42679191/5119746 adalah, bahwa kami juga mempertimbangkan orientasi tersebut.
Kemudian, untuk callback kami memiliki resume terlebih dahulu:
Dan padaAktivitas Berhenti:
Dan kemudian, inilah tambahan: Memeriksa perubahan orientasi:
Itu dia. Semoga ini bisa membantu seseorang :)
sumber
Kami dapat memperluas solusi ini menggunakan
LiveData
:Sekarang kita bisa berlangganan LiveData ini dan menangkap acara yang diperlukan. Sebagai contoh:
sumber
Jawaban ini sepertinya tidak benar. Metode-metode ini juga disebut ketika aktivitas lain dimulai dan berakhir. Yang bisa Anda lakukan adalah menjaga bendera global (ya, global buruk :) dan atur ini menjadi true setiap kali Anda memulai aktivitas baru. Setel ke false di onCreate setiap aktivitas. Lalu, di onPause Anda memeriksa tanda ini. Jika itu salah, aplikasi Anda masuk ke latar belakang, atau terbunuh.
sumber