Apakah ada kesepakatan tentang cara memberi nama sumber daya?

Apakah ada konvensi bagaimana memberi nama sumber daya di Android? Misalnya, tombol, tampilan teks, menu, dll.

Saya tidak tahu apakah ada rekomendasi resmi.

Untuk id di tata letak saya dengan widget dan penampung, saya menggunakan konvensi:

<layout>_<widget/container>_<name>

Saya melakukan strategi yang sama untuk dimens, string, angka, dan warna yang saya gunakan dalam tata letak tersebut. Namun, saya mencoba menggeneralisasi. misalnya jika semua tombol memiliki textColor yang sama, saya tidak akan memberi awalan nama dengan tata letak. Nama sumber daya akan menjadi 'button_textColor'. Jika semua textColors menggunakan sumber daya yang sama, itu akan dinamai 'textColor'. Untuk Styles, ini biasanya juga terjadi.

Untuk sumber menu yang saya gunakan:

menu_<activity>_<name>

Animasi hanya berbeda karena Anda tidak dapat menggunakan huruf besar. Hal yang sama berlaku untuk sumber daya xml yang dapat digambar, saya yakin.

Android SDK akan menjadi tempat yang baik untuk memulai.

Misalnya, saya mencoba untuk menjangkau ID dalam aktivitas.

Jika saya punya ListViewitu hanya akan @android:id/listdi semua kegiatan.
Namun, jika saya memiliki dua daftar maka saya akan menggunakan yang lebih spesifik @id/list_appledan@id/list_orange

Jadi generik (ids, ...) digunakan kembali R.java filesementara yang unik (kadang-kadang digunakan kembali) diawali dengan yang generik dipisahkan oleh garis bawah .

Garis bawah adalah satu hal, saya amati, misalnya:

Lebar tata letak layout_widthdalam xml dan layoutWidthdalam kode , jadi saya mencoba untuk tetap menggunakannya sebagailist_apple

Jadi tombol Login akan menjadi login, tetapi jika kita memiliki dua login maka login_foodan login_bar.

Diambil dari dokumentasi Android . Ada lebih banyak hal di sana.

Untuk menjawab pertanyaan Anda: Ya, ada.

Anda dapat menemukan banyak dari mereka melalui pencarian google misalnya. Dan tidak ada konvensi penamaan terbaik. Itu selalu tergantung pada kebutuhan Anda dan atribut proyek Anda (yang paling penting ruang lingkupnya).

Baru-baru ini, saya telah membaca postingan blog yang cukup bagus tentang penamaan resource di XML Android dari Jeroen Mols. Penulis menyebutkan prinsip dasar yang harus diikuti semua sumber daya dan kemudian bagaimana konvensi ini diterapkan pada setiap jenis sumber daya. Keduanya dijelaskan di lembar sontekan penamaan sumber daya Android :

Dia kemudian menjelaskan setiap elemen dan setiap jenis sumber daya secara mendetail.

Saya akan mengatakan Anda dapat menggunakan konvensi ini dari proyek kecil hingga menengah (penggunaan pribadi, aplikasi kontrak beberapa bulan). Meskipun, saya tidak akan merekomendasikannya untuk proyek lama dengan aktivitas seperti 50+ atau 1000+ string.

Konvensi untuk nilai sumber daya dalam proyek berskala besar membutuhkan penyelidikan lebih lanjut tentang bagaimana nilai tersebut akan digunakan. Ambil string misalnya. Mungkin dipengaruhi oleh ukuran tim Anda, pusat terjemahan yang Anda gunakan (jika ada), VCS Anda gunakan (untuk menghindari konflik penggabungan misalnya), dll. Anda bahkan mungkin berpikir untuk membagi string menjadi beberapa file.

Saya berasumsi Anda sedang mencari sesuatu untuk memulai. Jadi saya akan merekomendasikan posting blog yang saya sebutkan. Ini bagus untuk pemula dan Anda pasti bisa menggunakannya sebagai inspirasi untuk membuat konvensi penamaan yang bagus milik Anda sendiri.

