Přeskočit na hlavní obsah

Tech Spec — Mobilní vývoj

Verze1.0
Datum2026-02-23
StavDraft
VlastníkSymbio — Analýza & Design

1. Přehled

Tento dokument specifikuje mobilní architekturu Colosseum MA z pohledu UX a designu. Definuje navigační model, offline strategii, platformové požadavky a API očekávání. Detailní implementační rozhodnutí (state management, konkrétní knihovny) jsou na vývojovém týmu.

Platforma: Cross-platform (Flutter nebo React Native — finální rozhodnutí TBD). Podrobná analýza obou frameworků: context/analysis/tech-stack-rn-vs-flutter.md.

Kontext: Symbio jako UX/design agentura neimplementuje aplikaci, ale specifikuje architektonická očekávání z perspektivy uživatelského zážitku — navigace, offline chování, performance, bezpečnost a API kontrakt.


2. Navigační architektura

2.1 Hlavní navigace

Tab-based navigation se 4 taby v bottom bar:

TabIkonaLabelRoot screenPopis
Program🎭ProgramP1 (Home/Feed)Personalizovaný feed akcí, sekce, promo
Hledat🔍HledatP8 (Vyhledávání)Fulltext search, filtry, výsledky
Vstupenky🎫VstupenkyP7 (Wallet)Moje vstupenky, QR kódy, offline
Profil👤ProfilP9 (Účet hub)Správa účtu, nastavení, podpora

2.2 Navigation stack

Každý tab má vlastní navigation stack. Při přepnutí tabu se zachovává stav stacku (uživatel se vrací na poslední pozici v daném tabu). Back gesture/button naviguje v rámci stacku aktuálního tabu.

Chování tab přepnutí:

  • Tap na aktivní tab → scroll to top + reset na root screen
  • Tap na neaktivní tab → přepnutí se zachováním stavu stacku
  • Long press na tab → žádná akce (reserved pro budoucí rozšíření)

2.3 Navigační typy

TypPopisGestaPříklady
PushStandardní screen-to-screen navigace v rámci tab stackuBack swipe (iOS), back button (Android)P1P3, P3P4, P9S14
Modal (fullscreen)Fullscreen modal nad aktuálním tabem, vlastní navigation stackClose button (top-left/right), swipe-down na iOSS4 (login), S5 (registrace), P6 (checkout)
Bottom sheetPartial overlay zdola s drag handleSwipe-to-dismiss, tap on scrimS3 (filtr), S1 (neadresné), seat detail, X5 (timer warning)
Overlay/DialogCentered dialog s scrim backgroundTap outside, close buttonX14 (smazání účtu), X15 (GDPR souhlas)
ToastNon-blocking feedback, auto-dismissSwipe-to-dismiss (optional)X16, X17, success/error feedback
SystemApp-level, outside tab navigationN/AX10 (splash), X19 (force update), X20 (welcome)

2.4 Deep linking

Viz dedikovaná stránka: Deep Linking

2.5 Tab badge indicators

TabBadge typPodmínkaFáze
VstupenkyČíselný badge> 0 nadcházejících vstupenek (v příštích 7 dnech)MVP
ProfilČervená tečkaNepřečtené notifikaceF1

3. Screen types a navigation patterns

3.1 Primární obrazovky (root nebo klíčové flow)

Screen IDNázevNav typGestaTabFáze
P1Home/FeedRootPull-to-refreshProgramMVP
P2Seznam akcíPushBack swipe, pull-to-refreshProgramMVP
P3Detail akcePushBack swipe, shareProgramMVP
P4Seat MapPushPinch-to-zoom, pan, backProgramMVP
P5KošíkPushBack swipeProgramMVP
P6CheckoutModal (fullscreen)Close buttonMVP
P7WalletRootPull-to-refreshVstupenkyMVP
P8VyhledáváníRootKeyboard auto-focusHledatMVP
P9Účet hubRootProfilMVP
P10Věrnostní hubPushBack swipeProfilF1
P11Věrnostní e-shopPushBack swipeProfilF1
P12White-label správaPushBack swipeProfilF2+
P13Ticket SwapPushBack swipeVstupenkyTBD

