Program do awizacji Android - kierowca, portiernia i słaby zasięg

Program do awizacji Android w pracy kierowcy i portierni

Program do awizacji Android przenosi na telefon dwie czynności, które wcześniej wymagały rozmowy z dyspozytorem albo wizyty w okienku portierni: zgłoszenie przyjazdu i potwierdzenie wjazdu. Aplikacja nie zastępuje platformy awizacyjnej. Jest jednym z kanałów: przez niego kierowca i ochrona zapisują zdarzenia w tej samej bazie, w której dyspozytor planuje rampy.

Porównanie z pełną platformą i kalendarzem okien znajduje się w tekście o tym, kiedy wystarczy system awizacji VSS.net na Androida. Tutaj opisano stronę operacyjną: co robi kierowca, co robi portiernia i jak aplikacja zachowuje się przy niestabilnej sieci. Proces zgłoszenia po stronie przewoźnika omawia artykuł o awizacji transportu.

Poniższe mechanizmy opisują sposób, w jaki aplikacje mobilne tego typu zwykle się buduje. Zakres funkcji konkretnego wdrożenia potwierdza demo systemu awizacji online oraz analiza przedwdrożeniowa, a nazwy w przykładach kodu są umowne.

Rejestracja przyjazdu przez kierowcę

Kierowca otwiera aplikację, wybiera awizację przypisaną do swojego pojazdu i potwierdza przyjazd. Przy dostawie bez wcześniejszej rezerwacji wpisuje podstawowe dane transportu, a zgłoszenie trafia do dyspozytora jako wizyta wymagająca decyzji. Po wjeździe na teren zakładu na bieżąco aktualizuje status realizacji zlecenia.

Dane zgłoszenia i status dostawy

Formularz w telefonie musi być krótszy niż w portalu dyspozytora, bo kierowca wpisuje dane w kabinie, często jedną ręką. Wszystko, co system może ustalić sam, powinien ustalić bez pytania: przewoźnika z konta, magazyn z wybranej awizacji, termin z rezerwacji. Zostają cztery pola, których nikt inny nie zna.

• Numer rejestracyjny - pozwala odnaleźć awizację przy bramie, gdy kod QR jest nieczytelny albo nie został wydrukowany.
• Dane transportu - podstawowe informacje o dostawie, wypełniane wyłącznie przy zgłoszeniu bez wcześniejszej rezerwacji.
• Numer telefonu - adres dla powiadomień o zmianie terminu lub rampy.
• Status dostawy - bieżący etap wizyty, który kierowca potwierdza dotknięciem, a nie wpisywaniem.

Statusy nie są własnością aplikacji, tylko całej awizacji. Kierowca zmienia je w telefonie, portiernia przy bramie, a dyspozytor w kalendarzu, więc lista musi być wspólna dla wszystkich trzech ról. Poniższe zestawienie odpowiada widokowi dziennego kalendarza transportów w Studio VSS.net.

Kontakt z centralą i nawigacja

Aplikacja pokazuje kierowcy miejsce dostawy z nawigacją GPS, dzięki czemu nie musi on szukać właściwej bramy na rozległym terenie. Jeśli harmonogram się zmienia, kierowca kontaktuje się z centralą bezpośrednio z aplikacji. Koszt zaniedbań w tym obszarze opisuje artykuł o kosztach opóźnień w komunikacji z kierowcami.

Kod QR i identyfikacja pojazdu przy bramie

Po wpisaniu numeru rejestracyjnego lub zeskanowaniu kodu QR z dokumentu dostawy system odnajduje awizację i umożliwia potwierdzenie przyjazdu przy bramie. Kod skraca ten krok do jednego odczytu, a portiernia widzi od razu termin i rampę, a także nazwę przewoźnika.

Zawartość kodu i odczyt kamerą

Kod QR powinien zawierać numer awizacji i podpis, a nie dane osobowe kierowcy. Bez podpisu każdy mógłby wydrukować kod z dowolnym numerem i próbować wjechać na cudzą wizytę. Odczyt kamerą realizuje się zwykle biblioteką skanującą kody; opis takiego mechanizmu zawiera dokumentacja skanowania kodów kreskowych w ML Kit na Androidzie. Podpis weryfikuje serwer, żeby klucz nigdy nie trafiał do telefonu.

