Jetpack Compose vs React Native dla funkcji urządzeń i trybu offline

Co naprawdę porównujesz

Kiedy ludzie mówią „funkcje urządzenia”, zwykle mają na myśli elementy łączące aplikację z samym telefonem: robienie zdjęć, GPS, skanowanie Bluetooth, powiadomienia push, dostęp do plików (pobrane pliki, PDFy, załączniki) i zadania w tle, takie jak liczenie kroków czy monitorowanie stanu sieci. Prawdziwe pytanie to nie „czy to jest możliwe”, ale „jak bezpośrednia jest droga do sprzętu i jak przewidywalne to będzie na różnych modelach i wersjach systemu”.

Tryb offline zmienia cały zakres pracy. To nie jest przełącznik „działa bez internetu”. Potrzebujesz lokalnego magazynu, jasnej decyzji, które dane mogą być przestarzałe, i reguł rozwiązywania konfliktów (na przykład: użytkownik edytuje zamówienie offline, a to samo zamówienie zostało zaktualizowane na serwerze). Kiedy dodasz synchronizację, projektujesz mały system, a nie tylko ekran.

Compose kontra React Native bywa przedstawiane jako natywny vs cross-platform, ale przy pracy offline i z urządzeniami różnice wychodzą na łączeniach: ile mostów, wtyczek i obejść musisz użyć oraz jak łatwo jest debugować, gdy coś przestaje działać na konkretnym modelu telefonu.

„Wydajność” też trzeba zdefiniować w kategoriach użytkownika: czas uruchomienia, przewijanie i pisanie (szczególnie przy długich listach i formularzach), zużycie baterii i nagrzewanie (cicha praca w tle, która pożera energię) oraz stabilność (crashe, zamrożenia, błędy UI). Z obu podejść można dostarczyć świetne aplikacje. Różnica to poziom pewności: większa kontrola systemowa, czy jeden kod dla wielu platform z większą ilością elementów na krawędziach.

Dostęp do funkcji urządzeń: jak różni się instalacja rur

Główna różnica tu nie tkwi w komponentach UI, ale w tym, jak aplikacja dociera do kamery, Bluetootha, lokalizacji, plików i usług w tle.

Na Androidzie Jetpack Compose jest warstwą UI. Twój kod nadal używa normalnego SDK Androida i tych samych natywnych bibliotek, co „klasyczna” aplikacja Android. Dostęp do funkcji urządzeń jest bezpośredni: wywołujesz API Androida, obsługujesz uprawnienia i integrujesz SDK bez warstwy tłumaczącej. Jeśli vendor udostępnia bibliotekę do skanera lub narzędzie MDM, zwykle możesz ją dodać i użyć od razu.

React Native uruchamia JavaScript dla większości logiki aplikacji, więc dostęp do urządzeń przechodzi przez natywne moduły. Moduł to mały fragment kodu Android (Kotlin/Java) i iOS (Swift/Obj‑C), który wystawia funkcję urządzenia do JavaScript. Wiele typowych funkcji jest już pokrytych istniejącymi modułami, ale wciąż polegasz na moście (albo nowszym podejściu JSI/TurboModules) do wymiany danych między natywnym kodem a JavaScript.

Gdy trafiasz na funkcję, której nie ma, ścieżki się rozchodzą. W Compose piszesz więcej natywnego kodu. W React Native tworzysz własny natywny moduł i utrzymujesz go dla obu platform. W tym miejscu „wybraliśmy cross-platform” może cicho przerodzić się w „teraz mamy trzy bazy kodu: JS, Android native, iOS native”.

Praktyczny sposób myślenia o dopasowaniu zespołu, gdy wymagania rosną:

• Compose zwykle pasuje, jeśli macie silne kompetencje Androidowe lub oczekujecie głębokiej integracji z Androidem.
• React Native pasuje, jeśli zespół jest mocny w JavaScript i potrzeby sprzętowe są typowe.
• W każdym przypadku planuj pracę natywną, jeśli potrzebujesz usług w tle, specjalnego sprzętu lub ścisłych zasad offline.