3.2 Sekundární obrazovky

Screen IDNázevNav typGestaTabFáze
S1Neadresné vstupenkyBottom sheetSwipe-to-dismissMVP
S2Checkout údajePush (modal flow)BackMVP
S3FiltrováníBottom sheetSwipe-to-dismissMVP
S4PřihlášeníModal (fullscreen)Close buttonMVP
S5RegistraceModal (fullscreen)Close buttonMVP
S6OnboardingModal (fullscreen)Skip buttonF1
S7Historie objednávekPushBack swipeVstupenkyMVP
S8Detail vstupenkyPushBack swipeVstupenkyMVP
S9Nastavení notifikacíPushBack swipeProfilF1
S10Správa watchdogůPushBack swipeProfilF1
S11PředplatnéPushBack swipeProgramMVP
S12Detail místaPushBack swipeProgramMVP
S13Profil pořadatelePushBack swipeProgramMVP
S14Editace profiluPushBack swipeProfilMVP
S15Podpora/KontaktPushBack swipeProfilMVP
S16Detail odměnyPushBack swipeProfilF1
S17FAQPushBack swipeProfilF1
S18Chat/podporaPushBack swipeProfilF1
S19Notifikační centrumPushBack swipeProfilF1
S20Blog feedPushBack swipeProfilF2+
S21Detail článkuPushBack swipeProfilF2+
S22Geolokace/mapaPushBack swipeHledatF2+
S23Doplňkový prodejBottom sheet / PushSwipe-to-dismissProgramF2+
S24Brand konfiguracePushBack swipeProfilF2+
S25Ticket Swap detailPushBack swipeVstupenkyTBD

3.3 Podpůrné obrazovky (overlays, stavové, toasty)

Podpůrné X-screeny (X1–X26) nejsou v navigaci jako self-standing screeny, ale jako overlays, inline states nebo dialogy. Kompletní seznam viz context/analysis/screen-inventory.md.

KategorieScreen IDsTyp zobrazení
Thank you / successX1, X2Fullscreen result
Error statesX3, X4Fullscreen result / dialog
WarningsX5Inline banner
Empty statesX6, X7, X8Inline placeholder
Permission dialogyX12Custom dialog → system dialog
GDPR / confirm dialogyX14, X15Centered dialog
Toasty / feedbackX16, X17Toast (auto-dismiss 3s)
System screensX10, X11, X19, X20Fullscreen overlay

4. Offline strategie

4.1 Offline-first oblasti

OblastOffline dostupnostCache strategiePriorita
Wallet QR kódyPlná — musí fungovat 100 % bez internetuQR data + metadata stažena po nákupu a synchronizována při každém otevření wallet. Encrypted local storage.P0
Profil uživatelePlná — data z posledního syncCache-first, refresh on connectP0
Event feed (P1)Partial — cached verzeStale-while-revalidate, max age 1 hP1
Event detail (P3)Partial — nedávno prohlédnutéLRU cache posledních 20 detailůP1
ObrázkyCachedDisk cache s LRU eviction (max 200 MB)P1
Search výsledkyŽádná — vyžaduje internetP2
Seat map (P4)Žádná — real-time dataP2
Checkout (P6)Žádná — vyžaduje internetP0 (fail gracefully)

