Aplikacje desktopowe, mobilne i webowe na egzaminie INF.04

Warstwa prezentacji wyświetla stan i przekazuje zdarzenia użytkownika. Logika aplikacji realizuje przypadki użycia, na przykład zapis zadania lub obliczenie ceny. Warstwa danych komunikuje się z bazą, plikiem albo usługą sieciową. Taki podział ogranicza sytuacje, w których obsługa kliknięcia jednocześnie buduje SQL, liczy wynik i formatuje komunikat.

Wzorce takie jak MVC, MVVM czy architektura warstwowa inaczej nazywają elementy, ale rozwiązują podobny problem: oddzielają widok od stanu i reguł. Nazwa wzorca jest mniej ważna niż kierunek zależności. Interfejs powinien korzystać z jawnego modelu lub kontrolera, a dostęp do danych powinien dać się zastąpić w teście.

Stan interfejsu opisuje to, co ekran ma teraz pokazać, na przykład ładowanie, listę wyników, pusty wynik albo błąd. Zdarzenie, takie jak kliknięcie odśwież, uruchamia zmianę, a nowy stan wraca do widoku. Jedno źródło prawdy zmniejsza ryzyko, że licznik pokazuje inną wartość niż lista, z której został obliczony.

Dane trwałe zapisuje się w bazie, pliku lub ustawieniach, a dane zdalne pobiera przez API. Pamięć podręczna przyspiesza odczyt, ale wymaga zasad odświeżania. Obrót ekranu, uśpienie aplikacji i zamknięcie procesu pokazują, które informacje były tylko chwilowym stanem widoku, a które powinny zostać zapisane.

Formularz powinien mieć jednoznaczne etykiety, kolejność fokusu, czytelny komunikat walidacji i informację o trwającej operacji. Przycisk wysyłający dane blokuje się albo zabezpiecza przed podwójnym żądaniem. Układ powinien reagować na zmianę rozmiaru okna, skalę tekstu i orientację, a wszystkie ważne funkcje powinny być dostępne także z klawiatury lub technologii asystującej.

Ekran listy potrzebuje co najmniej stanów ładowania, sukcesu, pustej odpowiedzi i błędu. Sam spinner bez końca nie wyjaśnia problemu. Komunikat powinien mówić, co użytkownik może zrobić, na przykład spróbować ponownie, poprawić dane lub sprawdzić połączenie, bez ujawniania wewnętrznego śladu stosu.

Klient API wysyła żądanie, interpretuje kod odpowiedzi i zamienia dane, często w JSON, na model aplikacji. Walidacja po stronie interfejsu poprawia wygodę, ale serwer nadal musi samodzielnie sprawdzać dane. Błąd 400 oznacza problem z żądaniem, 401 brak prawidłowego uwierzytelnienia, 404 brak zasobu, a kody od 500 problem po stronie usługi.

Brak sieci, przekroczony czas i odpowiedź serwera to różne sytuacje. Ponowienie może pomóc przy chwilowej awarii, ale nie powinno bez końca powtarzać operacji tworzącej płatność lub rekord. Dane wejściowe warto zachować, błąd zapisać diagnostycznie, a użytkownikowi pokazać krótki komunikat i bezpieczną akcję.

Aplikacja desktopowa dobrze wykorzystuje duży ekran, pliki i urządzenia komputera oraz może pracować bez sieci. Aplikacja mobilna korzysta z dotyku, aparatu, lokalizacji i powiadomień, ale musi uwzględniać uprawnienia, mały ekran, baterię i przerywanie pracy przez system. Aplikacja webowa działa przez przeglądarkę i łatwo ją aktualizować centralnie, lecz podlega ograniczeniom przeglądarki i jakości połączenia.

Framework wieloplatformowy pozwala współdzielić część kodu, ale nie usuwa różnic w nawigacji, uprawnieniach ani zachowaniu systemu. Dobór powinien wynikać z urządzeń docelowych, dostępu do sprzętu, trybu offline, wymaganej wydajności, kompetencji zespołu i kosztu utrzymania. Testy obejmują logikę, integrację z danymi, interfejs oraz zachowanie na obsługiwanych rozmiarach ekranu i wersjach platformy.