Tworzenie aplikacji mobilnych - natywne, hybrydowe i webowe w magazynie

Tworzenie aplikacji mobilnych i trzy podejścia technologiczne

Pierwsza decyzja przy tworzeniu aplikacji mobilnych dotyczy sposobu jej budowy. Aplikacja natywna powstaje w narzędziach danego systemu: dla Androida w Kotlinie albo Javie, dla iOS w Swifcie. Aplikacja hybrydowa, zwana też multiplatformową, opiera się na frameworku takim jak React Native albo Flutter, który z jednego kodu buduje wersje na oba główne systemy. Aplikacja webowa działa w przeglądarce telefonu lub w kontrolce WebView osadzonej w prostej powłoce.

Każde podejście ma inne koszty. Natywna wersja daje pełny dostęp do sprzętu i najlepszą kontrolę nad wydajnością, ale wymaga osobnego kodu na każdy system. Rozwiązanie hybrydowe skraca czas pracy, choć dostęp do mniej typowych funkcji urządzenia, na przykład skanera w terminalu przemysłowym, bywa wolniejszy do zbudowania. Aplikacja webowa nie wymaga instalacji, lecz ogranicza dostęp do sprzętu.

Reguła: technologię wybiera się na podstawie urządzeń, na których aplikacja będzie pracować, a nie na podstawie mody. Terminal ze skanerem wymaga innych założeń niż telefon klienta.

Aplikacja mobilna czy webowa w firmie

W systemach firmowych podział wynika ze stanowiska. Pracownik biurowy siedzi przy komputerze, więc wystarcza mu przeglądarka. Magazynier chodzi po hali z terminalem w ręku. Skanuje kody i potwierdza operacje przy regale, więc potrzebuje aplikacji mobilnej. Studio WMS.net występuje w wariantach Framework i web oraz Android, które korzystają z tej samej bazy danych i są dobierane do stanowiska. Ten podział opisuje artykuł o aplikacjach WMS i ich architekturze.

Kiedy aplikacja webowa wystarcza, tworzenie osobnej wersji mobilnej jest zbędnym kosztem. Wystarcza wtedy przeglądarka i układ interfejsu dopasowany do ekranu telefonu. Podstawy budowy takich aplikacji przedstawia tekst o aplikacji webowej. Gdy jednak potrzebny jest skaner sprzętowy, praca bez zasięgu albo tryb kiosku, sensowna jest aplikacja instalowana na urządzeniu.

Aplikacje dla dwóch głównych systemów opisuje tekst o software house dla iOS, a mobilne narzędzia dla działu sprzedaży omawia artykuł o mobilnym CRM. Zadania kierowcy i spedytora przedstawia strona aplikacji mobilnej dla kierowcy i spedytora.

Interfejs na hali i etapy projektu

Ekran terminala magazynowego projektuje się inaczej niż ekran telefonu konsumenta. Operator pracuje w rękawicach, często jedną ręką, i patrzy na ekran przez ułamek sekundy. Dlatego każdy ekran obsługuje jedną czynność, a przyciski mają duże pole dotyku. Wynik skanowania jest widoczny z odległości ramienia, a błąd sygnalizowany dźwiękiem i kolorem.

• Jedna czynność na ekran - przyjęcie i przesunięcie oraz kompletacja mają osobne widoki, a nie wspólny formularz z wieloma polami.
• Duże pola dotyku i czytelny kontrast - przyciski dają się nacisnąć w rękawicy, a tekst odczytać w słabym oświetleniu hali.
• Potwierdzenie dźwiękiem - sygnał odróżnia poprawny odczyt od błędnego bez patrzenia na ekran.
• Minimum pisania - dane pochodzą ze skanera albo z listy wyboru, a klawiatura ekranowa pojawia się wyjątkowo.

Projekt aplikacji mobilnej przebiega w kilku etapach. Wykonawca zaczyna od konsultacji i analizy potrzeb. Potem projektuje interfejs oraz doświadczenie użytkownika. Następnie programuje i testuje, a na końcu wdraża aplikację i zapewnia jej rozwój po uruchomieniu. Tabela porządkuje te etapy.

Testy na urządzeniach docelowych są niezbędne, bo emulator nie odtwarza modułu skanującego ani warunków hali. Test w chłodni pokazuje, jak zachowuje się ekran dotykowy przy niskiej temperaturze, a test w strefie bez zasięgu sprawdza kolejkę offline. Pilotaż na jednej zmianie ujawnia problemy, których nie widać w biurze.

