Skip to content

Previewer versus Android

One Python declaration drives two renderers. The Previewer optimizes the edit loop; the generated project uses Android widgets and services.

DESKTOP

Hot Previewer

Fast layout, callbacks, simulated device events and deterministic test data.

  • Tk-based visual renderer
  • desktop file and network workers
  • explicit simulation for push and GPS
  • no Android permission or OEM behavior
DEVICE

Native Android

Material widgets, Activities, RecyclerView, Media3, FCM and device services.

  • Java, XML and Gradle output
  • native lifecycle and permissions
  • real codecs, GPS and notifications
  • Android Studio inspection

Behavior map

Feature Previewer Android
Components desktop widgets styled from the same tokens Material/native views and generated drawables
Navigation screen-tree switch Activity navigation and extras
Feeds pooled virtual rows RecyclerView with targeted notifications
SQLite Python SQLite SQLiteDatabase
Encrypted values local preview key store Android-backed encrypted storage
HTTP/uploads background desktop workers Android background network workers
WebSocket WSS client with reconnect Android WSS client with lifecycle callbacks
Audio/video desktop media backend foreground MediaSession and Media3
Push push.simulate() Firebase Cloud Messaging
Location explicit preview_route fused device location
Routes compatible HTTP routing endpoint same request contract from Android

Visual parity is a contract, not pixel identity

Text metrics, system fonts and native controls can differ slightly. The goal is the same hierarchy, spacing, color, behavior and responsive decisions. Native Android conventions take precedence for permission dialogs, media controllers, date pickers and notifications.

When a mismatch is a library bug, fix both the Previewer renderer and the generator. Editing only generated Java is temporary because a later apkpy build regenerates it.

Release test

  1. Exercise every primary action in the Previewer.
  2. Build a fresh project rather than reusing stale generated files.
  3. Compare a narrow phone and a wide/tablet layout.
  4. Test loading, empty, error and offline states.
  5. Put the app in the background during media, upload, GPS and WebSocket work.
  6. Test a physical device before store release.