Aplikacje na Androida.
Do pracy i dla klientów.

Gdy grupa użytkowników pracuje na telefonach z Androidem, a zadanie wymaga regularnego korzystania z urządzenia. Może to być przyjęcie zlecenia przez technika, potwierdzenie odbioru przesyłki lub sprawdzenie rezerwacji przez klienta. Najpierw określamy, która czynność powinna działać od początku do końca.

Lista obsługiwanych urządzeń jest częścią ustaleń. Firmowy telefon ze starszym systemem i nowy telefon klienta mogą mieć inne możliwości. Zamiast opisywać produkt liczbą ekranów, rozpisujemy przypadki użycia, potrzebne dane oraz ograniczenia sprzętu.

W aplikacji pracownik widzi przydzielone zadania, a koordynator w panelu widzi ich etap i osobę odpowiedzialną. Przekazanie statusu wymaga potwierdzenia przez system. Samo naciśnięcie przycisku na telefonie nie powinno udawać, że zapis na serwerze już się powiódł.

Określamy właściciela informacji i reakcję na konflikt. Jeśli dwie osoby zmieniają jedną sprawę, potrzebna jest czytelna odpowiedź: zapis przyjęty, nowsza wersja do sprawdzenia albo zmiana wymagająca zatwierdzenia. Integracje z obecnym oprogramowaniem oceniamy po dokumentacji konkretnego systemu.

Zdjęcie usterki, skan kodu lub komunikat o nowym zadaniu mogą skrócić drogę do wykonania pracy. Każdą funkcję urządzenia wiążemy z konkretnym celem. Użytkownik powinien rozumieć, dlaczego aplikacja prosi o dostęp i co może zrobić, kiedy go nie udzieli.

Android 13 i nowsze wymagają zgody na większość powiadomień aplikacji. Dlatego ważny status pozostaje także wewnątrz produktu, a push jest dodatkową informacją. Nie opieramy zakończenia zlecenia na założeniu, że komunikat na pewno dotarł na telefon.

Dla pracy poza biurem określamy, które dane można odczytać bez połączenia i które czynności można przygotować do późniejszego wysłania. Osobno ustalamy bezpieczeństwo informacji przechowywanych na urządzeniu oraz sposób wylogowania. Offline nie jest automatycznie dostępny dla całego systemu.

Przykładowo technik może przygotować opis wizyty, ale zatwierdzenie kosztu wymaga odpowiedzi serwera. Interfejs rozróżnia szkic, wysyłanie, przyjęcie i błąd. Ponowienie nie może tworzyć drugiego identycznego zgłoszenia; to warunek do uwzględnienia w projekcie i testach.

Zakres testów obejmuje uzgodnione telefony, orientację ekranu, powrót do aplikacji, uprawnienia i przerwane połączenie. Sprawdzamy także dane błędne, puste listy oraz utratę dostępu do konta. Odbiór opieramy na scenariuszach, które odpowiadają rzeczywistej pracy firmy.

Sposób dystrybucji zależy od odbiorców. Produkt dla klientów i narzędzie na firmowe urządzenia mogą wymagać innego przygotowania. Konto wydawcy, dostęp do materiałów i odpowiedzialność za aktualizacje ustalamy przed planowaniem startu.

Aplikację mobilną wyceniamy indywidualnie. Na cenę wpływają funkcje telefonu, konta, panel, integracje, wymagania offline i liczba uzgodnionych środowisk testowych. Porównujemy pełny zakres pierwszej wersji, a nie sam koszt wykonania widoków.

Próg 7 000 zł netto dotyczy małej aplikacji webowej, nie pełnej wersji na Androida. Jeśli ważny jest niewielki budżet startowy, rozważamy ograniczenie procesu albo wariant przeglądarkowy. Wybór powinien zachować użyteczny rezultat dla użytkownika.

Te artykuły pomogą opisać reguły, dane i sposób sprawdzenia aplikacji. Wybierz zagadnienie związane z pracą Twojej firmy.

Wskaż typy urządzeń używanych przez odbiorców i główny przebieg aplikacji. Ustal powiązanie z panelem oraz dostęp do danych.

Portale dla gości, uczniów, klientów nieruchomości i uczestników wydarzeń: informacje dostępne po właściwej stronie procesu. Przykłady interfejsów pozostają projektami; zakres produkcyjny, platformy i dane ustalamy osobno.

Osobny dział porządkuje funkcje produktu: konta, powiadomienia, płatności, dane bez połączenia i wykorzystanie urządzenia. Wybierz poddział, który odpowiada na zadanie Twojej firmy.