Wpis z mikrobloga

Właśnie przebudowałem projekt tak, aby działał w modelu modułowo-eventowym, gdzie każdy moduł ma swój wątek oraz kolejkę eventów; wątek czeka na event w kolejce i go obsługuje. Eventy mają swój priorytet. Eventy typu TICK_25MS wysyłane są przez wątek Quadcoptera, inne pochodzą od innych modułów.

Trochę kodu (ciągle się uczę poprzez takie projekty):

https://dl.dropboxusercontent.com/u/55028256/StatusExchangeModule.java.html

#programowanie #android #java #androiddev #quadcopter
  • 7
@Visher: - moduły mogą się w ogóle nie zatrzymywać i zawiesić aplikację (stopModule i join), kolejka której używasz zawsze zwraca true więc nie musisz tego sprawdzać. Pole quadrocopter albo na final albo je synchronizuj, bo pewnie często się do niego odnisisz.

Co do designu to dużo by się wypowiadać, ale generalnie np. akceptowane kody eventów na 99% powinny być w najzwyklejszej kolekcji, to nie jest różnica w zachowaniu tylko w danych.
@hbpitero: Michałem trochę roboty, więc pozwól że teraz przeanalizuję Twój komentarz - jaka jest możliwość zawieszenia aplikacji, skoro wywołanie destroy() ustawi stopModule na true (więc nigdy nie wejdzie ponownie do pętli while z queuedEvents.take()), oraz moduleThread.interrupt() przerwie pobieranie obiektu z kolejki? Zakładamy, że metoda onModuleStopping wykonuje tylko krótkie operacje (wyrejestrowanie listenerów itp.)

Zmieniłem też typ zmiennej stopModule na AtomicBoolean.

Ostatniej linijki nie rozumiem. dispatchEvent() jest wywoływane przez zew. moduły i do
@Visher Zawieszenie było możliwe po prostu przez booleana - nie był synchronizowany ani volatile. AtomicBoolean rozwiązuje sprawę.

Jeżeli chodzi o tę metodę to mam na myśli tylko przerobienie jej wnętrza. Do wyrzutki:

if (!added) {


System.out.println("Couldn't add event " + event + " to " + getClass().getSimpleName()+ "'s queue.");


}

a to:

queuedEvents.offer(event);


return;

w miejsce isAccepted = true; i metoda staje się znacznie przejrzystsza (6 linijek)