mAPRS to mój autorski projekt aplikacji dla systemów Android i iOS, przeznaczonej do współpracy z APRS. Nie powstał dlatego, że na rynku brakowało aplikacji obsługujących APRS — takich programów jest już kilka i wiele z nich bardzo dobrze spełnia swoje zadanie. Powód był znacznie prostszy. Podczas codziennego korzystania z APRS denerwowała mnie konieczność ciągłego ręcznego zmieniania ustawień w zależności od tego, co aktualnie robię. Kiedy jadę samochodem, chcę być widoczny inaczej niż wtedy, gdy poruszam się pieszo. Jeszcze inny zestaw informacji powinien być wysyłany, kiedy jestem w domu. Za każdym razem trzeba było o tym pamiętać. I właśnie wtedy pojawiło się pytanie: dlaczego aplikacja nie może zrobić tego sama? Tak zaczął powstawać mAPRS.
Skąd pomysł na mAPRS?
Główne założenie projektu od początku było bardzo konkretne: aplikacja ma w możliwie dużym stopniu działać autonomicznie. Nie chciałem przed każdym wyjazdem zastanawiać się, czy ustawiłem właściwą ikonę. Nie chciałem po zaparkowaniu samochodu i rozpoczęciu spaceru ręcznie zmieniać profilu. Nie chciałem również pamiętać o kolejnym przełączeniu ustawień po powrocie do domu. mAPRS ma rozpoznawać sytuację i odpowiednio reagować.
Aplikacja określa, czy aktualnie: jadę samochodem, poruszam się pieszo czy znajduję się w domu. Na tej podstawie automatycznie dobiera odpowiednie elementy przesyłane do APRS — przede wszystkim ikonę, komentarz oraz właściwy symbol/znak stacji. Użytkownik nie musi więc za każdym razem zmieniać konfiguracji ręcznie. To właśnie ta automatyzacja jest najważniejszym powodem powstania mAPRS i jednocześnie cechą, wokół której buduję cały projekt.
Współpraca z APRS-IS
mAPRS komunikuje się z siecią APRS-IS, czyli internetową częścią infrastruktury APRS. Aplikacja przygotowuje informacje związane ze stacją i przekazuje je do sieci. Dzięki temu pozycja i pozostałe dane mogą być widoczne także w innych serwisach oraz aplikacjach korzystających z APRS-IS. Dla mnie bardzo ważne jest przy tym zachowanie zgodności z APRS. Automatyzacja nie ma tworzyć własnego, zamkniętego sposobu działania. Wręcz przeciwnie — mAPRS ma wykorzystywać istniejącą infrastrukturę APRS, ale wykonywać za użytkownika część czynności, które zazwyczaj trzeba robić ręcznie. To niewielka różnica z punktu widzenia samej sieci, ale bardzo duża z punktu widzenia osoby korzystającej z aplikacji każdego dnia.
Ślad ma pozostać dokładny
Jednym z ważnych elementów aplikacji jest rejestrowanie i prezentowanie trasy. Podczas rozwijania mAPRS zależy mi na tym, aby optymalizacja działania aplikacji nie odbywała się kosztem jakości śladu. Jeżeli poruszam się po trasie, chcę później widzieć jej rzeczywisty przebieg, a nie kilka przypadkowych punktów połączonych prostymi liniami. Dlatego mechanizmy odpowiedzialne za wysyłanie informacji do APRS i mechanizmy związane z tworzeniem śladu nie muszą działać dokładnie w ten sam sposób. Aplikacja może potrzebować szczegółowych informacji o ruchu do prawidłowego działania i prezentowania trasy, mimo że nie każda z tych informacji musi natychmiast zostać wysłana do APRS-IS.
Kolejne wyzwanie: zużycie energii
Aplikacja, która obserwuje lokalizację przez wiele godzin, bardzo łatwo może stać się jednym z największych konsumentów energii w telefonie. Dlatego optymalizacja zużycia baterii jest kolejnym ważnym etapem rozwoju mAPRS. Nie chodzi jednak o najprostsze rozwiązanie polegające na rzadszym sprawdzaniu pozycji. To mogłoby pogorszyć jakość śladu oraz skuteczność wykrywania sposobu poruszania się. Celem jest znalezienie takiego sposobu korzystania z mechanizmów lokalizacyjnych, aby aplikacja otrzymywała potrzebne informacje, ale jednocześnie nie zmuszała telefonu do niepotrzebnej pracy. To szczególnie istotne podczas dłuższej podróży lub całodziennej aktywności w terenie. mAPRS powinien działać w tle przez długi czas bez konieczności ciągłego zastanawiania się, ile baterii pozostało w telefonie.
Aplikacja rozwijana etapami
mAPRS cały czas jest rozwijany. Staram się jednak nie wprowadzać wielu przypadkowych zmian jednocześnie. Każda kolejna wersja ma konkretne zadanie — poprawić określony element, zmienić zachowanie aplikacji albo zoptymalizować istniejący mechanizm. Następnie nowa wersja trafia do testów. Takie podejście pozwala znacznie łatwiej sprawdzić, czy dana zmiana rzeczywiście przyniosła oczekiwany rezultat i czy przy okazji nie wpłynęła negatywnie na coś, co wcześniej działało prawidłowo. Szczególnie ważne jest to przy aplikacji pracującej z lokalizacją w tle. Część problemów nie pojawia się po pięciu minutach używania programu. Widać je dopiero podczas dłuższej jazdy, postoju, spaceru albo po kilku godzinach pracy. Dlatego testy w rzeczywistych warunkach są bardzo ważną częścią całego projektu.
Nie chodzi o stworzenie kolejnej aplikacji APRS
mAPRS nie ma konkurować liczbą funkcji z każdym istniejącym programem. Nie taki był cel projektu. Chcę przede wszystkim rozwiązać problem, który sam napotkałem podczas korzystania z APRS. Jeżeli aplikacja potrafi sama zauważyć, że właśnie jadę, po co mam ręcznie zmieniać symbol samochodu? Jeżeli chwilę później ruszam pieszo, dlaczego znowu mam wchodzić w ustawienia? A jeżeli wróciłem do domu, telefon również może to rozpoznać. Właśnie ta idea jest dla mnie najważniejsza: APRS ma dostosowywać się do tego, co robi użytkownik, a nie użytkownik do aplikacji.
Projekt, na którym sam wiele się uczę
mAPRS jest jednocześnie projektem użytkowym i technicznym. Tworząc go, muszę łączyć kilka zupełnie różnych obszarów: działanie systemu, lokalizację, pracę aplikacji w tle, komunikację sieciową, specyfikę APRS, analizę ruchu oraz optymalizację zużycia energii. Do tego dochodzi przygotowywanie kolejnych wersji, testy oraz cały proces dystrybucji aplikacji. Każdy kolejny etap odkrywa nowe problemy, których często nie widać na początku. I właśnie to jest w tym projekcie najciekawsze. mAPRS nie powstał jako gotowy produkt zaplanowany od pierwszego do ostatniego ekranu. Rozwija się razem z kolejnymi testami i pomysłami wynikającymi z rzeczywistego korzystania z aplikacji.
Co dalej z mAPRS?
Podstawowa idea pozostaje bez zmian: maksymalnie zautomatyzować pracę z APRS przy zachowaniu kontroli nad tym, co aplikacja robi. Kolejne etapy rozwoju dotyczą przede wszystkim udoskonalania rozpoznawania sytuacji, poprawnego przełączania profili, działania lokalizacji, sposobu raportowania pozycji oraz ograniczania zużycia energii. Chcę również, aby użytkownik miał jasną informację o tym, co aktualnie robi aplikacja i jakie dane przekazuje do APRS-IS. Nie zależy mi natomiast na dokładaniu funkcji tylko po to, aby ich lista była dłuższa. Wolę, aby kilka najważniejszych mechanizmów działało naprawdę dobrze.
mAPRS – mniej przełączania, więcej APRS
Projekt rozpoczął się od bardzo prostej irytacji: ciągłego ręcznego przełączania ustawień APRS. Z tego powstał pomysł aplikacji, która obserwuje sytuację i sama potrafi zdecydować, w jaki sposób moja stacja powinna być w danym momencie prezentowana. Jadę. Idę. Jestem w domu. mAPRS ma to rozpoznać i odpowiednio dobrać ikonę, komentarz oraz symbol APRS. Bez pamiętania o przełącznikach. Bez każdorazowego wchodzenia w ustawienia. To właśnie jest główna idea mAPRS — i od niej zaczęła się cała reszta projektu.
Polityka prywatności aplikacji mAPRS znajduje się tutaj.