Mendesain aplikasi yang memberikan pengalaman yang lancar

Meskipun aplikasi Anda cepat dan responsif, keputusan desain tertentu masih dapat menimbulkan masalah bagi pengguna, karena interaksi yang tidak terencana dengan aplikasi atau dialog lain, kehilangan data tanpa sengaja, pemblokiran yang tidak diinginkan, dan sebagainya. Untuk menghindari masalah ini, ada baiknya memahami jalannya aplikasi dan interaksi sistem yang dapat memengaruhi aplikasi Anda. Singkatnya, Anda harus berusaha mengembangkan aplikasi yang berinteraksi secara lancar dengan sistem dan aplikasi lain.

Masalah kelancaran yang umum adalah saat proses latar belakang sebuah aplikasi, misalnya penerima layanan atau siaran, memunculkan dialog sebagai tanggapan terhadap beberapa peristiwa. Ini mungkin tampak seperti perilaku yang tidak berbahaya, terutama ketika Anda sedang membuild dan menguji aplikasi Anda secara terpisah, pada emulator. Namun, saat aplikasi dijalankan di perangkat yang sebenarnya, aplikasi mungkin tidak berfokus pada pengguna saat proses latar belakang menampilkan dialog. Bisa jadi aplikasi Anda akan menampilkan dialog di belakang aplikasi yang aktif, atau dapat mengambil fokus dari aplikasi saat ini dan menampilkan dialog di depan untuk berbagai hal yang sedang dilakukan pengguna (misalnya, panggilan telepon). Perilaku tersebut tidak akan berfungsi untuk aplikasi Anda atau untuk pengguna.

Untuk menghindari masalah ini, aplikasi Anda harus menggunakan fasilitas sistem yang sesuai untuk memberi tahu pengguna, class Notification. Dengan menggunakan 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 ketika aktivitas secara tidak sengaja kehilangan status atau data pengguna karena tidak menerapkan metode onPause() dan metode lifecycle lainnya dengan benar. Atau, jika aplikasi Anda menampilkan data yang ingin digunakan oleh aplikasi lain, Anda harus memaparkannya melalui ContentProvider, bukan (misalnya) melakukannya melalui database atau file mentah yang dapat dibaca di seluruh dunia.

Apa yang sama-sama dimiliki oleh contoh-contoh tersebut adalah bahwa hal tersebut melibatkan kerja sama yang baik dengan sistem dan aplikasi lainnya. Sistem Android dirancang untuk menangani aplikasi sebagai semacam federasi dari komponen yang digabungkan secara longgar, bukan potongan kode kotak hitam. Hal ini memungkinkan Anda sebagai developer untuk melihat keseluruhan sistem hanya sebagai federasi yang lebih besar dari komponen ini. Hal ini menguntungkan Anda dengan memungkinkan integrasi secara lancar dan mulus 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. Sangat jelas untuk dikatakan, akan tetapi penting untuk diingat bahwa Aktivitas lain (seperti aplikasi "Panggilan Telepon Masuk") dapat muncul di Aktivitas Anda sendiri kapan saja. Tindakan ini akan mengaktifkan metode onSaveInstanceState() dan onPause(), dan kemungkinan akan menyebabkan aplikasi Anda terhenti.

Jika pengguna mengedit data dalam aplikasi Anda saat Aktivitas lain muncul, aplikasi Anda kemungkinan akan kehilangan data tersebut saat aplikasi Anda terhenti. Kecuali, tentu saja, jika Anda menyimpan pekerjaan dalam proses terlebih dahulu. "Cara Android" adalah dengan melakukan: Aplikasi Android yang menerima atau mengedit input harus mengganti metode onSaveInstanceState() dan menyimpan statusnya dengan cara yang sesuai. Saat pengguna mengunjungi aplikasi kembali, ia seharusnya 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 enggan berjalan di jalanan mengenakan pakaian dalam, begitu pula dengan data Anda. Meskipun mungkin untuk mengekspos jenis-jenis aplikasi tertentu ke seluruh dunia untuk dibaca, hal ini biasanya bukan ide yang terbaik. Mengekspos data mentah membutuhkan aplikasi lain untuk memahami format data; jika Anda mengubah format tersebut, Anda akan merusak aplikasi lain yang tidak diupdate dengan cara yang sama.