Android w magazynie - skaner i terminal

Terminal przemysłowy z Androidem różni się od zwykłego telefonu konstrukcją. Ma wzmocnioną obudowę i wymienny akumulator oraz dedykowany moduł skanujący, który czyta kody 1D i 2D szybciej niż kamera. Aplikacja tworzona dla magazynu musi ten skaner obsłużyć, a producenci sprzętu udostępniają go zwykle jako klawiaturę wirtualną lub przez komunikat systemowy, który aplikacja przechwytuje.

Wybór sprzętu i sposób odczytu kodów opisuje artykuł o kolektorze danych z Androidem, a działanie aplikacji w codziennej pracy przedstawia tekst o aplikacji magazynowej na Androidzie. Starsze terminale z systemami Windows CE i Windows Mobile zastępuje się dziś urządzeniami z Androidem, o czym mówi artykuł o Windows Mobile w magazynie WMS. Na stronie producenta znajduje się także przegląd terminali radiowych.

Wersja Androida na terminalu decyduje o okresie poprawek bezpieczeństwa i o zgodności z narzędziem MDM. Aplikacja deklaruje minimalną wersję systemu, na której działa, oraz wersję docelową, względem której ją testowano. Zbyt niska wartość minimalna wydłuża listę przypadków testowych, a zbyt wysoka wyklucza starsze terminale w magazynie. Przegląd wydań systemu zawiera dokumentacja wersji Androida.

Firma ustala jedną minimalną wersję dla całej floty i pilnuje jej przy zakupie nowego sprzętu. Przed zamówieniem terminali warto zapytać producenta o okres wsparcia aktualizacjami, bo urządzenie bez poprawek bezpieczeństwa staje się problemem dla działu IT, nawet gdy fizycznie nadal działa.

Skanowanie musi być odporne na błędy operatora. Aplikacja sprawdza cyfrę kontrolną kodu, porównuje odczytany numer z listą oczekiwanych pozycji i sygnalizuje niezgodność dźwiękiem oraz kolorem ekranu. Potwierdzenie operacji wysyła się do serwera dopiero po przejściu walidacji lokalnej, dzięki czemu terminal nie obciąża sieci błędnymi odczytami.

Praca offline i synchronizacja z serwerem

Hala magazynowa ma strefy bez zasięgu Wi-Fi: chłodnie, wnęki między regałami, zamknięte naczepy. Aplikacja, która przestaje działać bez sieci, blokuje pracę, więc operacje zapisuje się najpierw lokalnie, a wysyła po odzyskaniu połączenia. Na Androidzie lokalną bazę zapewnia biblioteka Room, a wysyłkę w tle harmonogramuje WorkManager.

@Entity(tableName = "operacja")
data class Operacja(
    @PrimaryKey val id: String,      // UUID nadany na terminalu
    val typ: String,
    val ladunek: String,             // dane operacji w formacie JSON
    val utworzono: Long,
    val wyslano: Boolean = false
)

@Dao
interface OperacjaDao {
    @Query("SELECT * FROM operacja WHERE wyslano = 0 ORDER BY utworzono")
    suspend fun oczekujace(): List<Operacja>

    @Query("UPDATE operacja SET wyslano = 1 WHERE id = :id")
    suspend fun oznaczJakoWyslana(id: String)
}

Kolejna operacja ma identyfikator nadany na terminalu, więc serwer potrafi rozpoznać powtórkę. Po awarii połączenia terminal może wysłać ten sam komunikat drugi raz, a zapis nie może wtedy zwielokrotnić przyjęcia towaru. Po stronie SQL Server pilnuje tego klucz główny, który odrzuca duplikat.

CREATE TABLE dbo.OperacjaTerminala (
    OperacjaId   uniqueidentifier PRIMARY KEY,
    Typ          varchar(30)   NOT NULL,
    Ladunek      nvarchar(max) NOT NULL,
    PrzyjetoUtc  datetime2(0)  NOT NULL DEFAULT SYSUTCDATETIME()
);

INSERT INTO dbo.OperacjaTerminala (OperacjaId, Typ, Ladunek)
SELECT @OperacjaId, @Typ, @Ladunek
WHERE NOT EXISTS (
    SELECT 1 FROM dbo.OperacjaTerminala WHERE OperacjaId = @OperacjaId
);