Wydajność w praktyce: gdzie użytkownicy to poczują

Rzeczywiste odczucie różnicy pojawia się w kilku momentach: gdy aplikacja się otwiera, gdy przechodzisz między ekranami i gdy UI pracuje, a użytkownik wciąż klika.

Czas uruchomienia i przejścia ekranów jest zwykle łatwiejszy do utrzymania w Compose, ponieważ jest w pełni natywny i działa w tym samym runtime co reszta aplikacji Android. React Native też może być bardzo szybki, ale cold start często zawiera dodatkowe przygotowania (ładowanie silnika JS i bundle’ów). Małe opóźnienia są bardziej prawdopodobne, jeśli aplikacja jest ciężka lub build nie jest dopracowany.

Responsywność pod obciążeniem to kolejna ważna rzecz. Jeśli parsujesz duży plik JSON, filtrujesz długą listę lub liczysz sumy w formularzu, aplikacje Compose zwykle przenoszą tę pracę na Kotlin coroutines i trzymają główny wątek wolny. W React Native wszystko, co blokuje wątek JS, może sprawić, że dotknięcia i animacje będą „lepne”, więc często trzeba przenieść ciężką pracę do kodu natywnego lub ją starannie harmonogramować.

Przewijanie to pierwsza rzecz, o której użytkownicy będą narzekać. Compose oferuje natywne narzędzia list jak LazyColumn, które wirtualizują elementy i dobrze zarządzają pamięcią, jeśli są poprawnie napisane. React Native korzysta z komponentów jak FlatList (czasem z szybszymi alternatywami) i trzeba pilnować rozmiarów obrazów, kluczy elementów i re-renderów, by uniknąć przycinania.

Bateria i praca w tle często sprowadzają się do podejścia do synchronizacji. Na Androidzie aplikacje Compose mogą polegać na narzędziach systemowych jak WorkManager do przewidywalnego planowania. W React Native synchronizacja w tle zależy od natywnych modułów i ograniczeń systemu, więc niezawodność bardziej różni się między urządzeniami i konfiguracjami. Agresywne pollingi rozładują baterię w obu podejściach.

Jeśli wydajność jest największym ryzykiem, zbuduj jeden „problemowy ekran” najpierw: najcięższą listę i jeden offline’owy formularz z realną ilością danych. Mierz go na średniej klasy urządzeniu, nie tylko na flagowcu.

Podstawy trybu offline: przechowywanie danych i stan

Tryb offline to głównie problem danych, nie UI. Niezależnie od stosu UI, trudne jest zdecydowanie, co przechowywać na urządzeniu, co UI pokazuje offline i jak pogodzić zmiany później.

Lokalna baza: wybierz właściwe narzędzie

Prosta zasada: ważne dane tworzone przez użytkownika przechowuj w prawdziwej bazie, nie w przypadkowych polach klucz-wartość.

Używaj bazy danych do strukturalnych danych, które wyszukujesz i sortujesz (zamówienia, pozycje, klienci, szkice). Key-value zostaw na małe ustawienia (flagii typu „obejrzał samouczek”, tokeny, ostatni filtr). Pliki wykorzystuj do blobów (zdjęcia, PDFy, eksporty cache, duże załączniki).

Na Androidzie z Compose zespoły często używają Room lub innych rozwiązań opartych na SQLite plus małego magazynu key-value. W React Native zwykle dodasz bibliotekę do SQLite/Realm‑style storage i oddzielny key-value (AsyncStorage/MMKV‑like) na preferencje.

Offline-first: traktuj lokalne jako źródło prawdy

Offline-first oznacza, że tworzenie/edycja/usuwanie dzieje się najpierw lokalnie, a potem synchronizuje się później. Praktyczny wzorzec: zapisz do lokalnej DB, aktualizuj UI z lokalnej DB i kolejkuj zmiany do wysyłki w tle, gdy to możliwe. Na przykład: handlowiec edytuje zamówienie w samolocie, widzi je od razu na liście, a aplikacja dodaje zadanie synchronizacji do kolejki.