using System;
using System.Security.Cryptography;
using System.Text;

public static class KodAwizacji
{
    // Przykładowy format kodu: "AW:{numer}:{podpis}" - klucz pochodzi z konfiguracji serwera
    public static bool Zweryfikuj(string tresc, byte[] klucz, out string numerAwizacji)
    {
        numerAwizacji = null;
        var czesci = tresc.Split(':');
        if (czesci.Length != 3 || czesci[0] != "AW") return false;

        using var hmac = new HMACSHA256(klucz);
        var oczekiwany = hmac.ComputeHash(Encoding.UTF8.GetBytes(czesci[0] + ":" + czesci[1]));

        byte[] podany;
        try { podany = Convert.FromBase64String(czesci[2]); }
        catch (FormatException) { return false; }

        if (!CryptographicOperations.FixedTimeEquals(oczekiwany, podany)) return false;
        numerAwizacji = czesci[1];
        return true;
    }
}

Porównanie w stałym czasie zapobiega odgadywaniu podpisu po czasie odpowiedzi. Poprawny podpis dowodzi tylko tego, że kod wydał system. O wjeździe nadal decyduje status awizacji zapisany na serwerze.

Reguła: kod QR identyfikuje wizytę, ale zgodę na wjazd wydaje status awizacji na serwerze.

Numer rejestracyjny i inne sposoby identyfikacji

Kod bywa zniszczony, zalany deszczem albo w ogóle nieobecny, bo dokument dostawy przyszedł od innego podmiotu. Dlatego system dopuszcza równoległe ścieżki identyfikacji i nie uzależnia wjazdu od jednej z nich.

• Numer rejestracyjny - wpisany przy awizacji i wyszukiwany ręcznie przez portiernię lub kierowcę.
• Kod QR - odczyt z dokumentu dostawy albo potwierdzenia rezerwacji.
• Czytnik RFID - urządzenie zainstalowane przy bramie wjazdowej.
• Rozpoznawanie tablic (LPR) - kamera przy bramie odczytuje numer, a zdjęcie jest przypisywane do awizacji.

Praca przy słabym zasięgu

Blacha kontenerów oraz stalowe regały tłumią sygnał tam, gdzie kierowca stoi w kolejce do bramy. Aplikacja, która czeka na odpowiedź serwera po każdym dotknięciu ekranu, blokuje wtedy człowieka i powoduje powtórne zgłoszenia. Bezpieczniejszy wzorzec polega na tym, że zdarzenie zapisuje się najpierw na urządzeniu, a wysyła później.

Kolejka zdarzeń na urządzeniu

Każde działanie, czyli zgłoszenie przyjazdu albo zmiana statusu, trafia do lokalnej bazy w telefonie z unikalnym identyfikatorem zdarzenia i czasem urządzenia. Osobne zadanie w tle wysyła zdarzenia po kolei, gdy sieć wróci. Na Androidzie służy do tego WorkManager i zadania w tle, które przetrwają zamknięcie aplikacji i restart urządzenia.

Stan połączenia można odczytać w aplikacji, opisuje to dokumentacja o zarządzaniu użyciem sieci w Androidzie. Sam odczyt nie przesądza jednak, że serwer odpowie, więc decyzję o ponowieniu podejmuje zadanie w tle po nieudanej próbie, a nie po sprawdzeniu ikony zasięgu.

Powtórzone zdarzenia i idempotencja

Wysyłka może się powtórzyć, jeśli serwer odebrał zdarzenie, ale telefon nie dostał potwierdzenia. Bez zabezpieczenia w bazie pojawiłyby się dwa wjazdy tego samego pojazdu. Zabezpieczeniem jest unikalny indeks na identyfikatorze zdarzenia, generowanym w telefonie. Opcja IGNORE_DUP_KEY w poleceniu CREATE INDEX sprawia, że powtórzony zapis jest pomijany zamiast przerywać całą operację.

CREATE UNIQUE INDEX UX_ZdarzeniaAwizacji_IdZdarzenia
    ON dbo.ZdarzeniaAwizacji (IdZdarzenia)
    WITH (IGNORE_DUP_KEY = ON);

INSERT INTO dbo.ZdarzeniaAwizacji (IdZdarzenia, AwizacjaId, Typ, CzasUrzadzenia, CzasSerwera)
VALUES (@IdZdarzenia, @AwizacjaId, @Typ, @CzasUrzadzenia, SYSUTCDATETIME());

