Di AppsConf 2018 , yang berlangsung pada 8-9 Oktober, saya membuat presentasi tentang pembuatan aplikasi android dalam satu Kegiatan. Meskipun topiknya terkenal, ada banyak prasangka mengenai pilihan seperti itu - ruang yang penuh sesak dan jumlah pertanyaan setelah pidato mengkonfirmasi hal ini. Agar tidak menunggu rekaman video, saya memutuskan untuk membuat artikel dengan transkrip pidato.
Apa yang akan saya katakan
- Mengapa dan mengapa saya harus beralih ke Aktivitas Tunggal
- Pendekatan universal untuk menyelesaikan tugas yang biasa Anda selesaikan pada beberapa Kegiatan
- Contoh tugas bisnis standar
- Kemacetan di mana kode biasanya disangga alih-alih melakukan semuanya dengan jujur
Mengapa Kegiatan Tunggal Benar?
Siklus hidup
Semua pengembang android mengetahui skema mulai dingin dari aplikasi. Pertama, onCreate dipanggil pada kelas Aplikasi, kemudian siklus hidup Aktivitas pertama mulai berlaku.
Jika ada beberapa Aktivitas dalam aplikasi kita (dan ada sebagian besar aplikasi semacam itu), berikut ini terjadi:
App.onCreate() ActivityA.onCreate() ActivityA.onStart() ActivityA.onResume() ActivityA.onPause() ActivityB.onCreate() ActivityB.onStart() ActivityB.onResume() ActivityA.onStop()
Ini adalah aktivitas abstrakB log peluncuran dari ActivityA. Baris kosong adalah saat ketika peluncuran layar baru dipanggil. Sekilas, semuanya baik-baik saja. Tetapi jika kita beralih ke dokumentasi, menjadi jelas: untuk memastikan bahwa layar terlihat oleh pengguna dan bahwa dia dapat berinteraksi dengannya, itu hanya mungkin setelah memanggil onResume di setiap layar:
App.onCreate() ActivityA.onCreate() ActivityA.onStart() ActivityA.onResume() <-------- ActivityA.onPause() ActivityB.onCreate() ActivityB.onStart() ActivityB.onResume() <-------- ActivityA.onStop()
Masalahnya adalah log semacam itu tidak membantu untuk memahami siklus hidup aplikasi. Ketika pengguna masih di dalam, dan ketika dia sudah beralih ke aplikasi lain atau meminimalkan kita dan sebagainya. Dan ini diperlukan ketika kita ingin mengikat logika bisnis ke LC aplikasi, misalnya, menjaga koneksi soket saat pengguna berada dalam aplikasi dan menutupnya ketika keluar
Dalam aplikasi Aktivitas Tunggal, semuanya sederhana - Aktivitas LC menjadi aplikasi LC. Semua yang Anda butuhkan untuk logika apa pun mudah untuk mengikat ke keadaan aplikasi.
Luncurkan layar
Sebagai pengguna, saya sering menemukan fakta bahwa panggilan dari buku telepon (yang jelas merupakan peluncuran Kegiatan terpisah) tidak terjadi setelah mengklik pada kontak. Tidak jelas apa hubungannya dengan hal ini, tetapi mereka yang saya coba gagal tidak berhasil mengatakan mereka menerima panggilan dan mendengar suara langkah. Pada saat yang sama, ponsel cerdas saya sudah lama berada di saku.
Masalahnya adalah bahwa memulai suatu Aktivitas adalah proses yang sepenuhnya tidak sinkron! Tidak ada jaminan untuk memulai instan, dan lebih buruk lagi, kami tidak dapat mengontrol prosesnya. Tentu saja
Dalam aplikasi Aktivitas Tunggal, bekerja dengan manajer fragmen, kita dapat mengontrol prosesnya.
transaction.commit() - akan mengganti layar secara tidak sinkron, yang memungkinkan Anda untuk membuka atau menutup beberapa layar sekaligus.
transaction.commitNow() - mengalihkan layar secara sinkron, jika Anda tidak perlu menambahkannya ke tumpukan.
fragmentManager.executePendingTransactions () `memungkinkan Anda untuk melakukan semua transaksi yang diluncurkan sebelumnya sekarang.
Analisis tumpukan layar
Bayangkan bahwa logika bisnis aplikasi Anda bergantung pada kedalaman tumpukan layar saat ini (misalnya, pembatasan bersarang). Atau, pada akhir beberapa proses, Anda harus kembali ke layar tertentu, dan jika ada beberapa yang identik, ke yang paling dekat dengan root (awal rantai).
Bagaimana cara mendapatkan setumpuk Aktivitas? Parameter apa yang harus ditentukan saat memulai layar?
Omong-omong, tentang keajaiban opsi peluncuran Aktivitas:
- Anda dapat menentukan bendera peluncuran di Intent (dan juga mencampurnya bersama-sama, dan mengubahnya dari tempat yang berbeda);
- Anda dapat menambahkan parameter peluncuran di manifes, karena semua Kegiatan harus dijelaskan di sana;
- tambahkan filter Intent di sini untuk menangani pemicu eksternal;
- dan akhirnya pikirkan MultiTasks, ketika Activities dapat berjalan di "tugas" yang berbeda.
Bersama-sama, ini menciptakan kebingungan dan masalah dengan debugging dukungan. Anda tidak pernah bisa mengatakan dengan pasti bagaimana layar diluncurkan, dan bagaimana hal itu memengaruhi tumpukan.
Dalam aplikasi Aktivitas Tunggal, semua layar hanya beralih melalui transaksi fragmen. Anda dapat menganalisis tumpukan layar saat ini dan transaksi tersimpan.
Dalam demo perpustakaan Cicerone , Anda dapat melihat bagaimana status tumpukan saat ini ditampilkan di bilah alat.
Catatan: di versi terbaru, perpustakaan dukungan memblokir akses ke array fragmen di dalam manajer fragmen, tetapi jika Anda benar-benar ingin, masalah ini selalu dapat diselesaikan.
Hanya satu aktivitas di layar
Dalam aplikasi nyata, kita pasti perlu menggabungkan layar "logis" dalam satu Aktivitas, maka Anda tidak dapat menulis aplikasi HANYA di Aktivitas. Dualitas dari pendekatan itu selalu buruk, karena masalah yang sama dapat diselesaikan dengan cara yang berbeda (di suatu tempat, tata letaknya secara langsung dalam Kegiatan, dan di suatu tempat, Kegiatan itu hanya sebuah wadah).
Jangan terus beraktifitas
Bendera untuk pengujian ini benar-benar memungkinkan Anda menemukan beberapa bug dalam aplikasi, tetapi perilaku yang dihasilkannya TIDAK PERNAH terjadi pada kenyataannya! Itu tidak terjadi bahwa proses aplikasi tetap, dan pada saat itu Aktivitas, meskipun tidak aktif, mati! Aktivitas hanya bisa mati dengan proses aplikasi. Jika aplikasi ditampilkan kepada pengguna, dan sistem tidak memiliki sumber daya yang cukup, semua yang ada di sekitar akan mati (aplikasi tidak aktif lainnya, layanan, dan bahkan peluncur), dan aplikasi Anda akan hidup sampai akhir yang pahit, dan jika harus mati, maka itu akan menjadi seluruhnya.
Anda bisa mengeceknya.
Warisan
Secara historis, ada sejumlah besar logika yang tidak perlu dalam Aktivitas yang kemungkinan besar tidak berguna bagi Anda. Misalnya, semua yang Anda butuhkan untuk bekerja dengan loaders , actionBar , action menu dan sebagainya. Ini membuat kelas itu sendiri cukup besar dan berat.
Animasi
Mungkin, siapa pun dapat membuat animasi pergeseran sederhana saat beralih di antara Aktivitas. Di sini perlu diperjelas bahwa Anda perlu membuat diskon pada sinkronisasi Sinkronisasi dari aktivitas, yang telah kita bicarakan sebelumnya.
Jika Anda membutuhkan sesuatu yang lebih menarik, Anda dapat mengingat contoh animasi transisi yang dibuat di Activity:
Tetapi ada masalah besar: menyesuaikan animasi ini hampir tidak mungkin. Ini tidak mungkin menyenangkan para desainer dan pelanggan.
Dengan fragmen, semuanya berbeda. Kita dapat langsung menuju ke tingkat hierarki tampilan dan membuat animasi apa pun yang dapat Anda bayangkan! Bukti langsung di sini :
Jika Anda melihat kode sumber, Anda akan menemukan bahwa ini dilakukan pada tata letak biasa. Ya, kodenya layak di sana, tetapi animasi selalu cukup sulit, dan memiliki kesempatan seperti itu selalu merupakan nilai tambah. Jika Anda memiliki dua Kegiatan yang diaktifkan, maka aplikasi tidak memiliki wadah umum tempat Anda dapat melakukan transisi tersebut.
Ubah konfigurasi dengan cepat
Poin ini tidak dalam pidato saya, tetapi juga sangat penting. Jika Anda memiliki fitur dengan mengalihkan bahasa di dalam aplikasi, maka dengan beberapa Kegiatan akan cukup bermasalah untuk mengimplementasikannya, jika, antara lain, Anda tidak perlu memulai ulang aplikasi, tetapi tetap di tempat yang sama di mana pengguna pada saat memanggil fungsi.
Dalam aplikasi Aktivitas Tunggal, cukup mengubah lokal yang dipasang dalam konteks aplikasi dan memanggil recreate() pada Aktivitas, seluruh sistem akan melakukan semuanya sendiri.
Pada akhirnya
Google memiliki solusi navigasi, dokumentasi yang secara eksplisit menyatakan bahwa disarankan untuk menulis aplikasi Aktivitas Tunggal.
Pada titik ini, saya harap Anda tidak ragu bahwa pendekatan klasik dengan beberapa Kegiatan berisi sejumlah kekurangan, yang biasanya menutup mata, bersembunyi di balik tren umum ketidakpuasan Android.
Jika demikian, mengapa Single-Activity belum menjadi standar pengembangan?
Di sini saya akan mengutip teman baik saya:
Memulai proyek serius baru, pimpinan apa pun takut untuk melakukan kesalahan dan menghindari keputusan yang berisiko. Ini benar Tetapi saya akan mencoba memberikan rencana komprehensif untuk transisi ke Kegiatan Tunggal.
Beralih ke Aktivitas Tunggal
Jika Anda mempelajari aplikasi ini, Anda dapat menentukan dari animasi karakteristik dan perilaku yang tertulis di beberapa Kegiatan. Saya bisa saja salah, dan semuanya dilakukan bahkan pada tampilan kustom, tetapi ini tidak akan mempengaruhi alasan kami.
Sekarang perhatian! Kami melakukannya seperti ini:
Kami hanya membuat dua perubahan: kami menambahkan kelas AppActivity dan mengganti semua Kegiatan dengan FlowFragment. Pertimbangkan setiap perubahan lebih terinci.
Apa yang ditanggung oleh AppActivity untuk:
- hanya berisi wadah untuk fragmen
- adalah titik inisialisasi objek Lingkup UI (dulu dilakukan dalam Aplikasi, yang salah, karena, misalnya, objek Layanan dalam aplikasi kita pasti tidak memerlukan objek seperti itu)
- adalah penyedia aplikasi
- membawa semua manfaat Aktivitas Tunggal.
Apa itu FlowFragment :
- melakukan hal yang persis sama dengan Kegiatan, alih-alih yang dibuat.
Navigasi baru
Perbedaan utama dari pendekatan lama adalah navigasi.
Sebelumnya, pengembang punya pilihan: meluncurkan Aktivitas baru atau transaksi fragmen di saat ini. Pilihannya belum hilang, tetapi metode telah berubah - sekarang kita perlu memutuskan apakah akan memulai fragmentasi fragmen di AppActivity atau di dalam FlowFragment saat ini.
Begitu pula dengan pemrosesan tombol Back. Sebelumnya, Kegiatan meneruskan acara ke fragmen saat ini, dan jika tidak memprosesnya, ia membuat keputusan sendiri. Sekarang AppActivity meneruskan acara ke FlowFragment saat ini, dan itu, pada gilirannya, meneruskannya ke fragmen saat ini.
Mentransfer hasil antar layar
Untuk pengembang yang tidak berpengalaman, masalah mentransfer data antar layar adalah masalah utama dari pendekatan baru, karena sebelumnya dimungkinkan untuk menggunakan fungsionalitas startActivityForResult ()!
Bukan tahun pertama, berbagai pendekatan arsitektur untuk menulis aplikasi telah dibahas. Tugas utama pada saat yang sama tetap pemisahan UI dan lapisan data dan logika bisnis. Dari sudut pandang ini, startActivityForResult () memecah kanon, karena data antara layar dari satu aplikasi ditransmisikan pada sisi entitas dari lapisan UI. Saya menekankan bahwa ini hanya satu aplikasi, karena kami memiliki lapisan data umum, model umum dalam lingkup global, dan sebagainya. Kami tidak menggunakan peluang ini dan mengarahkan diri kami ke dalam kerangka satu Bundel (serialisasi, ukuran, dan lainnya).
Saran saya : jangan gunakan startActivityForResult () di dalam aplikasi! Gunakan hanya untuk tujuan yang dimaksudkan - untuk menjalankan aplikasi eksternal dan mendapatkan hasil darinya.
Lalu bagaimana cara meluncurkan layar dengan pilihan untuk layar lain? Ada tiga opsi:
- Targetfragment
- Eventbus
- model jet
TargetFragment - opsi "out of the box", tetapi transfer data yang sama di sisi lapisan UI. Opsi yang salah.
EventBus - jika Anda dapat menyetujui tim dan - yang paling penting - mengontrol pengaturan, maka Anda dapat mengimplementasikan transfer data antar layar pada bus data global. Tetapi karena ini adalah langkah berbahaya, kesimpulannya adalah opsi yang buruk.
Model reaktif - pendekatan ini menyiratkan adanya panggilan balik dan banyak lagi. Bagaimana Anda menerapkannya diputuskan oleh tim dari setiap proyek. Tetapi pendekatan ini optimal, karena memberikan kontrol atas apa yang terjadi dan tidak memungkinkan kode untuk digunakan untuk tujuan lain. Pilihan kita!
Ringkasan
Saya suka pendekatan baru ketika mereka sederhana dan memiliki manfaat yang jelas. Saya harap ini adalah kasusnya. Manfaatnya dijelaskan pada bagian pertama, dan Anda harus menilai kesulitannya. Sudah cukup untuk mengganti semua Kegiatan dengan FlowFragment, menjaga semua logikanya tidak berubah. Ubah sedikit kode navigasi dan pikirkan untuk bekerja dengan transfer data antar layar, jika belum dilakukan.
Untuk menunjukkan kesederhanaan pendekatannya, saya sendiri mengalihkan aplikasi terbuka ke Aktivitas Tunggal, dan hanya butuh beberapa jam (tentu saja, layak untuk mempertimbangkan bahwa ini bukan warisan kuno, dan semuanya kurang lebih baik dengan arsitektur di sana).
Apa yang terjadi
Mari kita lihat bagaimana menyelesaikan masalah standar dalam pendekatan baru.
BottomNavigationBar dan NavigationDrawer
Menggunakan aturan sederhana yang kami ganti semua Kegiatan dengan FlowFragment, menu samping sekarang akan berada di beberapa fragmen dan beralih fragmen bersarang di dalamnya:
Mirip dengan BottomNavigationBar.
Jauh lebih menarik bahwa kita dapat menginvestasikan beberapa FlowFragment pada yang lain, karena ini masih merupakan fragmen biasa!
Opsi ini dapat ditemukan di GitFox .
Ini adalah kemungkinan hanya dengan menggabungkan beberapa fragmen di dalam yang lain yang memungkinkan untuk membuat UI dinamis untuk perangkat yang berbeda tanpa masalah: tablet + smartphone.
Lingkup DI
Jika Anda memiliki aliran pembelian produk dari beberapa layar, dan Anda perlu menunjukkan nama produk di setiap layar, Anda mungkin sudah memasukkan ini ke dalam Kegiatan terpisah yang menyimpan produk dan menyediakannya ke layar.
Ini akan sama dengan FlowFragment - ini akan berisi skala DI dengan model untuk semua layar bersarang. Pendekatan ini menghilangkan kontrol rumit dari masa hidup lingkup dengan mengikatnya ke masa hidup FlowFragment.
Tautan dalam
Jika Anda menggunakan filter dalam manifes untuk meluncurkan layar spesifik pada tautan dalam, Anda mungkin memiliki masalah dalam memulai Kegiatan, yang saya tulis di bagian pertama. Dalam pendekatan baru, semua tautan dalam masuk ke AppActivity.onNewIntent. Selanjutnya, menurut data yang diperoleh, ada transisi ke layar yang diperlukan (atau rantai layar. Saya mengusulkan untuk melihat fungsi seperti itu di Chicheron ).
Proses kematian
Jika aplikasi ditulis pada beberapa Aktivitas, Anda harus tahu bahwa ketika aplikasi mati, dan kemudian ketika proses dikembalikan, pengguna akan berada di Aktivitas terakhir, dan semua yang sebelumnya akan dipulihkan hanya ketika mereka dikembalikan kepada mereka.
Jika Anda tidak mempertimbangkan ini sebelumnya, masalah mungkin timbul. Misalnya, jika ruang lingkup yang diperlukan pada Aktivitas terakhir dibuka pada sebelumnya, tidak ada yang akan membuatnya kembali. Apa yang harus dilakukan Bawa ini ke kelas Aplikasi? Apakah banyak titik membuka lingkup?
Semuanya lebih sederhana dengan fragmen, karena mereka berada di dalam suatu Kegiatan atau FlowFragment lain, dan wadah apa pun akan dipulihkan SEBELUM membuat ulang fragmen.
Kita dapat membahas tugas-tugas praktis lainnya dalam komentar, karena kalau tidak, ada kemungkinan bahwa artikel tersebut akan menjadi terlalu banyak.
Dan sekarang bagian yang paling menarik.
Kemacetan (Anda perlu mengingat dan berpikir).
Berikut ini dikumpulkan hal-hal penting yang harus Anda pikirkan dalam proyek apa pun, tetapi semua orang terbiasa "merobeknya" dalam proyek pada beberapa Kegiatan sehingga perlu diingat kembali dan diceritakan bagaimana menyelesaikannya dengan benar dalam pendekatan baru. Dan pertama dalam daftar
Rotasi layar
Itu adalah kisah yang paling mengerikan bagi penggemar rengekan bahwa Android menciptakan kembali Aktivitas ketika layar diputar. Metode solusi yang paling populer adalah untuk memperbaiki orientasi potret. Selain itu, proposal ini tidak lagi dibuat oleh pengembang, tetapi oleh manajer yang takut dengan frasa seperti " mempertahankan belokan sangat sulit dan biaya beberapa kali lebih banyak ."
Kami tidak akan berdebat tentang kebenaran keputusan semacam itu. Hal lain yang penting: memperbaiki rotasi tidak dibebaskan dari kematian Aktivitas! Karena proses yang sama terjadi dengan banyak peristiwa lain: mode split, ketika beberapa aplikasi ditampilkan di layar, menghubungkan monitor eksternal, mengubah konfigurasi aplikasi dengan cepat dan sebagainya.
Selain itu, rotasi layar memungkinkan Anda untuk memeriksa "kekakuan" tata letak yang benar, jadi di tim St. Petersburg kami, kami tidak mematikan rotasi di semua majelis penjualan, bahkan jika itu tidak ada dalam versi rilis. Belum lagi bug khas yang masih akan ditemukan saat verifikasi.
Banyak solusi telah ditulis untuk berbelok, mulai dari Moxy dan diakhiri dengan berbagai implementasi MVVM. Buat tidak lebih sulit dari yang lainnya.
Pertimbangkan kasus menarik lainnya.
Bayangkan aplikasi katalog produk. Kami melakukannya di Aktivitas Tunggal. Di mana-mana mode potret diperbaiki, tetapi pelanggan menginginkan fitur ketika, saat melihat galeri foto, pengguna dapat menontonnya dalam orientasi lanskap. Bagaimana cara mendukung ini?
Seseorang akan menawarkan tongkat pertama :
<activity android:name=".AppActivity" android:configChanges="orientation" />
override fun onConfigurationChanged(newConfig: Configuration?) { if (newConfig?.orientation == Configuration.ORIENTATION_LANDSCAPE) {
Dengan demikian, kita tidak dapat memanggil super.onConfigurationChanged(newConfig) , tetapi memprosesnya sendiri dan hanya memutar tampilan yang diperlukan di layar.
Tetapi dengan API 23, proyek akan macet dengan SuperNotCalledException , jadi pilihan yang buruk .
Pernyataan di atas membuat kesalahan:
Saya cukup dikoreksi dalam komentar yang menambahkan android: configChanges = "orientasi | screenSize" sudah cukup, dan kemudian Anda dapat memanggil super dan Kegiatan tidak akan dibuat kembali setelah rotasi. Berguna untuk menggunakannya saat WebView atau peta ada di layar yang membutuhkan waktu lama untuk diinisialisasi, dan Anda ingin menghindarinya.
Ini akan membantu untuk menyelesaikan kasus yang dijelaskan dengan galeri, tetapi pesan utama dari bagian ini: jangan mengabaikan rekreasi Aktivitas , ini dapat terjadi dalam banyak kasus lainnya.
Seseorang mungkin menyarankan solusi lain:
<activity android:name=".AppActivity" android:screenOrientation="portrait" /> <activity android:name=".RotateActivity" />
Tetapi dengan cara ini kita menjauh dari pendekatan Aktivitas Tunggal untuk memecahkan masalah sederhana dan menghilangkan semua manfaat dari pendekatan itu. Ini adalah penopang, dan penopang selalu merupakan pilihan yang buruk .
Inilah solusi yang tepat:
<activity android:name=".AppActivity" android:configChanges="orientation" />
override fun onResume() { super.onResume() activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_SENSOR } override fun onPause() { super.onPause() activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT }
Yaitu, ketika fragmen dibuka, aplikasi mulai "berputar", dan ketika kembali, itu diperbaiki lagi. Dalam pengalaman saya , ini adalah cara kerja aplikasi AirBnB . Jika Anda membuka tampilan foto perumahan, pemrosesan giliran diaktifkan, tetapi dalam orientasi lanskap, Anda dapat menarik foto ke bawah untuk keluar dari galeri. Di bawahnya, layar sebelumnya akan terlihat dalam orientasi lansekap, yang biasanya tidak akan Anda temukan, karena segera setelah meninggalkan galeri layar akan berubah menjadi potret dan diperbaiki.
Di sinilah persiapan tepat waktu untuk pergantian layar akan membantu.
Bilah status transparan
Hanya Aktivitas yang dapat bekerja dengan bilah sistem, tetapi sekarang kami hanya memiliki satu, jadi Anda harus selalu menentukan
<item name="android:windowTranslucentStatus">true</item>
Tetapi pada beberapa layar tidak perlu "merangkak" di bawahnya, dan Anda perlu menampilkan semua konten di bawah ini. Bendera datang untuk menyelamatkan
android:fitsSystemWindows="true"
yang menunjukkan tata letak yang tidak boleh Anda gambar di bawah bilah sistem. Tetapi jika Anda menentukannya di tata letak fragmen, dan kemudian mencoba untuk menampilkan fragmen melalui transaksi di manajer fragmen, maka Anda akan kecewa ... itu tidak akan berhasil!
Jawabannya cepat google
Saya sangat menyarankan Anda membiasakan diri dengan jawaban yang sangat komprehensif dan banyak tautan bermanfaat.
Solusi cepat dan berfungsi ( tetapi bukan yang tepat ) adalah membungkus tata letak di CoordinatorLayout
<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" android:layout_width="match_parent" android:layout_height="match_parent" android:fitsSystemWindows="true"> </android.support.design.widget.CoordinatorLayout>
Solusi yang lebih baik membantu memproses keyboard juga.
Ubah tata letak saat keyboard muncul
Saat keyboard keluar, tata letak harus berubah sehingga elemen penting dari UI tidak tetap di luar jangkauan. Dan jika sebelumnya kita dapat menentukan mode reaksi yang berbeda untuk keyboard untuk Aktivitas yang berbeda, sekarang kita perlu melakukan ini di Aktivitas Tunggal. Karena itu perlu digunakan
android:windowSoftInputMode="adjustResize"
Jika Anda menggunakan pendekatan dari bagian sebelumnya untuk memproses bilah status transparan, Anda akan menemukan kesalahan yang tidak menguntungkan: jika sebuah fragmen berhasil dirayapi di bawah bilah status, maka ketika keyboard muncul, itu akan menyusut di atas dan di bawah, karena bilah status dan keyboard di dalam sistem bekerja melalui SystemWindows .
Perhatikan judulnya
Apa yang harus dilakukan Baca dokumentasinya!Dan pastikan untuk melihat Chris Banes berbicara tentang WindowInsets .
Menggunakan WindowInsets akan memungkinkan
- cari tahu tinggi status bar yang benar (dan bukan hardcode 51dp)
- menyiapkan aplikasi untuk setiap guntingan di layar smartphone baru
- cari tahu ketinggian keyboard (nyata!)
- Menerima acara dan merespons tampilan keyboard.
Semua orang belajar WindowInsets!
Layar splash
Jika orang lain tidak mengetahui, maka layar Splash kanonik bukanlah layar pertama dalam aplikasi yang memuat data, tetapi apa yang dilihat pengguna saat startup hingga konten Aktivitas memiliki waktu untuk dirender. Ada banyak artikel tentang hal ini.
, Single-Activity, Splash screen. , deep-link Splash screen .
, , , .
, . Single-Activity. - , , .
...
Intent, , ...
Apa selanjutnya :
, . ? — «» «» .
Apa yang harus dilakukan , .
Activity!
, : , — .
— , ( Activity), .
Activity — . Activity, . .
Kesimpulan
() , Activity, Android-. , .
: Google . — , , Activity .
, , , ! Terima kasih