[siemanko]

#programowanie #java #androiddev

Czy enumy są złe? A czemu w ogóle miały by takie być? Nie zastanawiało was dlaczego w Androidowym frameworku wszędzie używa się integrów zamiast enumów?
No to odpowiedź macie tutaj:
http://trevore.com/post/should-I-use-enums-in-Android

W skrócie - ze względów wydajnościowych. Jeżeli ktoś kładzie duży nacisk na optymalizację, warto zastanowić się nad tym czy w danej sytuacji nie lepiej użyć klasy ze statycznymi polami integer. Oczywiście enum ma swoje zalety, ale w miejscach gdzie używamy go tylko jako flagi, lepiej sprawdza się stary dobry integer.

[hilemz]

@siemanko: P---------e.

[siemanko]

@hilemz: Przekonałeś mnie

[qmar]

@siemanko: zgadzam się z @hilemz - dla paru kb nie ma sensu się spinać

[siemanko]

@qmar: To wszystko zależy od projektu. Tam gdzie używa się ledwie kilku enumów na krzyż to oczywiście takie liczenie bitów nie ma najmniejszego sensu. Jednak chyba lepiej mieć tego świadomość i wiedzieć co tak naprawdę dzieje się "pod maską".

[qmar]

@siemanko: jasne - świadomość zawsze warto mieć

[plastik]

@siemanko: Wolisz potem czytać kod:
setFlag(1) czy

setFlag(flags.R-------O_SIE)

? ( ͡° ͜ʖ ͡°)

[siemanko]

@plastik: Przecież tak samo możesz zrobić z integrami.

public class Status {
public static final int NIER-------OSIE = 1;
public static final int

[martinuz]

@plastik: Lulz, ale w kodzie to nadal bedzie wygladalo tak samo
static final int R-------O_SIE = 1;

[mumiok1]

Nie jest tak źle jak by się wydawało :) https://developer.android.com/tools/debugging/annotations.html#enum-annotations

[plastik]

@martinuz: @siemanko: a no racja, widać żem początkujący xD

[siemanko]

@mumiok1: No właśnie w komentarzach ktoś tam to zapodał i przyznam, że nawet o tym nie wiedziałem. Dobra rzecz, aby zapobiec wstawianiu złych flag.

[soso]

Enumy w Javie są zajebiste, dają dużo możliwości, ale dla zwykłej flagi, imo nie trzeba używać, chociaż ja lubię.

[darck]

To wszystko zależy od projektu. Tam gdzie używa się ledwie kilku enumów na krzyż to oczywiście takie liczenie bitów nie ma najmniejszego sensu. Jednak chyba lepiej mieć tego świadomość i wiedzieć co tak naprawdę dzieje się "pod maską".

@siemanko: nie wiem, co to za aplikacja musiałaby być, żeby potrzeba było więcej niż 100 enumów. A to jest nic jeśli chodzi o pamięć.

[jablo]

@siemanko: @hilemz: @qmar: wersja video z oficjalnego zrodla ;-) [](https://www.youtube.com/watch?v=Hzs6OBcvNQE)

[siemanko]

@darck: Przecież tu nie chodzi o to, że w projekcie będzie 100 enumów jako oddzielne klasy tylko o przypadek gdzie np. masz kolekcję 1000 instancji obiektów mających w polach jakiegoś enuma.

[darck]

@siemanko: nawet jeśli, to enumy nie są większy od Stringów, a jakoś nikt nie przejmuje się używaniem Stringów w kolekcjach.

[siemanko]

@darck: Jak to nikt się nie przejmuje takimi rzeczami? Jasne, dopóki apka robi nic to takie rzeczy są pomijalne, ale wyobraź sobie sytuacje, gdzie od aplikacji wymaga się maksymalnej wydajności i to ma ogromne znaczenie. Naprawdę trochę wyobraźni.
Ostatnio pracowałem przy aplikacji zajmującej się przetwarzaniem dźwięku. Apka generowała masę obiektów w bardzo krótkim czasie zawierających stan. Zmiana enumów na integry poprawiła ogólny czas reakcji o 50%.

[jablo]

@siemanko: Dość znaczącą przyczyną przez którą ludzie nie zwracają na to uwagi jest, jak to zauważył ktoś z teamu googla, że programiści androida piszą apki korzystając z najnowszych flagowców gdzie ramu się praktycznie nie liczy i heap jest duzo większy niż u reszty. W sytuacji gdy ludzie wciąż kupują telefony u operatora typu S3 jako z wysokiej półki (pomijam budżetowe modele których i tak jest więcej) i nie planują ich

[KrzaQ2]

@siemanko: Brzmi jak bzdurne ograniczenie języka, tbh.

[siemanko]

@KrzaQ2: No niestety każdy język ma jakieś ograniczenia z którymi trzeba sobie rodzić :/