Drugi zapis z tym samym identyfikatorem nie zmienia tabeli, a serwer może odpowiedzieć aplikacji sukcesem, bo zdarzenie już istnieje. Telefon usuwa je wtedy z kolejki i przechodzi do następnego.

Reguła: zdarzenie ma dwa czasy (urządzenia i serwera), a raport terminowości opiera się na pierwszym, dopóki różnica nie przekracza ustalonego progu.

Powiadomienia i uprawnienia aplikacji na urządzeniu

Powiadomienia o zmianie terminu lub rampy trafiają do kierowcy jako e-mail albo SMS, także wtedy, gdy nie ma otwartej aplikacji. Aplikacja mobilna dla kierowcy może prezentować informacje w wybranym języku, co ogranicza barierę językową w przewozach międzynarodowych. Sposób prowadzenia takiej komunikacji opisuje tekst o wielojęzycznej komunikacji VSS z kierowcami.

Android wymaga zgody użytkownika na dostęp do aparatu i lokalizacji w czasie działania aplikacji, co opisuje dokumentacja żądania uprawnień w czasie działania. Poprawnie zbudowana aplikacja prosi o zgodę dopiero wtedy, gdy kierowca wybiera funkcję, która jej potrzebuje, i działa dalej po odmowie.

Dane kierowcy i bezpieczeństwo połączenia

Aplikacja kierowcy przechowuje niewiele danych osobowych: imię i nazwisko oraz numer telefonu. Numer rejestracyjny należy do pojazdu, ale pozwala też powiązać wizytę z konkretną osobą. Im mniej pól, tym mniejsze ryzyko w razie utraty telefonu i tym prostsza odpowiedź na pytania o ochronę danych. Pola, których nie potrzebuje żaden proces, nie powinny w ogóle trafiać do formularza.

Zakres kont i uprawnień ustawia administrator systemu. Portiernia i dyspozytor mają osobne role, a przewoźnik dostaje własne konto, w którym widzi zwykle wyłącznie własne zgłoszenia. Dla kierowców z tej samej firmy transportowej można nadać węższe uprawnienia niż dla jej dyspozytora. Mechanizm opisuje artykuł o module Administrator w VSS.net.

• Dane w telefonie - lokalna kolejka trzyma zdarzenia tylko do czasu potwierdzenia przez serwer.
• Dane na serwerze - pełna historia wizyt pozostaje w bazie awizacji, do której dostęp mają role uprawnione.

Wdrożenie aplikacji na urządzeniach kierowców i portierni

Firma transportowa rzadko zgodzi się na instalację kolejnej aplikacji na telefonach wszystkich kierowców. Dlatego kierowca może pobrać aplikację mobilną VSS.net albo skorzystać z przeglądarki na smartfonie. Portiernia pracuje na urządzeniu zarządzanym przez zakład, więc tutaj obowiązują inne zasady niż przy telefonach zewnętrznych kierowców.

Dobór urządzeń i zarządzanie flotą terminali omawia artykuł o aplikacji magazynowej na Androida, ponieważ te same zasady dotyczą tabletu przy bramie. Wersję webową i mobilną awizacji opisuje tekst o aplikacji do awizacji dostaw, a integrację z WMS oraz ERP omawia artykuł o awizacjach VSS.net jako module produktowym. Opis od strony producenta zawiera strona aplikacja awizacyjna SoftwareStudio.

Testowanie aplikacji przed uruchomieniem na placu

Błąd w kolejce zdarzeń wychodzi dopiero wtedy, gdy kilkanaście pojazdów stoi przed bramą, a sieć nagle znika. Dlatego scenariusze braku zasięgu sprawdza się przed wdrożeniem na jednej bramie, a nie po uruchomieniu na całym terenie. Testy nie wymagają specjalnych narzędzi: wystarcza kilka telefonów i tryb samolotowy.

Wynik każdego scenariusza zapisuje się w protokole odbioru. Przy okazji warto zweryfikować, czy kierowca widzi zrozumiały komunikat, a nie kod błędu. Definicję samej wizyty i jej etapów zawiera artykuł co to jest awizacja w transporcie, a plan testów powinien korzystać z tych samych nazw statusów, których używa dyspozytor.