Warunek NOT EXISTS zapewnia, że powtórzone żądanie nic nie zmieni, a klucz główny chroni przed równoległym wstawieniem dwóch takich samych identyfikatorów. Dokumentacja opisuje bibliotekę Room do lokalnego zapisu danych, a wysyłkę w tle omawia przewodnik po WorkManager. Nazwy tabel i klas w przykładach są umowne i nie odzwierciedlają struktury żadnego produktu.

Dystrybucja aplikacji i podpisywanie

Gotowy pakiet aplikacji musi zostać podpisany kluczem, a wynik trafić na urządzenia. Podpis potwierdza pochodzenie pakietu, a system odrzuca aktualizację podpisaną innym kluczem niż pierwotna instalacja. Utrata klucza oznacza więc konieczność przeinstalowania aplikacji, dlatego klucz przechowuje się w bezpiecznym miejscu i z kopią. Zasady opisuje dokumentacja podpisywania aplikacji na Androidzie.

Każda nowa wersja ma większy numer kodu wersji. System nie pozwoli zainstalować pakietu o numerze niższym niż istniejący, co chroni przed omyłkowym cofnięciem aplikacji. Numer wersji zapisuje się w skrypcie budowania, żeby nie zależał od ręcznej edycji.

Instalacja ręczna sprawdza się przy pilotażu, ale przy kilkudziesięciu terminalach zawodzi. Wtedy wchodzą do gry systemy zarządzania urządzeniami mobilnymi, opisane szerzej w artykule o programie magazynowym na Androida i flocie MDM.

Zarządzanie flotą i aktualizacje MDM

System MDM rejestruje urządzenia, przypisuje im grupy i wymusza ustawienia. Administrator zapisuje konfigurację raz, a terminale ją pobierają. Nowa wersja aplikacji trafia do grupy pilotażowej, a po kilku dniach bez zgłoszeń do pozostałych, co ogranicza skutki ewentualnego błędu w wydaniu.

Android udostępnia do tego zestaw interfejsów opisany w dokumentacji Android Enterprise. Tryb kiosku ogranicza ekran do wskazanej aplikacji, co blokuje pracownikowi możliwość zmiany ustawień lub uruchomienia innego programu. Przy pracy zmianowej terminal współdzielony przez kilka osób zyskuje logowanie użytkownika w aplikacji, a nie na poziomie systemu.

• Grupa pilotażowa - kilka terminali, które dostają nową wersję jako pierwsze i wykrywają błędy przed wdrożeniem na całą flotę.
• Okno aktualizacji - przedział czasu poza szczytem pracy, w którym terminale pobierają i instalują pakiety.

Po stronie serwera warto prowadzić rejestr, z którego wynika, jaką wersję aplikacji ma każde urządzenie. Przy zmianie kontraktu interfejsu serwer musi obsługiwać dwie wersje jednocześnie, bo część terminali zaktualizuje się później. Reguła zgodności wstecznej oszczędza magazynowi przestojów w dniu wydania.

Bezpieczeństwo i integracja z systemami firmowymi

Aplikacja mobilna nie łączy się z bazą wprost. Komunikuje się z serwerem przez interfejs REST, a ten weryfikuje uprawnienia i wykonuje operacje w bazie. Połączenie odbywa się przez HTTPS, a token dostępu użytkownika przechowuje się w bezpiecznym magazynie kluczy systemu, a nie w zwykłym pliku ustawień.

Integracja z systemami ERP i WMS oraz CRM odbywa się po stronie serwera, tak by aplikacja mobilna pozostała cienkim klientem. Zmiana w ERP nie wymaga wtedy nowej wersji aplikacji na terminalach. Dane wrażliwe, na przykład osobowe, ograniczają się do niezbędnego minimum, a dziennik zdarzeń rejestruje, kto i kiedy wykonał operację.

Firma z Poznania, SoftwareStudio, oferuje aplikacje mobilne zintegrowane z systemami ERP i WMS oraz CRM oraz pracujące z danymi w chmurze. Aplikacje działają na Androidzie i iOS, a zakres funkcji ustala się na podstawie analizy procesu. Kontakt z zespołem odbywa się pod numerem +48 533 322 626, a przykładowe systemy można obejrzeć w demo online.