Juga perlu diingat bahwa seiring dengan pertumbuhan proyek, banyak kebutuhan dan persyaratan dapat berubah seiring waktu. Jadi sangat normal bahwa konvensi penamaan yang cocok pada awalnya tidak akan cocok setelah 2 tahun. Dan itu baik-baik saja. Anda tidak boleh mencoba meramal masa depan. Pilih saja konvensi dan ikuti. Anda akan mengetahui apakah itu cocok untuk Anda dan proyek Anda. Jika tidak, pikirkan mengapa tidak cocok dan mulai gunakan yang lain.

Ada beberapa konvensi yang digunakan dalam sumber daya:

• Untuk sumber daya yang ada sebagai file terpisah, mereka harus lower_case_underscore_separated. Alat appt memastikan bahwa file Anda hanya menggunakan huruf kecil, karena menggunakan huruf besar / kecil dapat menyebabkan masalah pada sistem file yang tidak peka huruf besar / kecil.
• Untuk sumber daya yang dideklarasikan hanya dalam nilai / ... (atribut, string, dll.) Konvensi umumnya mixedCase.
• Terkadang ada konvensi yang digunakan untuk menandai nama dengan "klasifikasi" agar memiliki ruang nama yang sederhana. Ini adalah contoh saat Anda melihat hal-hal seperti layout_width dan layout_alignLeft. Dalam file tata letak, atribut untuk View dan manajemen tata letak induk dicampur bersama, meskipun mereka adalah pemilik yang berbeda. Konvensi "layout_ *" memastikan bahwa tidak ada konflik antara nama-nama ini dan mudah untuk memahami entitas mana yang terpengaruh oleh nama tersebut.

Konvensi "layout_blah" ini juga telah digunakan di beberapa tempat lain. Misalnya, ada atribut "state_blah" yang merupakan status drawable yang bisa dimiliki tampilan.

Juga karena dua konvensi ini (underscore_separated untuk file, mixedCase untuk sumber daya yang dideklarasikan), Anda akan menemukan sejumlah inkonsistensi. Misalnya warna dapat dideklarasikan dengan file atau sebagai nilai eksplisit. Umumnya kami ingin tetap menggunakan underscore_separated untuk semua itu, tetapi itu tidak selalu terjadi.

Pada akhirnya kami tidak terlalu khawatir tentang konvensi penamaan untuk sumber daya. Yang besar yang kami pertahankan konsisten adalah "mixedCase" untuk atribut, dan penggunaan "layout_blah" untuk mengidentifikasi atribut param layout.

Juga menelusuri sumber daya publik di sini harus memberikan kesan yang baik untuk konvensi:

http://developer.android.com/reference/android/R.html

Anda akan melihat semua atribut cukup konsisten (jika Anda memahami konvensi layout_), drawable semuanya underscore_separated, dll.

Ini adalah masalah umum untuk bahasa atau kerangka kerja apa pun, tetapi selama Anda menghindari kata-kata khusus, Anda akan baik-baik saja dengan asumsi Anda dapat mengingat apa yang Anda sebut sesuatu.

Saya mencatat bahwa Android menempatkan restrction pada nama file sumber daya xml tetapi garis bawah tampaknya baik-baik saja. ADT sebenarnya menyatakan

Nama sumber daya berbasis file hanya boleh berisi huruf kecil az, 0-9, atau _.

Sesuatu yang membuat saya tersandung pada awalnya adalah kurangnya ruang nama dengan id, tetapi ini umumnya dapat diabaikan jika Anda memiliki dua id dengan Android yang sama hanya akan menggunakan kembali id ​​yang ditentukan.

Untuk id, saya menggunakan qualifier 3 huruf diikuti dengan apa yang dirujuknya dalam notasi unta misalnya lblFoo untuk label teks statis (atau textview), txtFoo untuk kotak teks yang dapat diedit (teks edit di Android). Ini mungkin tampak aneh pada awalnya tetapi saya telah menggunakannya sejak VB6 dan kontrol tersebut disebut label dan kotak teks.

Berikut ini beberapa yang biasa saya gunakan:

• btnFoo - tombol
• pwdFoo - kata sandi
• lstFoo - daftar
• clrFoo - warna
• tblFoo - tabel
• colFoo - kolom
• rowFoo - baris
• imgFoo - gambar
• dimFoo - dimensi
• padFoo - padding
• mrgFoo - margin

Saya menggunakan kode yang sama dalam file java juga jadi saya tidak perlu memikirkannya, cakupan paket akan memungkinkan ini dengan cukup senang:

Button btnFoo = (Button)findViewById(R.id.btnFoo);

Anda dapat jika Anda lebih suka menambahkan sedikit jarak menggunakan garis bawah yaitu btn_foo ... Saya mungkin akan melakukan ini jika saya dapat menghentikan kebiasaan lama.

Ada orang yang mungkin berpendapat bahwa menyingkat ini mungkin tidak ideal dan para puritan akan berpendapat bahwa nama lengkap harus digunakan, tetapi ketika Anda menamai lusinan kontrol dan mengubah antara sistem dan kerangka kerja yang berbeda, nama lengkap kehilangan artinya, saya telah menggunakan ini selama lebih dari satu dekade di VB, C ++, ASP.NET, WinForms di C # dan VB.NET, Android dan Python. Saya tidak perlu mengingat apakah Android menyebutnya kotak teks atau teks editan. Yang perlu saya ketahui adalah bahwa lblFoo adalah label statis dan txtFoo adalah masukan yang diketik pengguna.

Satu catatan terakhir adalah bahwa apa pun konvensi yang Anda putuskan, hal-hal penting adalah penamaan kontrol dengan benar dan konsisten, sehingga Anda tidak bergumul dengan id default yang tidak jelas misalnya TextView5 atau campuran dari konvensi yang berbeda

Tautan yang berguna untuk desainer dan pengembang - di sini

Dimensi dan ukuran, konvensi penamaan, gaya dan tema, sembilan tambalan, dan seterusnya.

Saya rasa tidak ada konvensi standar yang dipromosikan oleh Google. Saya telah melihat berbagai cara orang memberi nama sesuatu, bahkan dalam aplikasi resmi Google yang berbeda.

Apa pun yang paling membantu Anda saat mencoba memahami 100 file tata letak (atau sumber daya yang dapat digambar, menu, dll.) Dalam satu hierarki direktori.

Jawaban singkatnya: jika Anda ingin belajar dari pengembang Android, contoh yang bagus adalah pustaka dukungan v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip )

Jika tidak, inilah yang telah saya pertimbangkan untuk menamai sumber daya:
1. menemukan sumber daya dengan mudah saat menulis kode
2. memahami sumber daya dengan mudah saat membaca kode
3. membuat nama berguna bagi penerjemah (R.string.* sumber daya saja)
4. menggunakan kembali tata letak dengan <include/>( R.id.*konflik sumber daya)
5. menangani dengan proyek perpustakaan

Secara logis, mengatur sumber daya seharusnya tidak berbeda dengan mengelompokkan kelas java ke dalam paket (atau memasukkan file ke dalam folder). Namun, karena sumber daya Android tidak memiliki ruang nama, awalan harus ditambahkan ke nama sumber daya untuk mencapai hal yang sama (misalnya com.example.myapp.photomenjadi com_example_myapp_photo).

Saya menyarankan untuk membagi aplikasi menjadi beberapa komponen terpisah (aktivitas, fragmen, dialog, dll.) Dengan nama unik pendek yang dapat digunakan sebagai awalan sumber daya. Dengan cara ini kami mengelompokkan sumber daya dengan fungsionalitas terkait bersama, yang membuatnya mudah ditemukan (poin 1) dan kami pada saat yang sama menghindari konflik penamaan dengan keduanya.<include/> dan proyek perpustakaan (poin 4 dan 5). Perhatikan bahwa sumber daya yang umum untuk beberapa komponen masih dapat memiliki awalan (seperti R.string.myapp_ok_button).

Setelah awalan, nama harus memberi tahu kami untuk apa sumber daya digunakan (tindakan yang harus dilakukan, konten yang akan ditampilkan, dll.). Memilih nama yang baik itu penting untuk pemahaman (poin 2 dan 3).