Konflikty pojawiają się, gdy ten sam rekord zmienia się na dwóch urządzeniach. Typowe strategie: last-write-wins (proste, może utracić dane), merge (dobrze dla pól addytywnych jak notatki) lub przegląd przez użytkownika (najlepsze, gdy ważna jest dokładność, np. ceny i ilości).

Aby uniknąć mylących błędów, zdefiniuj „prawdę” jasno:

• Stan UI jest tymczasowy (to, co użytkownik właśnie wpisuje).
• Stan zapisany to trwałe dane (to, co da się odtworzyć po crashu).
• Stan serwera to stan współdzielony (to, co w końcu zobaczą inne urządzenia).

Trzymaj te granice, a zachowanie offline pozostanie przewidywalne nawet gdy formularze i listy rosną.

Niezawodność synchronizacji w tle: co się psuje i dlaczego

Synchronizacja w tle zawodzi częściej z winy telefonu niż twojego kodu. Zarówno Android, jak i iOS ograniczają to, co aplikacje mogą robić w tle, aby chronić baterię, dane i wydajność. Jeśli użytkownik włączy tryb oszczędzania baterii, wyłączy dane w tle lub wymusi zamknięcie aplikacji, twoja obietnica „synchronizuj co 5 minut” może zamienić się w „synchronizuj wtedy, kiedy system pozwoli”.

Na Androidzie niezawodność zależy od sposobu planowania pracy i reguł producenta urządzenia. Bezpieczniejsza droga to użycie schedulerów zatwierdzonych przez system (np. WorkManager z constraintami). Nawet wtedy różne marki mogą agresywnie opóźniać zadania, gdy ekran jest wyłączony lub urządzenie jest w stanie bezczynności. Jeśli twoja aplikacja wymaga niemal‑natychmiastowych aktualizacji, musisz zaprojektować model wokół synchronizacji eventual zamiast zawsze‑włączonej synchronizacji.

Kluczowa różnica między Compose a React Native to miejsce, gdzie żyje logika w tle. Aplikacje Compose zwykle uruchamiają zadania w tle w natywnym kodzie, więc planowanie i logika retry pozostają blisko systemu. React Native też może działać dobrze, ale zadania w tle często zależą od dodatkowej natywnej konfiguracji i modułów zewnętrznych. Częste pułapki to nieprawidłowo zarejestrowane zadania, headless tasks zabijane przez system lub runtime JS, który nie budzi się, gdy się tego spodziewasz.

Aby udowodnić, że synchronizacja działa, traktuj ją jak funkcję produkcyjną i mierz jej działanie. Loguj fakty odpowiadające na pytania „czy uruchomiło się?” i „czy zakończyło się?”. Śledź kiedy zadanie zostało zaplanowane, rozpoczęte i zakończone; stan sieci i oszczędzania baterii; elementy w kolejce, wysłane, nieudane i ponawiane (z kodami błędów); czas od ostatniej udanej synchronizacji na użytkownika/urządzenie; oraz wyniki konfliktów.

Prosty test: włóż telefon do kieszeni na noc. Jeśli synchronizacja przebiegnie do rana na wszystkich urządzeniach, jesteś na dobrej drodze.

Złożone formularze: walidacja, szkice i detale UX

Złożone formularze to miejsce, gdzie użytkownicy odczuwają różnicę, nawet jeśli nie potrafią jej nazwać. Gdy formularz ma pola warunkowe, wieloetapowe ekrany i dużo walidacji, drobne opóźnienia lub problemy z fokusowaniem szybko powodują porzucenie pracy.

Walidacja jest najłatwiejsza do zaakceptowania, gdy jest przewidywalna. Pokaż błędy tylko po dotknięciu pola, trzymaj komunikaty krótkie i równaj zasady do rzeczywistego procesu. Pola warunkowe (np. „Jeśli wymagane jest doręczenie, poproś o adres”) powinny pojawiać się bez skoków na stronie. Formularze wieloetapowe działają lepiej, gdy każdy krok ma jasny cel i widoczny sposób powrotu bez utraty wprowadzonych danych.

