O projekcie i kliencie#
Polski Związek Łowiecki to organizacja zrzeszająca polskich myśliwych — strukturalnie obejmuje koła łowieckie, zarządy okręgowe i Zarząd Główny. SKŁ PZŁ 2.0 to pierwsze tak duże przedsięwzięcie cyfrowe w historii Związku, zastępujące rozproszone dotąd narzędzia i papierową książkę ewidencji polowań jednolitym, ogólnopolskim systemem.
Zaprojektować i wdrożyć aplikację mobilną będącą naturalnym przedłużeniem systemu webowego PZŁ 2.0 — pokrywającą pełen cykl pracy koła łowieckiego: Elektroniczną Książkę Ewidencji Polowań, polowania indywidualne i zbiorowe, szkody łowieckie, magazyn koła, mapy obwodów z warstwami nakładkowymi, urządzenia łowieckie, rozliczenia, wykonanie planu rocznego, newsletter Zarządu Głównego, czat, zgłoszenia alarmowe, pogodę z prędkością wiatru, zaproszenia gości i pomoc koleżeńską — z jednolitym podziałem uprawnień dla wszystkich poziomów struktury PZŁ.
Otrzymaliśmy wiele komentarzy i pytań od członków Zrzeszenia. To wyraźny sygnał, że środowisko oczekuje nowoczesnych rozwiązań, które usprawnią pracę kół i wzmocnią organizację PZŁ.
Z czym się mierzyliśmy#
System Kół Łowieckich obsługuje pełen cykl pracy koła — od ewidencji polowań, przez polowania indywidualne i zbiorowe, szkody łowieckie i magazyn, po komunikację wewnątrz organizacji. To znaczy, że aplikacja mobilna musiała pomieścić bardzo szeroki zakres scenariuszy w jednym, spójnym produkcie.
Elektroniczna Książka Ewidencji Polowań
Cyfrowy zamiennik papierowej książki, w której myśliwy zgłasza polowanie. Centralny element pracy koła — musi być szybki, niezawodny i łatwy w obsłudze.
Polowania — indywidualne i zbiorowe
Dwa różne procesy w jednej aplikacji. Polowanie solo to szybki wpis. Polowanie zbiorowe to lista uczestników, miejscówki, przebieg i rozliczenie końcowe.
Mapa obwodu jako centrum aplikacji
Granice obwodu, urządzenia łowieckie, działki, leśnictwa, ortofotomapy. Mapa to ekran, do którego użytkownik wraca dziesiątki razy dziennie — musi być natychmiastowa i czytelna.
Szkody łowieckie
Oszacowanie wstępne i ostateczne, z zaznaczeniem obszaru zniszczeń na mapie. Proces wrażliwy z punktu widzenia rolników i ubezpieczycieli — nie może być pomyłkowy.
Jeden użytkownik, wiele ról, wiele kół
Ten sam człowiek bywa myśliwym w jednym kole i łowczym w drugim. Aplikacja musi pokazywać mu tylko to, co należy do aktualnego kontekstu — bez relogowania.
Spójność z webem i back-endem
Łowczy może rano otworzyć ten sam wpis na laptopie, a wieczorem z telefonu. Mobile, web i backend muszą widzieć dokładnie te same dane, w ten sam sposób.
Zgłoszenie alarmowe — strzał
Awaryjne zgłoszenie incydentu z lokalizacją, dostępne natychmiast. Funkcja, w której każda sekunda projektowania ma znaczenie.
Magazyn koła i rozliczenia
Aktywa, rezerwacje, urządzenia łowieckie, rozliczenia indywidualne i zbiorowe, wykonanie rocznego planu — w jednym module, z jasnym podziałem uprawnień.
Komunikacja Zarządu Głównego
Newsletter Zarządu Głównego trafiający do wszystkich myśliwych, wiadomości użytkowników, ogłoszenia — codzienny kanał komunikacji wewnątrz Zrzeszenia.
Lokalizacja w tle — tylko wtedy, gdy potrzeba
Pozycja myśliwego ma znaczenie podczas polowania zbiorowego. Poza nim — nie. Włączamy ją tylko wtedy, gdy faktycznie wnosi wartość.
Pogoda i warunki w terenie
Aktualna pogoda, kierunek i prędkość wiatru, wschód i zachód słońca — informacje, które dla myśliwego decydują o tym, czy w ogóle wybrać się w łowisko.
Goście i zaproszenia
Myśliwy z innego koła może zostać zaproszony na polowanie. To wymaga pełnego workflow zezwoleń — wystawienia, akceptacji, ważności w danym dniu i obwodzie.
Nowy system znacząco usprawni pracę w kołach łowieckich. Jest prostszy w obsłudze, bardziej intuicyjny, a wiele czynności, takich jak raportowanie czy obsługa dokumentów, stanie się znacznie szybsze i mniej podatne na jakiekolwiek błędy.
Macie podobnie złożony projekt? Pogadajmy.
Mapy, role, integracje z innymi zespołami i skala — wiemy, jak to ułożyć w spójny produkt mobilny.
Jak weszliśmy w projekt#
Projekt prowadzi SmallGIS jako wykonawca systemu PZŁ 2.0. SmallGIS dobrał technologie dla całego rozwiązania — w tym React Native dla aplikacji mobilnej — a następnie szukał partnera, który poprowadzi tę część. Tak trafili do nas. Naszą rolą jako Mobile Development Leadera było objęcie pełnej odpowiedzialności za warstwę mobilną i poprowadzenie zespołu React Native tak, żeby aplikacja domknęła się w czasie i jakości.
Wejście w projekt i przejęcie warstwy mobilnej
SmallGIS miał zdefiniowaną wizję produktu, stack i kontrakt z PZŁ. Naszym pierwszym zadaniem było zrozumienie zakresu, wskazanie ryzyk po stronie mobile i ustalenie sposobu współpracy z zespołem webowym i backendowym SmallGIS.
Etapowy development z dużymi wydaniami
Pracowaliśmy w kilku etapach — każdy zamykał się wydaniem konkretnego pakietu funkcji prezentowanym SmallGIS i PZŁ. Pakiet, nie sprint — bo pakiet pokazuje wartość biznesową, a sprint tylko upływ czasu.
Beta z myśliwymi i przekazanie klientowi
Closed beta na grupie kół wytypowanych przez PZŁ, iteracje na bazie realnych raportów z polowania, finalne przekazanie kodu i dokumentacji do SmallGIS po 6 miesiącach.
Bez vendor lock-in. Klient ma pełnię praw do kodu.
Dla PZŁ kluczowe było, by po zakończeniu współpracy mieli pełny wpływ na dalszy rozwój systemu — możliwość rozbudowy, integracji z kolejnymi narzędziami i ewentualnej zmiany wykonawcy bez ryzyka utraty danych albo zatrzymania projektu. Dlatego stack jest świadomie standardowy, kod oddany w pełni razem z pełnym przeniesieniem majątkowych praw autorskich, a dokumentacja techniczna i CI/CD przekazane od pierwszego dnia.
Kluczowe widoki#
Dziewięć kluczowych widoków aplikacji — od polowania zbiorowego i komunikacji zespołowej po szacowanie szkód i zarządzanie gośćmi.
Uwaga: powyższe widoki to nasze redesigny pierwotnych ekranów aplikacji. Obecnie warstwa designu i dalszy rozwój SKŁ PZŁ 2.0 prowadzone są bezpośrednio przez Polski Związek Łowiecki — philosopht nie pracuje już nad jej projektem graficznym.
Co dostarczyliśmy#
Aplikacja została przekazana SmallGIS w 6 miesięcy i jest częścią ogólnopolskiej infrastruktury cyfrowej PZŁ — pierwszego tak dużego przedsięwzięcia cyfrowego w historii Związku.
Decyzje, które zrobiły różnicę#
Trzy decyzje techniczne, które najmocniej wpłynęły na to, jak aplikacja się zachowuje i jak łatwo ją utrzymywać. Reszta stacku jest świadomie standardowa — bez egzotycznych zależności, tak żeby SmallGIS i PZŁ mogli ją utrzymać po przekazaniu projektu.
Klient API generowany ze specyfikacji, nie pisany ręcznie
Aplikacja rozmawia z backendem na poziomie ponad dwudziestu modułów funkcjonalnych. Pisanie klienta REST ręcznie oznacza nieuchronne rozjazdy między mobile, webem i back-endem — każda zmiana kontraktu rodzi nową regresję na trzech platformach naraz.
Postawiliśmy na codegen z OpenAPI: typy, schematy walidacji i hooki do pobierania danych generują się automatycznie ze specyfikacji backendu, regeneracja dzieje się przy każdym buildzie. Skutek dla zespołu: zmiana w API jest natychmiast widoczna w mobile jako błąd kompilacji, nigdy jako ciche pominięcie pola.
Jest też drugi efekt, mniej oczywisty — przesunięcie odpowiedzialności za walidację danych tam, gdzie naturalnie powinna być: na backend. Frontend nie pisze własnych reguł walidacyjnych, które mogłyby się rozjechać z kontraktem — ufa specyfikacji i automatycznie wygenerowanym schematom. Bezpieczeństwo danych jest pilnowane w jednym miejscu, w sposób spójny dla wszystkich klientów — mobile, webu i każdego przyszłego.
Uprawnienia jako warstwa, nie if-y rozsiane po komponentach
System obsługuje wiele ról w wielu kołach jednocześnie. Bez wspólnej warstwy uprawnień każdy ekran szybko zamieniłby się w gąszcz warunków — nieczytelnych i podatnych na błędy bezpieczeństwa.
Zaprojektowaliśmy centralny rejestr uprawnień oparty na trasach Expo Router i jeden hook, który wymusza zasady w każdym komponencie. Aktywny kontekst (które koło, jaka rola) jest jednym źródłem prawdy — przełączenie konta zmienia widoczność modułów natychmiast, bez relogowania, bez magii.
Lokalizacja w tle tylko wtedy, gdy faktycznie ma znaczenie
Pozycja myśliwego jest istotna podczas polowania zbiorowego — wiadomo, gdzie kto jest na linii. Poza tym jest niepotrzebna i byłaby niepokojąca z punktu widzenia prywatności i baterii.
Background location uruchamiamy per aktywne polowanie, nie globalnie. Task startuje, gdy myśliwy dołącza do zbiorówki, kończy się sam, gdy polowanie się zamyka. Foreground tracking jest dodatkowo throttlowany — tyle dokładności, ile potrzeba do mapy, bez rozładowywania telefonu po godzinie w lesie.
Tech stack#
Wybór bibliotek i narzędzi wokół trzech decyzji powyżej. Standardowe, dobrze utrzymywane, bez ryzyka osierocenia.
FRAMEWORK · NAWIGACJA
JĘZYK
MAPY & LOKALIZACJA
STAN, DANE I CODEGEN
POWIADOMIENIA
RELEASE & DELIVERY
AUTH I BEZPIECZEŃSTWO
UI & WYDAJNOŚĆ
Środowiska i drogi do użytkownika#
Cztery środowiska, każde z osobną rolą i osobną grupą odbiorców. Im bliżej użytkownika końcowego, tym ostrzejsze kryteria wejścia.
Chcecie podobne wyniki u siebie?
Wstępna analiza i wycena w 48h. Bez zobowiązań — pierwszy krok zawsze po naszej stronie.
Mapa obwodów — warstwowy system #
Cztery warstwy bazowe, sześć warstw nakładkowych, jedno spójne doświadczenie
Mapa w aplikacji nie jest jednorazowym widokiem — to centralny ekran, do którego użytkownik wraca z różnych modułów: ekranu polowania zbiorowego, szkód łowieckich, urządzeń łowieckich, listy obwodów. Za każdym razem chce widzieć ten sam obraz świata, tylko z innym akcentem — raz inne nakładki, raz inną warstwę bazową.
Pierwsze podejście było intuicyjne, ale wadliwe: zmiana warstwy bazowej przemontowywała całą mapę. Mignięcie ekranu, utrata pozycji kamery i zoomu, pełen reload wszystkich kafelków — nieakceptowalne na ekranie używanym w trakcie polowania.
Rozwiązaniem była dekompozycja mapy na cztery wyraźne warstwy odpowiedzialności:
Kontroler — trzyma stan widoku, decyduje, która warstwa bazowa jest aktywna i które nakładki użytkownik włączył. Kompozycja — składa wszystkie warstwy bazowe i nakładkowe naraz, ale tylko aktywne renderują kafelki; reszta jest gotowa do błyskawicznego pokazania. Pojedyncza warstwa — każde źródło danych (ortofoto, topo, działki, leśnictwa) ma swój komponent z własną strategią ładowania. Lazy loading — ciężkie warstwy nakładkowe montują się dopiero w momencie pierwszego użycia, nie blokując pierwszego renderu mapy.
Efekt jest niewidoczny na pierwszy rzut oka — co jest największym komplementem dla kodu mapy. Użytkownik przełącza między ortofotomapą a OSM, kamera zostaje na miejscu, kafelki pojawiają się płynnie. Z perspektywy łowczego sprawdzającego granice obwodu w trakcie polowania — mapa po prostu działa, tak jak powinna.
// koncepcyjnie: jedna kompozycja, wiele warstw, jedna mapa <MapComposition camera={camera}> // warstwy bazowe — zawsze w drzewie, aktywna jedna <BaseLayers active={baseLayer} /> // nakładki — lazy, montują się przy pierwszym użyciu <Overlays visible={enabledOverlays} lazy /> </MapComposition>
To inwestycja nie tylko w technologię, ale przede wszystkim w lepsze funkcjonowanie naszej wspólnoty myśliwskiej.