Kadang-kadang "nama_komponen" akan memberi kita informasi yang cukup, terutama jika tipe sudah diberikan oleh kelas R (di R.string.myapp_name_string"string" ke-2 adalah berlebihan). Namun, menambahkan jenis secara eksplisit dapat meningkatkan pemahaman (misalnya, dapat membantu penerjemah membedakan antara bersulang, atau label). Kadang-kadang bagian "nama" dan "jenis" dapat ditukar untuk memungkinkan pemfilteran berdasarkan jenis (hanya R.string.photo_menu_*akan memberi kita item yang berhubungan dengan menu untuk komponen foto).

Katakanlah kita sedang menulis aktivitas untuk mengambil gambar, kelas com.example.myapp.photo .PhotoActivity. Sumber daya kami dapat terlihat seperti ini (dikelompokkan berdasarkan komponen "foto"):

R.layout.photo //if only a single layout is used
R.menu.photo  
R.string.photo_capture_instructions_label  
R.id.photo_capture_instructions_label  
R.id.photo_capture_button  
R.id.photo_capture_image  
R.drawable.photo_capture_placeholder  
R.dimen.photo_capture_image_height  

Jika Anda melihat-lihat dokumentasi Android, ada berbagai penyebutan "praktik terbaik", tetapi yang pasti tidak ada aturan konkret. Misalnya, dalam Panduan Desain Ikon , Google menyarankan penamaan ikon dengan awalan "ic_".

Tempat yang baik untuk memulai mungkin Menyediakan Sumber Daya .

Gali juga di sekitar sumber / contoh SDK serta di Blog Pengembang Android jika Anda ingin melihat bagaimana pengembang Google melakukan sesuatu.

Saya menemukan konvensi penamaan berikutnya yang berguna untuk string:

[<action>]_<object>_<purpose>

Misalnya, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. Dan "tindakan" di sini bersifat opsional.

Anda dapat membaca dokumentasi google untuk gaya kode untuk mendapatkan ide di sini

Saya biasanya mengikuti konvensi penamaan java untuk id sumber daya (bukan untuk file untuk file) kecuali saya menambahkan "x" di depan id misalnya:

<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>

Di java kita bisa menggunakannya dengan sederhana (kita juga bisa mengingatnya secara sederhana)

TextView mTvName=(TextView)findViewById(R.id.xTvName);

Di sini mTvName (Ini adalah konvensi penamaan yang disarankan android secara umum) dan xTvName yang dinamai dalam file layout sebagai bagian dari Android TextView's Id (x untuk XML), saya mengikuti jenis konvensi penamaan ini untuk objek tampilan seperti Buttons dan EditText dll.

dalam XML IDS: xViewTypeSpecificName

di Java: mViewTypeSpeficName

Konvensi di atas membuat hidup saya lebih mudah saat saya membuat tata letak yang kompleks. Cobalah untuk membuat nama Anda sesingkat mungkin dan lebih baik jika nama tersebut dapat dimengerti dan bermakna bagi rekan pengembang lain (tetapi mungkin tidak setiap saat), Semoga pengalaman saya dapat membantu orang lain, saran diterima.

Dalam proyek android kami ada banyak komponen seperti tombol, label, kotak teks. Jadi nama yang sederhana seperti misalnya "nama" ini sangat membingungkan untuk mengidentifikasi "nama" adalah label atau kotak teks. Terutama itu terjadi ketika Anda mengelola proyek yang dikembangkan oleh beberapa pengembang lain.

Jadi untuk menghindari kebingungan seperti ini saya menggunakan nama berikut untuk Buttons TextBoxes atau Labels

Contoh:

 btnName
 labName
 txtName
 listName

Semoga ini bermanfaat untuk Anda.

Ada beberapa batasan:

1. Nama sumber daya harus berisi az, 0-9, _
2. Nama sumber daya harus dimulai dengan az, _

Ngomong-ngomong, lebih disarankan untuk mengikuti pedoman atau belajar dari kode standar.