Zachowanie klawiatury i fokus to cichy breaker. Użytkownicy oczekują, że przycisk Dalej przejdzie w sensownym porządku, ekran przewinie się tak, by aktywne pole było widoczne, a komunikaty o błędach będą dostępne dla czytników ekranu. Testuj jedną ręką na małym telefonie — tam błędna kolejność fokusu i ukryte przyciski wychodzą na jaw.

Szkice offline nie są opcjonalne przy długich formularzach. Praktyczne podejście to zapisywanie w trakcie pracy i możliwość wznowienia później, nawet po zabiciu aplikacji. Zapisuj po znaczących zmianach (nie po każdym znaku), pokazuj prostą podpowiedź „ostatnio zapisane”, pozwalaj na dane częściowe i obsługuj załączniki oddzielnie, by duże obrazy nie spowalniały szkicu.

Przykład: 40‑polowy formularz inspekcyjny z sekcjami warunkowymi (kontrole bezpieczeństwa pojawiają się tylko dla określonego sprzętu). Jeśli aplikacja waliduje każdą regułę po każdym znaku, pisanie będzie „lepkie”. Jeśli szkice zapisywane są tylko na końcu, rozładowanie baterii straci całą pracę. Lepsze doświadczenie to szybkie lokalne zapisy, walidacja nasilająca się przy przesyłaniu i stabilny fokus, by klawiatura nigdy nie zasłaniała przycisków akcji.

Długie listy: płynne przewijanie i użycie pamięci

Długie listy to miejsce, gdzie użytkownicy najpierw zauważają problemy: przewijanie, klikanie i szybkie filtrowanie. Oba podejścia mogą być szybkie, ale zwalniają z różnych powodów.

W Compose długie listy zwykle buduje się z LazyColumn (i LazyRow). Renderuje tylko to, co jest na ekranie, co pomaga użyciu pamięci. Nadal trzeba utrzymać każdy wiersz tani w rysowaniu. Ciężka praca wewnątrz item composables lub zmiany stanu powodujące szeroką rekompozycję mogą wywołać przycinki.

W React Native FlatList i SectionList też są zaprojektowane do wirtualizacji, ale można napotkać dodatkową pracę, gdy propsy się zmieniają i React renderuje wiele wierszy ponownie. Obrazy, dynamiczne wysokości i częste aktualizacje filtrów dodatkowo obciążają wątek JS, co przekłada się na zgubione klatki.

Kilka nawyków zapobiega większości „janków” listy: trzymaj stabilne klucze, unikaj tworzenia nowych obiektów i callbacków dla każdego wiersza przy każdym renderze, utrzymuj przewidywalne wysokości wierszy i paginuj, by nigdy nie blokować przewijania podczas ładowania.

Krok po kroku: jak wybrać dla swojej aplikacji

Zacznij od spisania wymagań prostym językiem, nie w terminach frameworka. „Zeskanuj kod kreskowy w słabym świetle”, „dodaj 10 zdjęć do zamówienia”, „pracuj 2 dni bez zasięgu” i „synchronizuj cicho, gdy telefon jest zablokowany” — takie wymagania jasno pokazują kompromisy.

Następnie zablokuj reguły danych i synchronizacji przed dopracowaniem ekranów. Zdecyduj, co żyje lokalnie, co można cache’ować, co musi być zaszyfrowane i co się dzieje przy konfliktach. Jeśli zrobisz to po upiększeniu UI, zwykle przerabiasz połowę aplikacji.

Potem zbuduj ten sam mały wycinek w obu opcjach i oceniaj: jeden złożony formularz ze szkicami i załącznikami, jedna długa lista z wyszukiwaniem i aktualizacjami, podstawowy przepływ offline w trybie samolotowym i synchronizacja, która wznawia się po zabiciu i ponownym otwarciu aplikacji. Na koniec testuj zachowanie w tle na prawdziwych urządzeniach: oszczędzanie baterii włączone, dane w tle ograniczone, telefon bezczynny przez godzinę. Wiele problemów „działa na moim telefonie” synchronizacji ujawnia się właśnie tutaj.

