Mobile UI Implementation and Architecture Questions

Approach (brief)
Use SubcomposeLayout to subcompose children once, measure each child a single time with final constraints, compute column assignment (masonry) by greedy min-height, and place. Keep measured Placeables in a list so we never call measure again during that layout pass. Use stable keys to avoid unnecessary recomposition.

Kotlin example

@Composable
fun MasonryGrid(
    modifier: Modifier = Modifier,
    columns: Int,
    content: @Composable () -> Unit
) {
    SubcomposeLayout(modifier) { constraints ->
        // subcompose all content once
        val measurables = subcompose("items", content)
        // calculate column widths
        val columnWidth = (constraints.maxWidth / columns).coerceAtLeast(0)
        val childConstraints = Constraints.fixedWidth(columnWidth)
        // measure each child exactly once and assign to shortest column
        val columnHeights = IntArray(columns)
        data class Item(val placeable: Placeable, val column: Int, val y: Int)
        val items = ArrayList<Item>(measurables.size)
        measurables.forEach { measurable ->
            val p = measurable.measure(childConstraints) // single measurement per child
            val col = columnHeights.indices.minByOrNull { columnHeights[it] } ?: 0
            val y = columnHeights[col]
            columnHeights[col] += p.height
            items += Item(p, col, y)
        }
        val height = columnHeights.maxOrNull()?.coerceIn(constraints.minHeight, constraints.maxHeight) ?: constraints.minHeight
        layout(constraints.maxWidth, height) {
            items.forEach { (placeable, col, y) ->
                val x = col * columnWidth
                placeable.place(x, y)
            }
        }
    }
}

Why this avoids multiple measures / recompositions

• SubcomposeLayout subcomposes once; we call subcompose("items", content) a single time per layout pass.
• Each measurable is measured exactly once with childConstraints; we store Placeables and reuse them for placement — no re-measure loop.
• No additional measurement passes (no measuring to find heights then remeasuring to place) — we compute column assignment during the first measure.
• To reduce recomposition, callers should provide stable keys for changing item content; keep content lambdas small and use remember for derived state.

Edge notes & optimizations

• For variable width columns (responsive), compute childConstraints carefully.
• For very large lists, combine with Lazy layout patterns (LazyColumn + custom item measurement) to avoid composing all items at once.

Situation (S): At my last role the Android app had a 200k+ MAU, monolithic codebase in XML + ViewModels with heavy merge conflicts, slow build times (~8m local), and onboarding for new hires took weeks. Product wanted faster feature velocity for A/B tests.

Task (T): Convince engineering leadership and product to invest 3 months into modularizing the app and migrating core screens to Jetpack Compose so teams could ship faster and reduce release risk.

Action (A):

• Presented options: do nothing; incremental refactor; full rewrite. Recommended incremental modularization + pilot Compose for 3 high-priority flows.
• Built consensus by quantifying benefits: projected 30% faster build times via Gradle modules, 40% reduction in merge conflicts, and 20% faster feature delivery. Showed a prototype of a Compose screen to UX and backend to prove parity.
• Addressed risks: migration complexity, training needs, and increased CI runs. Proposed mitigations: one-week training, migration checklist, feature-flagged rollout, and CI gating per module.
• Aligned with PMs on KPIs and got exec sign-off for a 12-week roadmap and 20% engineering capacity allocation.

Result (R):

• After 12 weeks: incremental modules reduced average CI build time by 35%, local build by 25% (to ~6m), and the pilot Compose flows shipped 2x faster with fewer UI bugs.
• Measured success: lead time for changes to modular areas dropped from 10 days to 6 days; merge conflict rate decreased by 45%; developer satisfaction improved in surveys.
• Trade-offs: up-front slower velocity during ramp, added short-term CI cost. Those were offset by faster iterations and lower production regressions.

Lessons: start small with measurable pilots, quantify impact for stakeholders, and balance technical debt paydown with product cadence.

Overview
Compare RxJava/RxKotlin, Kotlin Flow (with Coroutines), and Combine across backpressure, cancellation, error handling, and lifecycle integration — with mobile-specific examples.

Backpressure

• RxJava: Built-in backpressure (Flowable) vs non-backpressured Observable. Mature operators (onBackpressureBuffer/drop/latest). Good for streams that can outrun consumers (sensors, BLE).
• Kotlin Flow: Designed with backpressure by suspending emitter when downstream is slow (cold, sequential). Simpler mental model for coroutine users.
• Combine: Has backpressure via Demand (Subscribers request n). Powerful but slightly verbose compared to Flow.

Cancellation

• RxJava: Disposable to cancel subscription; integration with scopes requires manual wiring (CompositeDisposable).
• Flow: Cancellation is structured via CoroutineScope; cancel coroutine to cancel flow collection automatically.
• Combine: Cancellable via AnyCancellable; tie to lifecycle manually or via frameworks (e.g., store cancellables).

