Czy istnieją konwencje dotyczące nazywania zasobów?

Czy istnieją konwencje dotyczące nazywania zasobów w systemie Android? Na przykład przyciski, TextViews, menu itp.

Nie wiem, czy są jakieś oficjalne zalecenia.

W przypadku identyfikatorów w moich układach z widżetami i kontenerami używam konwencji:

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

Robię tę samą strategię dla dowolnych wymiarów, ciągów, liczb i kolorów, których używam w tych układach. Jednak staram się generalizować. np. jeśli wszystkie przyciski mają wspólny textColor, nie będę poprzedzał nazwy układem. Nazwą zasobu będzie „button_textColor”. Jeśli wszystkie elementy textColors używają tego samego zasobu, zostanie on nazwany „textColor”. W przypadku stylów zwykle tak jest.

W przypadku zasobów menu, których używam:

menu_<activity>_<name>

Animacje różnią się tylko tym, że nie można używać wielkich liter. Myślę, że to samo dotyczy zasobów XML do rysowania.

Android SDK będzie dobrym miejscem do rozpoczęcia.

Na przykład próbuję określić zakres identyfikatorów w ramach działania.

Gdybym miał ListViewto po prostu byłby @android:id/listwe wszystkich działaniach.
Gdybym jednak miał dwie listy, to użyłbym bardziej szczegółowych @id/list_applei@id/list_orange

Tak więc ogólne (ids, ...) są ponownie używane, R.java filepodczas gdy unikalne (czasami są ponownie używane) są poprzedzane przedrostkami ogólnymi oddzielonymi podkreśleniem .

Podkreślenie to jedno, zauważyłem na przykład:

Układ szerokość jest layout_widthw formacie XML , a layoutWidthw kodzie , więc staram się trzymać się go jakolist_apple

Tak więc przycisk Login będzie login, ale jeśli mamy dwa loginy to login_fooi login_bar.

Zaczerpnięte z dokumentacji Androida . Na ten temat jest więcej.

Odpowiadając na twoje pytanie: tak, są.

Wiele z nich można znaleźć na przykład w wyszukiwarce Google . I nie ma czegoś takiego jak najlepsza konwencja nazewnictwa. Zawsze zależy to od Twoich potrzeb i atrybutów projektu (przede wszystkim zakresu).

Ostatnio przeczytałem całkiem niezły wpis na blogu Jeroen Mols dotyczący nazewnictwa zasobów w Android XML. Autor wspomina o podstawowej zasadzie, której powinny przestrzegać wszystkie zasoby, a następnie o tym, jak ta konwencja jest stosowana do każdego rodzaju zasobów. Oba opisane w ściągawce do nazewnictwa zasobów Androida :

Następnie szczegółowo opisuje każdy element i każdy rodzaj zasobów.

Powiedziałbym, że możesz zastosować tę konwencję od małych do średnich projektów (do użytku osobistego, kilkumiesięczne wnioski o kontrakt). Chociaż nie polecałbym tego do długich projektów z 50+ działaniami lub 1000+ strunami.

Konwencje dotyczące wartości zasobów w projektach na tak dużą skalę wymagają dokładniejszego zbadania sposobu ich wykorzystania. Weźmy na przykład struny. Może mieć na to wpływ wielkość Twojego zespołu, centrum tłumaczeń, z którego korzystasz (jeśli istnieje), VCS (na przykład w celu uniknięcia konfliktów podczas łączenia) itp. Możesz nawet pomyśleć o podzieleniu ciągów znaków na wiele plików.

Zakładam, że szukasz czegoś na początek. Polecam więc wspomniany przeze mnie wpis na blogu. Jest dobry na początek i na pewno możesz go wykorzystać jako inspirację do tworzenia własnych dobrych konwencji nazewnictwa.