Mierz to, co użytkownicy naprawdę czują: cold start, płynność przewijania i sesje bez crashy. Nie gon za perfekcyjnymi benchmarkami. Prosty, powtarzalny baseline jest lepszy.

Częste błędy i pułapki

Wiele zespołów zaczyna od ekranów i animacji. Bolesna część pojawia się później: zachowanie offline, ograniczenia pracy w tle i stan, który nie pasuje do oczekiwań użytkowników.

Typowa pułapka to traktowanie synchronizacji w tle jak coś, co będzie działać zawsze na żądanie. Zarówno Android, jak i iOS będą wstrzymywać lub opóźniać pracę, aby oszczędzać baterię i dane. Jeśli projekt zakłada natychmiastowe uploady, dostaniesz zgłoszenia o „braku aktualizacji”, które w rzeczywistości są wynikiem harmonogramowania systemu.

Inna pułapka to budowanie UI najpierw i dopuszczenie, by model danych dogonił go później. Konflikty offline są dużo trudniejsze do poprawienia po wdrożeniu. Zdecyduj wcześnie, co się dzieje, gdy ten sam rekord edytowany jest dwukrotnie, albo gdy użytkownik usuwa coś, co nigdy nie zostało wysłane.

Formularze mogą cicho stać się bałaganem, jeśli nie nazwiesz i nie rozdzielisz stanów. Użytkownik musi wiedzieć, czy edytuje szkic, zapisany lokalnie rekord, czy coś już zsynchronizowanego. Bez tego kończysz z duplikatami, utraconymi notatkami lub walidacją blokującą użytkowników w niewłaściwym momencie.

Zwróć uwagę na te wzorce:

• Zakładanie, że praca w tle będzie działać cyklicznie zamiast być best‑effort zgodnie z regułami OS.
• Traktowanie offline jako przełącznika, a nie jako rdzenia modelu danych i konfliktów.
• Pozwolenie, by jeden formularz reprezentował trzy stany (szkic, zapisane, zsynchronizowane) bez jasnych reguł.
• Testowanie tylko na szybkich telefonach i stabilnym Wi‑Fi, a potem zaskoczenie wolnymi listami i zablokowanymi uploadami.
• Dodawanie wielu wtyczek zewnętrznych, a potem odkrycie, że jedna jest nieutrzymana lub zawodzi na edge case’ach.

Krótka kontrola rzeczywistości: handlowiec tworzy zamówienie w piwnicy bez zasięgu, edytuje je dwukrotnie, potem wychodzi na zewnątrz. Jeśli aplikacja nie potrafi wyjaśnić, która wersja zostanie zsynchronizowana, albo synchronizacja jest zablokowana przez oszczędzanie baterii, handlowiec obwini aplikację, nie sieć.

Szybka lista kontrolna przed wyborem

Zanim wybierzesz stack, zbuduj malutki „realny” wycinek aplikacji i oceń go. Jeśli jeden element zawodzi, zwykle zamienia się w tygodnie poprawek później.

Sprawdź ukończenie offline najpierw: czy użytkownicy mogą dokończyć trzy najważniejsze zadania bez sieci, end‑to‑end, bez mylących pustych stanów czy duplikatów? Potem obciąż synchronizację: ponawiania i backoff przy chwiejnych Wi‑Fi, zabicie aplikacji w trakcie uploadu i jasny status widoczny dla użytkownika jak „Zapisane na urządzeniu” vs „Wysłane”. Waliduj formularze z długim, warunkowym przepływem: szkice powinny dokładnie otwierać się tam, gdzie użytkownik przerwał po crashu lub wymuszonym zamknięciu. Testuj listy z tysiącami wierszy, filtrami i aktualizacjami in‑place, obserwując zgubione klatki i skoki pamięci. Na koniec sprawdź funkcje urządzeń przy odmowach i ograniczeniach: uprawnienia „tylko podczas używania”, oszczędzanie baterii włączone, dane w tle ograniczone i łagodne fallbacki.