4.2 Offline indikátor (X11)

  • Persistent banner pod app bar: „Jste offline — některé funkce jsou omezené"
  • Disabled stavy na non-cached prvcích (šedý overlay, disabled taps)
  • Auto-dismiss při obnovení připojení (s krátkou „Zpět online" toast)
  • Retry button u failed requestů
  • Wallet tab zůstává plně funkční i offline

4.3 Sync strategie

AspektStrategie
Reconnect syncBackground sync při obnovení připojení — tickets first, pak profil, pak feed
Manual syncPull-to-refresh jako manuální trigger
Conflict resolutionServer-wins (server je source of truth)
Offline action queueQueue pro akce provedené offline (watchdog, sdílení) — odeslání po reconnect, FIFO pořadí
Cache invalidationETag/Last-Modified headers pro conditional requests
Data freshnessWallet: sync při každém otevření app. Feed: max 1 h. Detail: max 24 h.

5. Platform-specific požadavky

5.1 iOS

FeatureFramework/APIMinimum iOSFáze
BiometrikaLocalAuthentication (Face ID, Touch ID)iOS 16+MVP
Apple PayPassKit / Apple Pay JSiOS 16+MVP
Apple WalletPKPass (boarding pass style)iOS 16+MVP
Push notifikaceAPNs + UserNotificationsiOS 16+MVP (základ) → F1 (plný)
Deep linkingUniversal Links (apple-app-site-association)iOS 16+MVP
KalendářEventKitiOS 16+MVP
ShareUIActivityViewControlleriOS 16+MVP
Camera/QRAVFoundation (pokud potřeba sken)iOS 16+TBD
App ClipsApp Clip (event detail landing)iOS 16+TBD
Haptic feedbackUIFeedbackGeneratoriOS 16+MVP

Minimum podporovaná verze: iOS 16+

Odůvodnění: iOS 16 pokrývá ~95 % aktivních zařízení (únor 2026). Umožňuje využití moderních API (SwiftUI improvements, Live Activities pro ticket countdown).

5.2 Android

FeatureFramework/APIMinimum APIFáze
BiometrikaBiometricPrompt (fingerprint, face)API 28+MVP
Google PayGoogle Pay APIAPI 28+MVP
Google WalletGoogle Wallet API (JWT pass)API 28+MVP
Push notifikaceFCM (Firebase Cloud Messaging)API 28+MVP (základ) → F1 (plný)
Deep linkingApp Links (assetlinks.json)API 28+MVP
KalendářCalendarContractAPI 28+MVP
ShareIntent.ACTION_SENDAPI 28+MVP
Instant AppsGoogle Play InstantAPI 28+TBD
Haptic feedbackHapticFeedbackConstantsAPI 28+MVP

Minimum podporovaná verze: Android 9 (API 28)

Odůvodnění: API 28 pokrývá ~95 % aktivních zařízení. Umožňuje BiometricPrompt (unified API) a moderní notification channels.

5.3 Platformové rozdíly v UX

OblastiOSAndroid
Back navigationSwipe from left edgeSystem back button/gesture
Bottom sheet dismissSwipe down + tap scrimSwipe down + tap scrim + back button
ShareUIActivityViewController (system sheet)Intent chooser
HapticsTaptic Engine (bohatší palette)Vibration API (jednodušší)
Status barLight/dark per screenImmersive mode pro seat map
Safe areasDynamic Island, home indicatorNavigation bar, notch handling
PermissionsOne-time ask, settings redirectRuntime permissions, rationale dialog

6. Expected API požadavky

Podrobný rozpis viz API Požadavky.

Definujeme co očekáváme od backend API — ne přesnou specifikaci (tu dodá backend tým). Formát je REST-like, ale implementace může být GraphQL nebo jiná.

Přehled API skupin

SkupinaKlíčové endpointyFáze
Events APISeznam, detail, termíny, seat map, hledáníMVP
Auth APIRegistrace, login, OAuth, refresh, resetMVP
Cart & Payment APIKošík, platba, voucher, timerMVP
Tickets APIVstupenky, QR data, sdílení, wallet passMVP
Orders APIHistorie, detailMVP
User Profile APIProfil, preferenceMVP / F1
Notifications APISeznam, čtení, nastavení, device tokenMVP / F1
Watchdog APIVytvoření, seznam, zrušeníF1
Loyalty APIBody, transakce, odměny, výměnaF1
Content APIVenues, organizers, předplatné, FAQ, blogMVP / F1 / F2+

7. Performance budget

MetrikaTargetPrioritaMěření
App launch → interactive< 2 s (cold start)P0Time to first meaningful paint
Screen transition< 300 msP0Animation start to end
Scroll FPS≥ 60 FPSP0Profiler, žádné janky
Search response< 500 ms (API + render)P0Keystroke to results
Image loading (thumbnail)< 1 s (progressive)P1Placeholder → full image
Seat map render< 1 s (initial), 60 FPS zoom/panP0First paint + interaction FPS
Offline ticket access< 100 msP0Tap to QR display
Push notification delivery< 5 s (FCM/APNs)P1Server send to device display
Cart checkout flow< 30 s (celý flow)P1Seat selection to payment confirmation
App binary size< 50 MB (download)P2App Store / Play Store size
Memory usage< 300 MB (peak)P1Seat map + image gallery
Background battery< 2 % / hP2Background sync + location

Image loading strategie

  • Progressive loading s blur-up placeholderem (low-res → full-res)
  • WebP formát (s JPEG fallback pro starší zařízení)
  • CDN s responsivními variantami (1x, 2x, 3x — dle device pixel ratio)
  • Lazy loading mimo viewport (intersection-based)
  • Disk cache s LRU eviction (max 200 MB)
  • Placeholder shimmer efekt při načítání

Seat map performance

  • SVG/Canvas rendering (ne WebView)
  • Chunked loading pro velké sály (> 1000 sedadel)
  • Debounced seat status refresh (ne per-seat polling)
  • GPU-accelerated zoom/pan transformace
  • Pre-rendered thumbnails pro overview zoom level

8. Security

8.1 Token storage

PlatformaÚložištěMechanismus
iOSKeychain ServiceskSecClassGenericPassword, accessible afterFirstUnlock
AndroidEncryptedSharedPreferencesAndroid Keystore backend (hardware-backed na podporovaných zařízeních)
TokenŽivotnostRotace
Access token15 minAutomatická přes refresh token
Refresh token30 dnůRotated on use (single-use)
Push tokenPlatforma-managedRe-registrace při změně

8.2 Biometrika

  • Volitelná, aktivovaná po prvním úspěšném login (prompt uživateli)
  • Fallback na PIN/heslo při selhání (3 pokusy → PIN)
  • Biometric key vázán na device, ne na account
  • Při změně biometrických dat (nový otisk, nová tvář) → invalidace → vyžadovat heslo
  • Použití: app unlock, potvrzení platby, zobrazení citlivých dat

8.3 QR kód security

  • QR payload podepsaný serverovým klíčem (asymetrické podepisování)
  • Offline validace: sken zařízení ověří podpis bez API volání
  • Expiry timestamp v payloadu (prevence replay útoků)
  • Unikátní scan ID per vstup (prevence duplikátního použití)
  • QR kód obnovován periodicky (rolling code — TBD s backend týmem)

8.4 Síťová bezpečnost

OpatřeníStavPoznámka
HTTPS onlyPovinnéTLS 1.3, žádný HTTP fallback
Certificate pinningTBDZávisí na infrastruktuře a CDN. Doporučeno pro API endpointy.
Request signing (HMAC)TBDPro citlivé endpointy (platby, account deletion)
Jailbreak/root detectionDoporučenoWarning dialog, ne blokace — wallet musí fungovat
Screenshot preventionDoporučenoPouze na S8 (QR kód detail) — prevence neoprávněného sdílení

8.5 GDPR compliance

PožadavekImplementace
Data encryption at restSQLCipher nebo platform-native encrypted storage
Exportovatelnost datAPI endpoint pro stažení osobních dat (JSON/PDF)
Právo na smazáníAccount deletion flow (X14) → soft delete → hard delete po 30 dnech
Consent managementGranulární souhlasy (marketing, analytics, personalizace) s audit trail
Data minimizationSbírat jen nezbytná data per účel
Privacy by designAnonymizace analytics dat, pseudonymizace kde možné

8.6 Sensitive data handling

DataKlasifikaceStorageTransmission
Auth tokenyTajnéKeychain/KeystoreHTTPS only
QR payloadyCitlivéEncrypted local DBHTTPS only
Osobní údajeOsobní (GDPR)Encrypted local DBHTTPS only
Platební dataPCI-DSSNikdy lokálně (tokenizace)Přes platební SDK
AnalyticsAnonymníStandard storageHTTPS

9. Flutter vs. React Native

Aktuální stav rozhodování

Finální rozhodnutí nebylo učiněno. Podrobná srovnávací analýza: context/analysis/tech-stack-rn-vs-flutter.md.

Z pohledu UX/designu nemá volba frameworku zásadní dopad na design deliverables — oba podporují nativní komponenty i custom UI. Specifikace v tomto dokumentu jsou framework-agnostické.

Souhrnná matice z perspektivy UX

KritériumFlutterReact NativeVítěz
Custom UI (seat map, animace)Vlastní rendering engine (Impeller), pixel-perfect kontrolaZávisí na native bridge, react-native-skia pro custom renderingFlutter
Nativní feel (platform conventions)Material/Cupertino widgety, ne 100 % nativníNativní UI komponentyReact Native
Performance (seat map zoom/pan)Impeller engine, konzistentní 60 FPSDobrý s New Architecture, možný jitter u komplexních animacíFlutter
Apple/Google Wallet integracePlugin ecosystem (ověřené knihovny)Plugin ecosystem (ověřené knihovny)Remíza
Offline storageHive/Isar/DriftWatermelonDB/MMKVRemíza
White-label (multi-brand)Flutter Flavors — first-class citizenBuild-time konfigurace, více manuální práceFlutter
Startup time20–40 % rychlejší cold start (AOT kompilace)Pomalejší (JS bundle parsing)Flutter
Talent poolMenší (Dart specialisté)3–4× větší (JS/TS vývojáři)React Native

Doporučení z perspektivy UX

Z pohledu UX doporučujeme framework, který nejlépe zvládne:

  1. Custom seat map interakci — pinch-to-zoom, SVG rendering, real-time updates sedadel
  2. Smooth animace — shared element transitions, bottom sheet gesta, parallax
  3. White-label theming — runtime přepínání brandů z jednoho codebase

Oba frameworky to zvládají. Flutter má mírnou výhodu v rendering performance a white-label podpoře. React Native má výhodu v talent poolu a nativním look & feel.

Finální rozhodnutí by mělo zohlednit:

  1. Kompetence vývojového týmu (rozhodující faktor)
  2. Existující codebase klienta (Colosseum Scanner je Xamarin — ani jedna platforma nemá přímou návaznost)
  3. Long-term maintenance strategie a náklady
  4. White-label škálování (1–2 brandy vs. 10+)

10. Accessibility (a11y)

Základní požadavky

OblastPožadavekPriorita
Screen readerVoiceOver (iOS) + TalkBack (Android) podpora na všech screenechP1
KontrastWCAG 2.1 AA minimum (4.5:1 text, 3:1 UI elements)P1
Touch targetsMinimálně 44×44 pt (iOS) / 48×48 dp (Android)P0
Font scalingPodpora Dynamic Type (iOS) / Font Scale (Android) až do 200 %P1
Seat map a11yAlternativní list view pro výběr sedadel (ne jen vizuální mapa)P1
MotionRespektovat Reduce Motion nastavení (žádné parallax, zjednodušené přechody)P2
ColorInformace nikdy jen barvou — vždy doplnit ikonou/textem (seat dostupnost, status)P1

Seat map accessibility

Seat map (P4) je vizuálně nejnáročnější screen. Pro uživatele se zrakovým postižením musí existovat alternativní cesta:

  • Textový list view se sekcemi, řadami a sedadly
  • Filtrování dle cenové kategorie
  • VoiceOver/TalkBack popis: „Řada 5, sedadlo 12, kategorie Premium, dostupné"

11. Analytics a monitoring

Klíčové události pro tracking

UdálostParametryScreenFáze
app_opencold/warm start, launch_time_msMVP
screen_viewscreen_id, screen_nameVšechnyMVP
event_viewevent_id, source (feed/search/deeplink)P3MVP
seat_selectedevent_id, seat_id, category, priceP4MVP
cart_createdevent_id, item_count, total_priceP5MVP
checkout_startedpayment_method, cart_valueP6MVP
purchase_completedorder_id, payment_method, total, item_countX1/X2MVP
purchase_failederror_code, payment_methodX3MVP
ticket_sharedticket_id, share_methodS8MVP
search_performedquery, result_count, filters_appliedP8MVP
filter_appliedfilter_type, filter_valueS3MVP
push_receivednotification_type, sourceF1
push_openednotification_type, deeplinkF1
loyalty_redeemedreward_id, points_spentS16F1

Crash reporting

  • Automatický crash reporting s stack traces
  • Breadcrumbs (posledních 20 akcí před crashem)
  • User consent pro automatické reporty
  • Konkrétní tooling (Firebase Crashlytics, Sentry, Bugsnag) — rozhodnutí na dev týmu

12. Otevřené otázky

Kompletní seznam otevřených otázek viz Open Questions.

#OtázkaOblastDopadUrgence
OQ-T-01Seat map data formát — V jakém formátu Colosseum API dodává sálové plány?P4, PerformanceKlíčové pro seat map implementaciVysoká
OQ-T-02Real-time seat updates — WebSocket nebo polling?P4Architektura, performance, UXVysoká
OQ-T-03Certificate pinning — Podpora v infrastruktuře?SecuritySecurity modelStřední
OQ-T-04Push notification provider — Vlastní infra nebo APNs/FCM?NotifikaceF1 architekturaStřední
OQ-T-05Platební brána — GoPay, ČSOB, Stripe, Comgate?P6Checkout UXVysoká
OQ-T-06CDN pro obrázky — Responsivní varianty z API?PerformanceImage loading strategieStřední
OQ-T-07Framework rozhodnutí — Flutter nebo React Native?Celý projektTechnické plánováníVysoká
OQ-T-08Tablet podpora — Adaptive layout?Celý projektDesign scope, odhadyStřední
OQ-T-09App Clips / Instant AppsDeep linkingArchitektura, scopeNízká
OQ-T-10Analytics toolingCelý projektSDK integraceStřední
OQ-T-11QR rolling code — Statický nebo obnovovaný?S8, SecurityOffline architekturaStřední
OQ-T-12Existující API — Rozšíření nebo nové?Celý backendArchitektura, timelineVysoká

Přílohy

A. Referenční dokumenty

DokumentCestaObsah
Přehled projektuprd/00-prehled-projektu.mdScope, fáze, architektura
Feature matrixcontext/analysis/feature-matrix.mdFunkce → fáze (source of truth)
Screen inventorycontext/analysis/screen-inventory.mdObrazovky → fáze (source of truth)
Flutter vs. RN analýzacontext/analysis/tech-stack-rn-vs-flutter.mdDetailní srovnání frameworků
Analýza webucontext/analysis/current-web-colosseum.mdContent model, aktuální stav

B. Konvence

  • Fázování dle .cursor/rules/phasing-convention.mdc
  • Screen ID formát: P = primární, S = sekundární, X = podpůrná
  • API endpointy jsou očekávání, ne specifikace — finální kontrakt definuje backend tým