Należy również pamiętać, że wraz z rozwojem projektu wiele potrzeb i wymagań może się zmieniać w czasie. Jest więc całkowicie normalne, że konwencje nazewnictwa, które były odpowiednie na początku, nie będą odpowiednie po 2 latach. I jest całkowicie w porządku. Nie powinieneś próbować przewidywać przyszłości. Po prostu wybierz konwencję i postępuj zgodnie z nią. Dowiesz się, czy jest odpowiedni dla Ciebie i Twojego projektu. Jeśli nie, zastanów się, dlaczego nie jest odpowiedni i zacznij używać czegoś innego.

Istnieje kilka konwencji używanych w zasobach:

• W przypadku zasobów, które istnieją jako oddzielne pliki, muszą one być oddzielone małymi literami. Narzędzie appt upewnia się, że pliki są pisane tylko małymi literami, ponieważ używanie mieszanej wielkości liter może powodować problemy w systemach plików bez rozróżniania wielkości liter.
• Dla zasobów zadeklarowanych tylko w wartościach / ... (atrybuty, ciągi znaków itp.) Konwencja jest generalnie mixedCase.
• Czasami stosuje się konwencję oznaczania nazw „klasyfikacją” w celu uzyskania prostych przestrzeni nazw. Jest to na przykład miejsce, w którym widzisz takie rzeczy, jak layout_width i layout_alignLeft. W pliku układu atrybuty zarówno widoku, jak i zarządzania układem nadrzędnym są mieszane, nawet jeśli są różnymi właścicielami. Konwencja „layout_ *” zapewnia, że ​​nie ma konfliktów między tymi nazwami i łatwo jest zrozumieć, na który element nazwa ma wpływ.

Ta konwencja „layout_blah” była również używana w kilku innych miejscach. Na przykład istnieją atrybuty „state_blah”, które są możliwymi do rysowania stanami, jakie może mieć widok.

Również ze względu na te dwie konwencje (podkreślenie_separowane dla plików, mieszaneCase dla zadeklarowanych zasobów), można znaleźć szereg niespójności. Na przykład kolory można zadeklarować za pomocą plików lub jako jawne wartości. Generalnie chcielibyśmy trzymać się podkreślenia_ osobno dla wszystkich tych elementów, ale nie zawsze się to zdarza.

Ostatecznie nie martwimy się zbytnio konwencjami nazewnictwa zasobów. Najważniejszą rzeczą, którą utrzymujemy spójną, jest „mixedCase” dla atrybutów i użycie „layout_blah” do identyfikacji atrybutów parametrów układu.

Również przeglądanie zasobów publicznych tutaj powinno dać dobre wyczucie konwencji:

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

Zobaczysz, że wszystkie atrybuty są dość spójne (biorąc pod uwagę, że rozumiesz konwencję layout_), elementy do rysowania są oddzielone podkreśleniem itp.

Jest to powszechny problem w każdym języku lub frameworku, ale tak długo, jak unikasz zastrzeżonych słów, powinieneś być w porządku, zakładając, że pamiętasz, jak to nazwałeś.

Zauważyłem, że Android nakłada ograniczenia na nazwy plików zasobów xml, ale podkreślenia wydają się być w porządku. ADT faktycznie stwierdza

Nazwy zasobów oparte na plikach mogą zawierać tylko małe litery az, 0-9 lub _.

Coś, co na początku mnie zaskoczyło, to brak przestrzeni nazw z identyfikatorami, ale ogólnie można to zignorować, jeśli masz dwa identyfikatory, a ten sam Android po prostu ponownie użyje zdefiniowanego identyfikatora.

Dla id używam 3-literowego kwalifikatora, po którym następuje to, do czego się odnosi w notacji wielbłąda, np. LblFoo dla statycznej etykiety tekstowej (lub textview), txtFoo dla edytowalnego pola tekstowego (edittext w Androidzie). Na początku może się to wydawać dziwne, ale używam go od czasu VB6, a te elementy sterujące nazywały się etykietą i polem tekstowym.