Error propagation

• RxJava: Rich error operators (onErrorResumeNext, retryWhen). Terminal errors unless handled.
• Flow: Uses exceptions — catch, retry, retryWhen. Operators are coroutine-friendly.
• Combine: Similar to Rx with Failure type; errors propagate as completion with failure; mapError etc.

Lifecycle integration (mobile)

• Android: RxJava needs lifecycle-aware management (AutoDispose, LifecycleScope adapters). Flow integrates smoothly with lifecycle-aware CoroutineScope (viewModelScope, lifecycleScope) and Jetpack (repeatOnLifecycle). Use flowWithLifecycle for UI.
• iOS: Combine integrates with UIKit/SwiftUI via AnyCancellable and lifecycle of views/view models; SwiftUI provides .onReceive and @Published interop.

Where each excels

• RxJava: Complex multi-stream composition, legacy codebases, extensive operator set, robust backpressure options.
• Flow: Modern Kotlin apps — concise, structured cancellation, excellent with coroutines and Jetpack (ViewModel/lifecycle).
• Combine: Native iOS reactive in SwiftUI/Combine stacks; tight Swift type safety and Swift concurrency interop.

Use Rx for heavy reactive transformations, Flow for coroutine-first Android apps, Combine for native Swift UI pipelines.

Clarify goals & constraints

• Mobile app must work fully offline, allow local edits, sync reliably with server, preserve UX/battery.

Local persistence

• Use a robust local DB: Room (Android) / Core Data or Realm (iOS). Model has canonical object ID, client-generated UUID, version/timestamp, and metadata (dirty flag, base_revision).
• Keep a change-log table for operations (create/update/delete) with causal metadata.

Operation queue

• Append user operations to a durable FIFO queue (DB-backed). Each op: op_id, entity_id, op_type, payload, base_revision, timestamp.
• Retry with exponential backoff; mark ops as in-flight and idempotent (include client_op_id) so server can dedupe.

Conflict resolution

• Strategy layers:
  • Last-Write-Wins: use for low-value fields; compare revisions/timestamps.
  • Field-level merge: for structured objects, merge non-overlapping fields.
  • CRDTs: apply when concurrent, real-time collaborative state needed (e.g., ordered lists — use RGA or LWW-Element-Set).
• Prefer server-authoritative merge with deterministic rules; client performs optimistic merge and records server resolution to update local state.

Background sync

• Use platform schedulers: WorkManager (Android) and BGTasks/URLSession background (iOS).
• Trigger sync on network change, app foreground, or user action. Batch ops to reduce network/battery; limit frequency and use exponential backoff on failures.

UI & UX

• Show per-item sync state icons (synced, syncing, conflict). Provide unobtrusive global status (banner/spinner).
• For conflicts, surface a clear conflict screen: show local vs server diff, auto-merge preview, buttons: Accept Local / Accept Server / Manual Edit. Provide Undo and last-synced timestamp.
• Avoid blocking critical flows; allow queued edits and indicate when resolution required.

Observability & testing

• Log sync traces, expose metrics, write integration tests for concurrent edits and CRDT behaviour.

Brief answer
Mobile architecture that centralizes UI primitives and semantics makes accessibility and UX consistent: componentization, centralized theming, localization pipelines, and semantic APIs each reduce duplication and surface-area for bugs so Dynamic Type, VoiceOver/TalkBack, and RTL are handled uniformly.

Concrete architectural decisions & examples

• Componentization:

  • Build text/button/image components that internally apply Dynamic Type (iOS: UIFontMetrics with text styles; Android: autosize TextView or use Compose’s Text with style) so all screens inherit scaling.
  • Shared accessible components set accessibilityLabel/contentDescription and traits/role in one place.

• Centralized theming:

  • Single theme store exposing fonts, color tokens, spacing scaled by accessibility font size multiplier. On iOS/Android observe system font-size changes and reapply.
  • Use tokenized colors to swap high-contrast or dark-mode variants globally.

• Localization pipeline:

  • String catalog with ICU/plural and gender rules; CI runs pseudo-localization and automated checks for truncation.
  • Use structured keys and avoid concatenation so translators get full sentences (prevents accessibility label breakage).

• Semantic APIs:

  • Expose semantic props on components (role, state, hint) so screen readers read consistent phrasing (e.g., “Play button, selected”).
  • Use accessibility actions for custom gestures.

• RTL/layout:

  • Use start/end constraints (Android) and leading/trailing (Auto Layout) and mirror assets; test with RTL simulator and enforce in CI.

Why this helps
Centralization reduces scattered platform-specific fixes, ensures a single place to implement Dynamic Type, VoiceOver/TalkBack and RTL support, and makes testing and scaling across app features predictable and maintainable.