000%
COMMISSION Nº 04 · 2024–25 — ANDROID COMMERCE
BRIGHTMALL · Android

Brightmall Android — the other half of the storefront, same contract as iOS.

Brightmall Android — the same hybrid commerce shell as the iOS counterpart, in Kotlin, on the same release cadence.

FIG. 01BRIGHTMALL — ANDROID — BRIGHTMALL · Android
COMMISSIONAndroid · Kotlin · Hilt · Coroutines · WebView · Android-11 deep-link2024 — 2025

I developed both versions alone, matching the Android app to the iOS app in behavior and release schedule.

The application is written in Kotlin with AndroidX Views, Hilt, Coroutines, and an Android-11-grade deep-link policy that handles the Korean pay-and-banking ecosystem cleanly. The native shell carries the storefront traffic through a WebView surface with the same configuration as Certilife.

The hard part of a Korean commerce shell is everything around payment. Since Android 11, an app has to declare upfront which external apps it intends to see, so the shell ships with an explicit allowlist for the country's payment and banking apps. When the storefront fires a payment intent, the shell parses it, launches the right app when it is installed, and falls back to the store listing when it is not — the install-then-pay loop Korean payment gateways expect, handled without the web layer ever noticing.

The token bridge and the call bridge mirror the iOS contracts one to one, the WebView introduces itself to the server the same way, and even the edge-to-edge inset handling was written with the iOS safe-area behavior as the reference. Photo upload from the storefront opens a native chooser — camera or gallery — wired through Android's scoped file APIs, the policy-correct way to serve a web file input. And a debug-only switch changes the server environment without a rebuild.

— FIN —