Nie podano
23 oferty
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.
