Praca zdalna dla specjalistów ds. rozwoju hybrid mobile apps

Opracowanie międzynarodowej aplikacji mobilnej pod klucz (Projekt + Kod) W celu obniżenia kosztów, możliwe jest zakupienie gotowego projektu 1. Ogólne wymagania dotyczące projektu Platforma: Rozwój wieloplatformowy na frameworku Flutter (jeden kod dla iOS i Android). Typ platformy: Społeczny zakład / Gry o dyscyplinę (Peer-to-Peer 도전戰). Zadanie Wykonawcy: Pełny cykl rozwoju (UI/UX Projekt w Figma, frontend, backend-serwer, baza danych, integracja czujnika IoT i bramki płatniczej). Wielojęzyczność: Pełne wsparcie lokalizacji (i18n) oraz obsługa wielu walut. 2. Wymagania dotyczące UI/UX Projektu Potrzebny jest nowoczesny, neonowo-technologiczny interfejs w ciemnych kolorach (Tryb Ciemny). Kolory akcentujące: Głęboki grafitowy (tło), jasny zielony (finanse, saldo), jasny czerwony (tryb ochrony, zdarzenia karne). Funkcjonalność: Wyświetlanie 4 głównych ekranów dolnej nawigacji (Dashboard, Pokoje Gier, Portfel, Ustawienia urządzenia). Potrzebne są dynamiczne animacje zmiany salda i wyskakujących alertów. 3. Architektura finansowa (Escrow/Holding/Split) Aplikacja do utrzymania depozytów zgodnie z zasadami dyscypliny. Kluczowa jest integracja bramki płatniczej, która obsługuje Split Payments (Podział płatności) oraz Holding funduszy (Stripe Connect dla rynku globalnego/analogiczne dla lokalnego). Logika transakcji (komendy API backendu): Doładowanie: Środki użytkowników są przypisywane do ich konta i zamrażane na transakcyjnym (escrow) koncie systemu płatniczego. Nie trafiają bezpośrednio na konto firmy. Tryb SOLO: Po wystąpieniu zdarzenia wyzwalającego z czujnika IoT w zakazanych godzinach backend wydaje polecenie systemowi płatniczemu przelania stałej kwoty (kary) z konta transakcyjnego użytkownika na konto rozliczeniowe firmy. Tryb GROUP (Pokój): Użytkownicy tworzą wspólną pulę (na przykład 10 osób po 10 dolarów). Pieniądze są zamrażane w ramach konkretnego Pokoju Gier. Po wystąpieniu zdarzenia wyzwalającego u jednego z uczestników jego kara automatycznie się dzieli: 15% (prowizja platformy) trafia na konto rozliczeniowe firmy, a 85% pozostaje w puli nagród pokoju. Po zakończeniu terminu wyzwania backend automatycznie dzieli zgromadzoną pulę nagród między zwycięzców, a system płatniczy dokonuje automatycznego przelewu (Payout) na ich karty. 4. Struktura kabinetów Kabinet 1: „Osobisty Tracker” (Tryb SOLO) Wskaźnik statusu monitorowania (Aktywny/Dostępny/Zablokowany). Konfigurator interwałów czasowych ochrony (Time Picker) oraz ustawienia wartości kary wyzwalacza. Panel stanu zewnętrznego urządzenia IoT (poziom naładowania czujnika w %, poziom sygnału, status synchronizacji). Kabinet 2: „Pokoje Gier” (Tryb GROUP) Narzędzia do tworzenia prywatnych pokoi (generowanie linków/zaproszeń dla przyjaciół) oraz lista publicznych globalnych lig. Tabela wyników (Leaderboard) uczestników z wyświetlaniem ich aktualnego statusu w czasie rzeczywistym, timer do końca wyzwania oraz wbudowany czat grupowy. Wspólny dział: Wielowalutowy portfel Wyświetlanie salda z automatycznym konwertowaniem lokalnych walut w czasie rzeczywistym. Historia transakcji z przejrzystym logiem wydatków, prowizji i wygranych. 5. Wymagania dotyczące Backend i Integracji IoT Stos: Node.js/Python/Go (do wyboru wykonawcy, uzasadnione). Łącze z IoT: Odbieranie pakietów danych z zewnętrznego modułu Wi-Fi. Czas wysyłania powiadomień Push (przez FCM) na smartfon w momencie wystąpienia zdarzenia z czujnika – mniej niż 1 sekunda. Logika antyfraudowa: Serwer musi analizować przesyłane przez czujnik dane telemetryczne wbudowanego akcelerometru (accel_x/y/z). Jeśli zdarzenie występuje przy zerowej zmianie osi przyspieszenia, transakcja jest oznaczana przez system jako podejrzana (ochrona przed statycznym trzymaniem czujnika), użytkownik otrzymuje powiadomienie.

połączenia są realizowane przez kartę SIM w iPhone, więc należy automatycznie przekazywać informacje o przychodzących/wychodzących połączeniach do CRM