Praktyczna wskazówka: ogranicz czas testu do 2–3 dni na podejście. Jeśli nie uda się sprawić, by wycinek „offline + sync + długa lista + złożony formularz” działał solidnie w tym oknie, spodziewaj się ciągłych problemów.

Przykładowy scenariusz: aplikacja dla handlowców terenowych z zamówieniami offline

Wyobraź sobie zespół handlowców obsługujących małe sklepy. Aplikacja potrzebuje zamówień offline, robienia zdjęć (regał i paragon), dużego katalogu produktów i codziennej synchronizacji do centrali.

Rano: przedstawiciel otwiera aplikację na parkingu z przetykanym zasięgiem. Przeszukuje katalog 10 000 pozycji, szybko dodaje produkty i przełącza się między detalami klienta a długim formularzem zamówienia. To tu pojawia się friction UI. Jeśli lista produktów nadmiernie się rerenderuje, przewijanie przycina. Jeśli formularz traci fokus, resetuje dropdown lub zapomina szkicu przy przejściu do aparatu, przedstawiciel to odczuje od razu.

W południe: łączność spada na kilka godzin. Przedstawiciel tworzy pięć zamówień, każde z rabatami, notatkami i zdjęciami. Tryb offline to nie tylko „przechowuj lokalnie”. To też reguły konfliktów (co jeśli zmienił się cennik), jasne statusy (Zapisane, Oczekuje synchronizacji, Zsynchronizowane) i bezpieczne szkice (formularz powinien przeżyć rozmowę telefoniczną, użycie aparatu czy restart aplikacji).

Wieczorem: przedstawiciel wraca do zasięgu. „Wystarczająco niezawodna” synchronizacja dla tego zespołu oznacza, że zamówienia wysyłają się automatycznie w ciągu kilku minut po powrocie sieci, nieudane wysyłki są ponawiane bez duplikatów, zdjęcia są kolejkowane i kompresowane, aby sync nie zablokował się, a przedstawiciel może stuknąć „Synchronizuj teraz” i zobaczyć wynik.

Właśnie tu decyzja zwykle staje się jasna: ile natywnego zachowania potrzebujesz pod obciążeniem (długie listy, aparat + backgrounding i zarządzana przez OS praca w tle). Prototypuj ryzykowne części najpierw: jedną ogromną listę produktów, jeden złożony formularz zamówienia ze szkicami i jedną offline’ową kolejkę, która ponawia przesył po utracie sieci.

Kolejne kroki: zweryfikuj wybór małą budową

Jeśli utknąłeś w debacie, uruchom krótki, skupiony spike. Nie chcesz skończyć aplikacji — chcesz odnaleźć pierwszy realny ogranicznik.

Użyj prostego planu: wybierz jedną funkcję urządzenia, na której nie możesz iść na kompromis (np. skaner kodów kreskowych + zdjęcie), jeden offline’owy przepływ end‑to‑end (stwórz, edytuj, zapisz szkic, zrestartuj telefon, wznow, wyślij) i jedno zadanie synchronizacji (kolejkuj akcje offline, ponawiaj przy chybotliwej sieci, obsłuż odrzucenie serwera i pokaż jasny stan błędu).

Przed uruchomieniem zdecyduj, jak złapiesz błędy w realnym świecie. Loguj próby synchronizacji z kodem przyczyny (brak sieci, wygasło auth, konflikt, błąd serwera) i dodaj mały ekran „Status synchronizacji”, aby support mógł diagnozować problemy bez zgadywania.

Jeśli musisz jednocześnie zbudować backend i panel admina wraz z mobilną aplikacją, AppMaster (appmaster.io) może być użytecznym punktem wyjścia dla aplikacji biznesowych: generuje produkcyjny backend, web i natywne aplikacje, dzięki czemu szybko zweryfikujesz model danych i przepływy, zanim zaangażujesz się w dłuższy build w konkretnym frameworku mobilnym.