Oto kilka, których często używam:

• btnFoo - przycisk
• pwdFoo - hasło
• lstFoo - lista
• clrFoo - kolor
• tblFoo - tabela
• colFoo - kolumna
• rowFoo - row
• imgFoo - obraz
• dimFoo - wymiar
• padFoo - wyściółka
• mrgFoo - margines

Używam tego samego w kodzie w pliku java, więc nie muszę o tym myśleć, zakres pakietu pozwoli na to całkiem szczęśliwie:

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

Mógłbyś, jeśli wolisz, dodać trochę spacji za pomocą podkreślenia, np. Btn_foo ... Prawdopodobnie zrobiłbym to, gdybym mógł przełamać stare przyzwyczajenia.

Są tacy, którzy mogą twierdzić, że skracanie tych skrótów może nie być idealne, a puryści argumentowaliby, że należy użyć pełnej nazwy, ale kiedy nazywasz dziesiątki elementów sterujących i zmieniasz między różnymi systemami i strukturami, pełne nazwy tracą znaczenie. używam ich od ponad dekady w VB, C ++, ASP.NET, WinForms w C # i VB.NET, Androidzie i Pythonie. Nigdy nie muszę pamiętać, czy Android nazywa to polem tekstowym czy edytorem. Wszystko, co muszę wiedzieć, to to, że lblFoo jest statyczną etykietą, a txtFoo jest tym, do czego wpisuje użytkownik.

Ostatnia uwaga jest taka, że ​​bez względu na to, jaką konwencję zdecydujesz się na ważne rzeczy, nazywanie kontrolek jest prawidłowe i spójne, aby nie zmagać się z niejasnymi domyślnymi identyfikatorami, np. TextView5 lub mieszanką różnych konwencji

Przydatny link dla projektanta i programistów - tutaj

Wymiary i rozmiary, konwencje nazewnictwa, style i motywy, dziewięć łatek i tak dalej.

Nie sądzę, by istniała żadna standardowa konwencja promowana przez Google. Widziałem różne sposoby nazywania rzeczy, nawet w różnych oficjalnych aplikacjach Google.

Cokolwiek pomoże ci najbardziej, gdy próbujesz nadać sens 100 plikom układu (lub rysunków, menu itp.) W jednej hierarchii katalogów.

Krótka odpowiedź: jeśli chcesz uczyć się od programistów Androida, dobrym przykładem jest biblioteka wsparcia v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip )

W przeciwnym razie, oto co rozważałem przy nazywaniu zasobów:
1. łatwe znajdowanie zasobów podczas pisania kodu
2. łatwe rozumienie zasobów podczas czytania kodu
3. tworzenie nazw przydatnych dla tłumaczy ( R.string.*tylko zasoby)
4. ponowne używanie układów z <include/>( R.id.*konflikty zasobów)
5. radzenie sobie z projektami bibliotecznymi

Logicznie rzecz biorąc, porządkowanie zasobów nie powinno różnić się od grupowania klas Java w pakiety (lub umieszczania plików w folderach). Jednakże, ponieważ zasoby systemu Android nie mają przestrzeni nazw, przedrostki muszą zostać dodane do nazwy zasobu, aby osiągnąć to samo (np. com.example.myapp.photoStaje sięcom_example_myapp_photo ).

Proponuję podzielić aplikację na osobne komponenty (działania, fragmenty, okna dialogowe itp.) O krótkich, unikalnych nazwach, które mogą być używane jako prefiksy zasobów. W ten sposób grupujemy zasoby z powiązanymi funkcjami, co ułatwia ich wyszukiwanie (punkt 1) i jednocześnie unikamy konfliktów nazewnictwa zarówno z <include/>projektami bibliotecznymi, jak i (punkty 4 i 5). Należy pamiętać, że zasoby wspólne dla wielu składników mogą nadal mieć przedrostek (taki jakR.string.myapp_ok_button ).