"Cara Android" adalah membuat ContentProvider untuk mengekspos data Anda ke aplikasi lain melalui API yang bersih, terencana, dan terpelihara. Menggunakan ContentProvider sama seperti menyisipkan antarmuka bahasa Java untuk memisahkan dan membuat komponen dari dua potongan kode yang digabungkan dengan erat. Artinya, Anda dapat mengubah format internal data tanpa mengubah antarmuka yang diekspos oleh ContentProvider, dan hal ini dilakukan tanpa memengaruhi aplikasi lain.

Jangan ganggu pengguna

Jika pengguna menjalankan aplikasi (seperti aplikasi Telepon selama panggilan berlangsung), itu adalah taruhan yang cukup aman yang sengaja dilakukan. Oleh karena itu, Anda harus menghindari aktivitas spawning kecuali dalam merespons langsung masukan pengguna dari Aktivitas saat ini.

Artinya, jangan panggil startActivity() dari BroadcastReceivers atau Layanan yang berjalan di latar belakang. Hal ini akan mengganggu aplikasi apa pun yang saat ini sedang berjalan, dan mengakibatkan pengguna kesal. Mungkin lebih buruknya, Aktivitas Anda dapat menjadi "bandit tombol" dan menerima beberapa masukan yang tengah diberikan oleh pengguna ke Aktivitas sebelumnya. Tergantung pada apa yang dilakukan aplikasi Anda, ini bisa menjadi kabar buruk.

Daripada spawning UI Aktivitas secara langsung dari latar belakang, Anda harus menggunakan NotificationManager untuk menyetel Notifikasi. Ini akan muncul di status bar, dan pengguna kemudian dapat mengkliknya saat senggang, untuk melihat apa yang harus ditunjukkan aplikasi Anda kepadanya.

(Perhatikan bahwa semua ini tidak berlaku untuk kasus jika Aktivitas Anda sudah ada di latar depan: dalam hal ini, pengguna mengharapkan untuk melihat Aktivitas berikutnya sebagai respons terhadap input.)

Banyak yang harus dilakukan? Lakukan dalam thread

Jika aplikasi Anda perlu melakukan komputasi yang mahal atau lama, Anda mungkin harus memindahkannya ke thread. Hal ini akan mencegah dialog "Aplikasi Tidak Merespons" yang ditakuti ditampilkan kepada pengguna, yang menyebabkan terhentinya aplikasi Anda secara langsung.

Secara default, semua kode dalam Aktivitas serta semua Tampilan berjalan dalam thread yang sama. Ini adalah thread yang sama yang juga menangani peristiwa UI. Misalnya, saat pengguna menekan tombol, peristiwa tahan-tombol ditambahkan ke antrean thread utama dari Aktivitas. Sistem pengendali peristiwa perlu melakukan dequeue dan menangani peristiwa tersebut dengan cepat; jika tidak, sistem akan tertutup setelah beberapa detik aplikasi digantung dan menawarkan untuk mematikannya kepada pengguna.

Jika ada kode yang berjalan lama, memprosesnya selaras dengan Aktivitas akan menjalankannya pada thread pengendali peristiwa, dan akan memblokir pengendali peristiwa secara efektif. Ini akan menunda pemrosesan input, dan menghasilkan dialog ANR. Untuk menghindari hal ini, pindahkan komputasi ke thread. Dokumen Desain Daya Respons 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.

Tergantung pada latar belakang pengembangan, Anda dapat menafsirkan Aktivitas mirip dengan sesuatu seperti Java Applet, dalam hal ini adalah titik masuk untuk aplikasi Anda. Akan tetapi, hal itu tidak cukup akurat: jika subclass Applet adalah titik masuk tunggal untuk Java Applet, Aktivitas harus dianggap sebagai salah satu kemungkinan beberapa titik masuk ke aplikasi Anda. Satu-satunya perbedaan antara Aktivitas "utama" dan aktivitas lainnya yang mungkin Anda miliki adalah bahwa "utama" kebetulan menjadi satu-satunya yang menunjukkan minat terhadap tindakan "android.intent.action.MAIN" di file xml AndroidManifest Anda.

Jadi, saat merancang 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, juga berjalan baik dengan histori aplikasi Android dan model "backstack".

Memperluas tema sistem

