Meskipun aplikasi Anda cepat dan responsif, keputusan desain tertentu masih dapat menyebabkan masalah bagi pengguna — karena interaksi yang tidak direncanakan dengan aplikasi atau dialog lain, kehilangan data secara tidak sengaja, pemblokiran yang tidak diinginkan, dan sebagainya. Untuk menghindari masalah ini, sebaiknya pahami konteks tempat aplikasi berjalan dan interaksi sistem yang dapat memengaruhi aplikasi Anda. Singkatnya, Anda harus berusaha mengembangkan aplikasi yang berinteraksi lancar dengan sistem dan aplikasi lain.
Masalah kelancaran umum adalah saat proses latar belakang aplikasi — misalnya, layanan atau penerima siaran — memunculkan dialog sebagai respons terhadap beberapa peristiwa. Perilaku ini mungkin tampak seperti tidak berbahaya, terutama ketika Anda mem-build dan menguji aplikasi secara terpisah, pada emulator. Namun, saat aplikasi dijalankan di perangkat yang sebenarnya, aplikasi Anda mungkin tidak mendapatkan fokus pengguna saat proses latar belakang menampilkan dialog. Jadi, aplikasi mungkin saja akan menampilkan dialog di belakang aplikasi yang aktif, atau mengambil fokus dari aplikasi saat ini dan menampilkan dialog di depan hal yang sedang dilakukan pengguna (misalnya, menelepon panggilan telepon). Perilaku itu tidak akan berfungsi untuk aplikasi Anda atau pengguna.
Untuk menghindari masalah ini, aplikasi Anda harus menggunakan fasilitas sistem
yang tepat untuk memberi tahu pengguna — class
Notification. Dengan
notifikasi, aplikasi Anda dapat memberi sinyal kepada pengguna bahwa suatu peristiwa telah
terjadi, dengan menampilkan ikon di status bar, bukan mengambil
fokus dan mengganggu pengguna.
Contoh lain dari masalah kelancaran adalah saat aktivitas secara tidak sengaja kehilangan status atau data pengguna karena tidak menerapkan metode onPause() dan metode siklus proses lainnya dengan benar. Atau, jika aplikasi Anda mengekspos data yang ingin digunakan oleh aplikasi lain, Anda harus mengeksposnya melalui ContentProvider, bukan (misalnya) melakukannya melalui database atau file mentah yang dapat dibaca di seluruh dunia.
Kesamaan dari contoh-contoh tersebut adalah terkait kerja sama yang baik dengan sistem dan aplikasi lainnya. Sistem Android dirancang untuk memperlakukan aplikasi sebagai semacam federasi komponen yang dikaitkan secara longgar, bukan bagian kode black-box. Hal ini memungkinkan Anda sebagai developer untuk melihat keseluruhan sistem hanya sebagai gabungan yang lebih besar dari komponen-komponen ini. Hal ini menguntungkan Anda dengan memungkinkan Anda berintegrasi secara rapi dan lancar dengan aplikasi lain, sehingga Anda harus mendesain kode sendiri sebagai balasannya.
Dokumen ini membahas masalah kelancaran umum dan cara menghindarinya.
Jangan melepaskan data
Selalu ingat bahwa Android adalah platform seluler. Mungkin terlihat jelas untuk mengatakannya, tetapi penting untuk diingat bahwa Aktivitas lain (seperti aplikasi "Panggilan Telepon Masuk") dapat muncul di Aktivitas Anda sendiri kapan saja. Ini akan memicu metode onSaveInstanceState() dan onPause(), dan kemungkinan akan mengakibatkan aplikasi Anda dimatikan.
Jika pengguna mengedit data dalam aplikasi Anda saat Aktivitas lain muncul, aplikasi kemungkinan akan kehilangan data tersebut saat aplikasi dimatikan. Kecuali, tentu saja, jika Anda menyimpan pekerjaan dalam proses terlebih dahulu. "Cara Android" adalah untuk melakukannya: Aplikasi Android yang menerima atau mengedit input harus mengganti metode onSaveInstanceState() dan menyimpan statusnya dalam mode yang sesuai. Saat pengguna mengunjungi kembali aplikasi, seharusnya dia dapat mengambil datanya.
Contoh klasik dari pemanfaatan hal ini adalah aplikasi email. Jika pengguna menulis email saat Aktivitas lain dimulai, aplikasi akan menyimpan email dalam proses sebagai draf.
Jangan mengekspos data mentah
Jika Anda tidak mau berjalan di jalan dengan mengenakan pakaian dalam, begitu pula data Anda. Meskipun mungkin untuk mengekspos jenis aplikasi tertentu ke seluruh dunia untuk dibaca, ini biasanya bukan ide terbaik. Mengekspos data mentah memerlukan aplikasi lain untuk memahami format data; jika Anda mengubah format tersebut, Anda akan merusak aplikasi lain yang tidak diupdate serupa.
"Cara Android" adalah membuat ContentProvider untuk mengekspos data Anda ke aplikasi lain melalui API yang bersih, dirancang dengan baik, dan mudah dikelola. Menggunakan ContentProvider sama seperti menyisipkan antarmuka bahasa Java untuk memisahkan dan melakukan komponen pada dua bagian kode yang dikaitkan dengan erat. Artinya, Anda dapat mengubah format internal data tanpa mengubah antarmuka yang diekspos oleh ContentProvider, dan hal ini tanpa memengaruhi aplikasi lain.
Jangan ganggu pengguna
Jika pengguna menjalankan aplikasi (seperti aplikasi Telepon selama panggilan), kemungkinan besar dia sengaja melakukannya. Oleh karena itu, Anda harus menghindari aktivitas memunculkan kecuali dalam merespons langsung input pengguna dari Aktivitas saat ini.
Artinya, jangan panggil startActivity() dari BroadcastReceivers atau Layanan yang berjalan di latar belakang. Tindakan ini akan mengganggu aplikasi apa pun yang sedang berjalan, dan akan membuat pengguna kesal. Mungkin lebih buruk lagi, Aktivitas Anda dapat menjadi "bandit tombol" dan menerima beberapa input yang tengah diberikan pengguna ke Aktivitas sebelumnya. Bergantung pada apa yang dilakukan aplikasi Anda, ini bisa menjadi kabar buruk.
Daripada memunculkan UI Aktivitas langsung dari latar belakang, Anda harus menggunakan NotificationManager untuk menyetel Notifikasi. Ini akan muncul di status bar, dan pengguna kemudian dapat mengkliknya di waktu luang, untuk melihat apa yang harus ditunjukkan aplikasi Anda kepadanya.
(Perhatikan bahwa semua ini tidak berlaku untuk kasus ketika Aktivitas Anda sudah ada di latar depan: dalam hal ini, pengguna berharap melihat Aktivitas berikutnya sebagai respons terhadap input.)
Banyak yang harus dilakukan? Lakukan dalam thread
Jika aplikasi Anda perlu menjalankan komputasi yang mahal atau berjalan lama, Anda mungkin harus memindahkannya ke thread. Hal ini akan mencegah dialog "Aplikasi Tidak Merespons" yang ditakuti ditampilkan kepada pengguna, dan hasil akhirnya adalah penghentian aplikasi Anda yang sangat hebat.
Secara default, semua kode dalam Aktivitas serta semua View-nya berjalan di thread yang sama. Ini adalah thread yang sama yang juga menangani peristiwa UI. Misalnya, saat pengguna menekan tombol, peristiwa tombol ke bawah akan ditambahkan ke antrean thread utama Aktivitas. Sistem pengendali peristiwa perlu melakukan dequeue dan menangani peristiwa tersebut dengan cepat; jika tidak, sistem akan menutup setelah beberapa detik aplikasi digantung dan menawarkan untuk mematikannya bagi pengguna.
Jika Anda memiliki kode yang berjalan lama, menjalankannya secara inline di Aktivitas akan menjalankannya di thread pengendali peristiwa, yang secara efektif memblokir pengendali peristiwa. Tindakan ini akan menunda pemrosesan input, dan menghasilkan dialog ANR. Untuk menghindarinya, pindahkan komputasi Anda ke thread. Dokumen Desain untuk Responsivitas ini membahas cara melakukannya..
Jangan membebani layar aktivitas tunggal
Aplikasi apa pun yang layak digunakan mungkin akan memiliki beberapa layar yang berbeda. Saat mendesain layar UI, pastikan Anda menggunakan beberapa instance objek Aktivitas.
Bergantung pada latar belakang pengembangan, Anda dapat menafsirkan Activity sebagai mirip dengan Java Applet, karena itu merupakan titik entri untuk aplikasi Anda. Namun, itu tidak cukup akurat: jika subclass Applet adalah titik masuk tunggal untuk Java Applet, Aktivitas harus dianggap sebagai salah satu kemungkinan beberapa titik entri ke aplikasi Anda. Satu-satunya perbedaan antara Aktivitas "utama" dan aktivitas lainnya yang mungkin Anda miliki adalah bahwa aktivitas "utama" kebetulan menjadi satu-satunya yang menunjukkan minat pada tindakan "android.intent.action.MAIN" di file AndroidManifest..xml.
Jadi, saat mendesain aplikasi, anggap aplikasi Anda sebagai federasi objek Aktivitas. Hal ini akan membuat kode Anda lebih mudah dikelola dalam jangka panjang, dan sebagai efek samping yang baik, kode Anda juga akan berfungsi baik dengan histori aplikasi Android dan model "backstack".
Memperluas tema sistem
Dalam hal tampilan dan nuansa antarmuka pengguna, penting untuk membaur dengan baik. Pengguna akan dikejutkan oleh aplikasi yang kontras dengan antarmuka pengguna yang mereka harapkan. Saat mendesain UI, Anda harus mencoba dan menghindari meluncurkan UI Anda sendiri sebanyak mungkin. Sebagai gantinya, gunakan Tema. Anda dapat mengganti atau memperluas bagian tema yang diperlukan, tetapi setidaknya Anda mulai dari basis UI yang sama dengan semua aplikasi lainnya. Untuk semua detailnya, baca Gaya dan Tema.
Desain UI Anda agar berfungsi dengan beberapa resolusi layar
Berbagai perangkat Android akan mendukung resolusi layar yang berbeda. Beberapa di antaranya bahkan dapat mengubah resolusi dengan cepat, misalnya dengan beralih ke mode lanskap. Penting untuk memastikan tata letak dan drawable Anda cukup fleksibel untuk ditampilkan dengan benar di berbagai layar perangkat.
Untungnya, hal ini sangat mudah dilakukan. Singkatnya, yang harus Anda lakukan adalah menyediakan berbagai versi ilustrasi (jika Anda menggunakannya) untuk resolusi utama, lalu mendesain tata letak untuk mengakomodasi berbagai dimensi. (Misalnya, hindari penggunaan posisi hard code dan gunakan tata letak relatif.) Jika Anda melakukan banyak hal, sistem akan menangani sisanya, dan aplikasi Anda akan terlihat bagus di perangkat apa pun.
Anggap jaringan berjalan lambat
Perangkat Android akan hadir dengan berbagai opsi konektivitas jaringan. Semuanya akan memiliki beberapa penyediaan akses data, meskipun beberapa akan lebih cepat daripada yang lain. Namun, denominator umum terendah adalah GPRS, layanan data non-3G untuk jaringan GSM. Bahkan perangkat yang mendukung 3G akan menghabiskan banyak waktu di jaringan non-3G, sehingga jaringan yang lambat akan tetap menjadi kenyataan untuk waktu yang cukup lama.
Karena itu, Anda harus selalu membuat kode aplikasi untuk meminimalkan akses jaringan dan bandwidth. Anda tidak dapat menganggap jaringan itu cepat, jadi Anda harus selalu merencanakannya agar lambat. Jika pengguna Anda berada di jaringan yang lebih cepat, itu bagus — pengalaman mereka hanya akan meningkat. Namun, Anda perlu menghindari kebalikannya: aplikasi yang dapat digunakan sepanjang waktu, tetapi yang dengan frustrasi memperlambat sisanya berdasarkan posisi pengguna pada suatu saat mungkin tidak populer.
Salah satu potensi yang bisa ditemukan di sini adalah sangat mudah terjebak dalam perangkap ini jika Anda menggunakan emulator, karena emulator menggunakan koneksi jaringan komputer desktop. Hal itu hampir dijamin akan jauh lebih cepat daripada jaringan seluler, jadi Anda dapat mengubah setelan pada emulator yang menyimulasikan kecepatan jaringan yang lebih lambat. Anda dapat melakukannya di Android Studio melalui AVD Manager atau melalui opsi command line saat memulai emulator.
Jangan asumsikan layar sentuh atau keyboard
Android akan mendukung berbagai faktor bentuk handset. Ini adalah cara yang elegan untuk mengatakan bahwa beberapa perangkat Android akan memiliki keyboard "QWERTY" lengkap, sementara yang lain akan memiliki konfigurasi 40 tombol, 12 tombol, atau bahkan tombol lainnya. Demikian pula, beberapa perangkat memiliki layar sentuh, tetapi banyak yang tidak.
Saat membuat aplikasi, ingat hal ini. Jangan membuat asumsi tentang tata letak keyboard tertentu -- kecuali, tentu saja, Anda benar-benar tertarik untuk membatasi aplikasi Anda agar hanya dapat digunakan di perangkat tersebut.
Hematlah baterai perangkat
Perangkat seluler tidak terlalu sering digunakan untuk terhubung ke dinding. Perangkat seluler menggunakan daya baterai, dan semakin lama kita dapat membuat baterai tersebut bertahan saat diisi daya, semakin bahagia semua orang — terutama pengguna. Dua konsumen terbesar daya baterai adalah prosesor dan radio; itulah sebabnya penting untuk menulis aplikasi Anda agar dapat melakukan pekerjaan sesedikit mungkin, dan menggunakan jaringan sesering mungkin.
Meminimalkan jumlah waktu prosesor yang digunakan aplikasi Anda benar-benar berkaitan dengan menulis kode yang efisien. Untuk meminimalkan konsumsi daya dari penggunaan radio, pastikan untuk menangani kondisi error dengan baik, dan hanya ambil yang Anda butuhkan. Misalnya, jangan terus-menerus mencoba kembali operasi jaringan jika gagal. Jika gagal sekali, kemungkinan karena pengguna tidak memiliki penerimaan, jadi mungkin akan gagal lagi jika Anda langsung mencobanya; yang akan Anda lakukan hanyalah membuang daya baterai.
Pengguna cukup cerdas: jika program Anda boros listrik, Anda bisa mengandalkan mereka memperhatikannya. Satu-satunya hal yang dapat Anda pastikan pada saat itu adalah program Anda tidak akan tetap terinstal dalam waktu lama.