Po prefiksie nazwa powinna nam informować, do czego służy zasób (akcja do wykonania, treść do wyświetlenia itp.). Wybór dobrego imienia jest ważny dla zrozumienia (punkty 2 i 3).

Czasami „nazwa_komponentu” dostarczy nam wystarczających informacji, co jest szczególnie prawdziwe, jeśli typ jest już podany przez klasę R (w R.string.myapp_name_stringdrugim „ciągu” jest nadmiarowy). Jednak jawne dodanie typu może poprawić zrozumienie (np. Tłumacze mogą dobrze odróżnić toast od etykiety). Czasami części „nazwa” i „typ” można zamienić, aby umożliwić filtrowanie na podstawie typu (R.string.photo_menu_* da nam tylko pozycje związane z menu dla komponentu zdjęcia).

Powiedzmy, że piszemy ćwiczenie do robienia zdjęć, klasa com.example.myapp.photo .PhotoActivity. Nasze zasoby mogą wyglądać następująco (pogrupowane według komponentu „zdjęcie”):

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  

Jeśli przejrzysz dokumentację Androida, znajdziesz tam różne wzmianki o „najlepszych praktykach”, ale z pewnością nie ma konkretnych reguł. Na przykład w wytycznych dotyczących projektowania ikon wskazówkach Google sugeruje nazywanie ikon z prefiksem „ic_”.

Dobrym miejscem do rozpoczęcia może być zapewnienie zasobów .

Przejrzyj także źródła / przykłady SDK, a także blog programistów Androida, jeśli chcesz zobaczyć, jak robią to programiści Google.

Znalazłem przydatną następną konwencję nazewnictwa dla ciągów:

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

Na przykład clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. A „akcja” jest tutaj opcjonalna.

możesz przeczytać dokumentację Google dotyczącą stylu kodu, aby uzyskać pomysł tutaj

Generalnie postępowałem zgodnie z konwencją nazewnictwa java dla identyfikatorów zasobów (nie dla plików dla plików), z wyjątkiem tego, że dodałem „x” na początku identyfikatorów, na przykład:

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

W javie możemy go używać w prosty sposób (możemy też zapamiętać w prosty sposób)

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

Tutaj mTvName (jest to ogólnie sugerowane konwencje nazewnictwa Androida) i xTvName, który został nazwany w pliku układu jako część identyfikatora Android TextView (x oznacza XML), postępowałem zgodnie z tego typu konwencjami nazewnictwa dla obiektów widoku, takich jak przyciski i EditText itp.

w XML IDS: xViewTypeSpecificName

w Javie: mViewTypeSpeficName

Powyższe konwencje ułatwiają mi życie, kiedy tworzę złożone układy. Po prostu postaraj się, aby twoje nazwy były jak najbardziej krótkie i lepiej, jeśli są zrozumiałe i znaczące dla innych współtwórców (ale może to nie być możliwe za każdym razem). Mam nadzieję, że moje doświadczenie pomoże innym, sugestie są mile widziane.

W naszych projektach na Androida jest wiele komponentów, takich jak przyciski, etykiety, pola tekstowe. Tak prosta nazwa, jak na przykład „nazwa”, jest bardzo myląca, aby zidentyfikować „nazwę” jako etykietę lub pole tekstowe. Głównie dzieje się tak, gdy zarządzasz projektami opracowanymi przez innych programistów.

Aby uniknąć tego rodzaju zamieszania, użyłem następujących nazw dla Buttons TextBoxes lub Labels

Przykład:

 btnName
 labName
 txtName
 listName

Może to być pomocne dla Ciebie.

Istnieją pewne ograniczenia:

1. Nazwa zasobu powinna zawierać az, 0-9, _
2. Nazwa zasobu powinna zaczynać się od az, _

Nawiasem mówiąc, lepiej jest postępować zgodnie z wytycznymi lub uczyć się od standardowego kodu.