Jak już pisałem wcześniej wstępną implementację VehicleBeacon zakończyłem. Jednocześnie mam już zaimplementowaną wersję Alpha logiki odpowiedzialnej za prezentację pojazdów na mapie. Po uruchomieniu serwisów VehicleBeacon i Beaconer można wejść na stronę ToTu i obejrzeć pustą mapę:)
Dane potrzebne do prezentacji pojazdów na mapie pobierane są przez Beaconer’a z VehicleBeacon co 5 sekund. Zgodnie z przyjętą architekturą ToTu aby jakiekolwiek dane pojawiły się na mapie muszą zostać na początku wstawione do VehicleBeacon ( przy pomocy REST API lub WebSocket’ów). Do wstawiania danych do VehicleBeacon używam PostMan’a, dzięki któremu można łatwo tworzyć requesty HTTP i wywoływać je na różnych serwerach. Po pierwszym zawołaniu VehicleBeacon z danymi jednego pojazdu zobaczyłem:
Myśla na przyszłość: TDD działa :). Kolejne wstawienia pojazdów przebiegały bez problemu. Teraz czas na implementację serwisu odpowiedzialnego za prezentowanie na mapie przystanków – nowy serwis lub rozbudowa VehicleBeacon w uniwersalny Beacon obsługujący dane z regionu, który obsługuje.
P.S. Implementacja GoogleMaps w ToTu:
Aby być jak najmniej zależnym od GoogleMaps postanowiłem, że JS odpowiedzialny za prezentację będzie podzielony na warstwy
- Logiki
- Prezentacji i interakcji z mapą.
Aby jak najbardziej odseparować od siebie te dwie warstwy jedyną komunikację między nimi są eventy, co pozwala na łatwą wymianę GoogleMaps na BingMaps lub Open Street Maps. Jedyne, co trzeba zapewnić przy wymianie dostawcy map jest spójna obsługę zdarzeń, jakie moduł map przyjmuje i generuje. Drugą zaletą sprowadzenia modułu map tylko do prezentacji map i publikowania zdarzeń jest to, że całą logika gdzie/czy/jaki wyświetlić marker podejmowana jest w warstwie logiki, która jest łatwo testowalna.