Czy istnieją konwencje dotyczące nazywania zasobów w systemie Android? Na przykład przyciski, TextViews, menu itp.
104
Czy istnieją konwencje dotyczące nazywania zasobów w systemie Android? Na przykład przyciski, TextViews, menu itp.
Odpowiedzi:
Nie wiem, czy są jakieś oficjalne zalecenia.
W przypadku identyfikatorów w moich układach z widżetami i kontenerami używam konwencji:
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:
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.
źródło
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ł
ListView
to po prostu byłby@android:id/list
we wszystkich działaniach.Gdybym jednak miał dwie listy, to użyłbym bardziej szczegółowych
@id/list_apple
i@id/list_orange
Tak więc ogólne (ids, ...) są ponownie używane,
R.java file
podczas 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_width
w formacie XML , alayoutWidth
w kodzie , więc staram się trzymać się go jakolist_apple
Tak więc przycisk Login będzie
login
, ale jeśli mamy dwa loginy tologin_foo
ilogin_bar
.źródło
Zaczerpnięte z dokumentacji Androida . Na ten temat jest więcej.
źródło
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.
źródło
Istnieje kilka konwencji używanych w zasobach:
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.
źródło
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
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:
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:
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
źródło
Przydatny link dla projektanta i programistów - tutaj
Wymiary i rozmiary, konwencje nazewnictwa, style i motywy, dziewięć łatek i tak dalej.
źródło
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.
źródło
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.photo
Staje 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_string
drugim „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ódło
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.
źródło
Znalazłem przydatną następną konwencję nazewnictwa dla ciągów:
Na przykład clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. A „akcja” jest tutaj opcjonalna.
źródło
możesz przeczytać dokumentację Google dotyczącą stylu kodu, aby uzyskać pomysł tutaj
źródło
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:
W javie możemy go używać w prosty sposób (możemy też zapamiętać w prosty sposób)
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.
źródło
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:
Może to być pomocne dla Ciebie.
źródło
Istnieją pewne ograniczenia:
Nawiasem mówiąc, lepiej jest postępować zgodnie z wytycznymi lub uczyć się od standardowego kodu.
źródło