2013-10-23 12 views
8

Znam różnicę między @+id a @id (patrz: accepted answer). Jednak zawsze mam wrażenie, że wykonuję pracę kompilatora AAPT, kiedy piszę "+" w @+id.Dlaczego konieczne jest użycie @ @ id zamiast @id?

Czy istnieje powód, dla którego kompilator zasobów nie może sam wnioskować, czy identyfikator musi zostać utworzony, czy po prostu ponownie wykorzystany? Podstawowa struktura hashtable wykona zadanie: każdy zasób o tym samym identyfikatorze trafi do tego samego zasobnika, a jeśli klucz nie istnieje, po prostu go utwórz.

+0

http://stackoverflow.com/questions/5025910/difference-between-id-and-id-in-android - odnoszą się do tego – N20084753

+0

@ N20084753 Już wspomniał o tym w OP. – Piovezan

+0

@ N20084753 To jest link, który podałem w pierwszym zdaniu. Wyjaśnia różnicę, ale nie odpowiada, dlaczego AAPT nie może automatycznie wywoływać "+". –

Odpowiedz

0

z @ + id dodajesz id do R.java, który pozwala ci odwoływać się do niego z klas Java, podczas gdy z @id nie jesteś. Możesz użyć @id tylko wtedy, gdy określony identyfikator jest już utworzony i odwołujesz się do niego w innym widoku, np. android:layout_below="@id/some_id"

+1

Dzięki, ale jak już powiedziałem, wiem o tym wszystkim. Pytanie brzmi, dlaczego konieczny jest znak plus. Kompilator powinien bardzo łatwo wiedzieć, czy identyfikator już istnieje, więc nie rozumiem, dlaczego muszę podać tę informację. –

1

Prawdopodobnie kompilator nie byłby w stanie odróżnić "właściwego" od "niewłaściwego" identyfikatora. Jeśli znajdzie nowy identyfikator (tj. Taki, który nie znajduje się w ukrytej tablicy), zawsze zakłada, że ​​jest to prawy, nowy identyfikator. Nie będzie w stanie rozróżnić rzeczywistego nowego identyfikatora od błędnego identyfikatora.

+0

Może, ale wynikiem tego jest to, że wielu twórców używa wszędzie @ + id, ponieważ nie ma błędu, jeśli identyfikator jest już zdefiniowany i wszystko działa dobrze. Oznacza to, że kompilator testuje, czy identyfikator już istnieje, ale nie, jeśli nie istnieje, to jest szalone. –

1

Mogę sobie wyobrazić, że jest to pomoc dla programisty.

Jeśli nie potrzebujesz konstrukcji @ + id, wtedy wszystkie odniesienia @id/konstrukcje byłyby ważne, wtedy trudno byłoby wyśledzić błąd, ponieważ kompilator nie zawiedzie na niewłaściwych referencjach (jak to by było po prostu skonstruować identyfikator literówki).

Inaczej mówiąc, wszystkie błędy odniesień do identyfikatorów musiałyby zostać wykryte w czasie wykonywania.

Edit:

Właśnie zauważyłem podobną odpowiedź od Piovezan, odnośnie Twojego komentarza:

Maybe, but the result is that many devs use @+id everywhere, since there is no error if the id is already defined, and everything works just fine. That means the compiler tests if the id already exist, but not if it does not exist, that's crazy 

Następnie te deweloperzy nadużywanie @ + id budowę imo.

O wiele lepiej jest mieć opcję rozróżniania pomiędzy @ + id i @id, ponieważ (dla tych, którzy nie używają błędnie identyfikatora @ +), kompilator ma szansę podać błąd czasu kompilacji na błędnych odniesieniach .

Edit2

I zająć się komentarz:

That's the link I gave in the first sentence. It explains the difference but does not answer why the '+' cannot be automatically infered by AAPT 

wierzę, że mogę, po prostu nie ma powodu do argumentacji powyżej (wierzę).

+0

Robiąc to specjalnie, aby pomóc programistom, rzeczywiście istnieje taka możliwość. Jednak spróbuj przeciągnąć i upuścić niektóre elementy interfejsu użytkownika w projektorze zaćmienia, a zobaczysz, że używa @ @ id EVERYWHERE! Ponieważ jest to oficjalne narzędzie Android, uważam, że to dziwne zachowanie, ponieważ większość nowych użytkowników będzie używać tego projektanta i patrzeć na kod, aby się uczyć. –

+0

Widzę twój punkt widzenia, ale ponieważ jest to narzędzie, na pewno wygeneruje poprawne referencje i może mieć powód do używania identyfikatora @ + (co jest dla mnie prostsze). Podsumowując, nie potrzebują czasu na kompilację, który przynosi @id. – cYrixmorten