Berbicara tentang tampilan dan nuansa antarmuka pengguna, penting untuk berbaur dengan baik. Pengguna akan dikejutkan oleh aplikasi yang kontras dengan antarmuka pengguna yang diharapkan. Saat mendesain UI, sebaiknya coba dan hindari rolling sendiri sebanyak mungkin. Sebagai gantinya, gunakan Tema. Anda dapat mengganti atau memperluas bagian tema yang dibutuhkan, tetapi setidaknya Anda mulai dari dasar UI yang sama dengan semua aplikasi lainnya. Untuk detail selengkapnya, baca Gaya dan Tema.

Desain UI Anda agar berfungsi dengan beberapa resolusi layar

Berbagai perangkat Android akan mendukung resolusi layar yang berbeda. Beberapa bahkan dapat mengubah resolusi dengan cepat, misalnya dengan beralih ke mode lanskap. Penting untuk memastikan tata letak dan resource yang dapat digambar cukup fleksibel untuk ditampilkan dengan tepat di berbagai layar perangkat.

Untungnya, hal ini sangat mudah dilakukan. Singkatnya, yang harus Anda lakukan adalah menyediakan versi yang berbeda dari artwork Anda (jika menggunakannya) untuk resolusi utama, kemudian mendesain tata letak untuk menampung berbagai dimensi. (Misalnya, hindari penggunaan posisi hard code. Sebagai gantinya, gunakan tata letak relatif.) Jika Anda melakukan banyak hal, sistem akan menangani sisanya, dan aplikasi Anda akan berfungsi prima 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 lainnya. Namun, denominator umum terendah adalah GPRS, layanan data non-3G untuk jaringan GSM. Bahkan perangkat dengan kemampuan 3G memakan banyak waktu di jaringan non-3G, sehingga jaringan yang lambat masih nyata adanya dalam waktu yang cukup lama.

Oleh karena itu, sebaiknya selalu beri kode aplikasi Anda untuk meminimalkan akses jaringan dan bandwidth. Anda tidak dapat menganggap jaringan tersebut cepat, jadi selalu rencanakan dengan anggapan jaringan lambat. Jika pengguna Anda berada di jaringan yang lebih cepat, artinya bagus, pengalaman mereka akan meningkat. Namun, Anda ingin menghindari kebalikannya: aplikasi yang dapat berfungsi optimal sepanjang waktu, tetapi sisanya sangat lambat berdasarkan lokasi pada saat tertentu. Hal ini jarang terjadi.

Salah satu potensi yang ada di sini adalah sangat mudah terjebak dalam perangkap ini jika Anda menggunakan emulator, karena emulator menggunakan sambungan jaringan komputer desktop Anda. Kemungkinan besar akan 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. Itu adalah cara keren untuk memberi tahu bahwa beberapa perangkat Android memiliki keyboard "QWERTY" yang lengkap, sementara yang lainnya akan memiliki konfigurasi tombol 40 tombol, 12 tombol, atau bahkan tombol lainnya. Demikian pula, beberapa perangkat memiliki layar sentuh, tetapi kebanyakan tidak.

Saat membuat aplikasi, ingat hal ini. Jangan membuat asumsi tentang tata letak keyboard tertentu - kecuali, tentu saja, Anda benar-benar tertarik membatasi aplikasi Anda sehingga hanya dapat digunakan di perangkat tersebut.

Hematlah baterai perangkat

Perangkat seluler tidak dapat digunakan dengan leluasa jika terus tercolok ke dinding. Perangkat seluler menggunakan tenaga baterai, dan semakin lama kita bisa membuat baterai tidak terlalu sering diisi daya, semakin bahagia semua orang - terutama pengguna. Dua konsumen terbesar daya baterai adalah prosesor, dan radio; itulah sebabnya penting untuk menuliskan aplikasi Anda agar melakukan pekerjaan sesedikit mungkin, dan menggunakan jaringan sejarang mungkin.

Meminimalkan jumlah waktu prosesor yang digunakan aplikasi Anda benar-benar bergantung pada penulisan kode yang efisien. Untuk meminimalkan konsumsi daya dari penggunaan radio, pastikan untuk menangani kondisi error dengan aman, dan cukup 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; dengan ini Anda hanya akan menyia-nyiakan daya baterai.

Pengguna cukup cerdas: jika program Anda mengonsumsi banyak daya, pengguna dapat mengetahuinya. Satu-satunya hal yang dapat Anda pastikan saat itu adalah bahwa program Anda tidak akan tetap terinstal dalam waktu yang lama.