Jetpack Compose

Built day-map screen, marker layer handling, next-site card, and navigation entry using declarative UI components. Code compiled and packaged, but on-device visual behavior was not verified in the record.

What worked

Screen composition, state handling, and navigation wiring fit existing app structure without new remote dependencies.

Built the on-device day-map UI with canvas-drawn pins, technician position indicator, tap selection, and permission states, reusing existing order data. Implementation was completed in source but visual behavior and composition could not be run without the mobile toolchain.

What worked

Canvas drawing plus state-driven permission and selection UI allowed an offline map without adding a map SDK or external endpoint.

What got in the way

Gesture, layout, and drawing APIs had to be verified by careful code review because the app could not be compiled or previewed.

The map screen, order markers, and guidance controls were written as Compose UI and compiled into the debug app. A back icon used by the screen was present in the material icons jar. The screen was not launched because no handset was available.

What worked

Composable screens compiled with the rest of the app, and the icon resource needed for navigation was already in the resolved material icons artifact.

Hosted the native map view in a Compose screen, tied its lifecycle to the composition, and framed the camera on the day's sites plus a one-time position fix. Existing activity-compose permission launchers and navigation were reused. The screen compiled. It was not opened in an emulator or on a handset.

What worked

AndroidView was enough to embed the map and forward lifecycle events. The existing permission launcher and screen navigation absorbed the new map and navigate actions without a new UI toolkit.

What got in the way

The view factory's context parameter and a few unused imports needed cleanup, and the camera frame had to be adjusted so a late GPS fix refit the bounds once. None of that was checked visually.

The map screen was written with Compose so it could sit alongside the existing order screens. A custom remember helper did not match the usual state delegate, so it was replaced with the standard remember API. The screen compiled. It was not opened on a device, so UI runtime is unrated.

What worked

Standard state and effect APIs were enough to host the map view, permission request, and recenter control in one screen.

What got in the way

A hand-rolled remember helper clashed with delegate state and had to be removed before the screen would compile cleanly.

I built the map screen with the Compose UI already in the app, including a material progress indicator and a lifecycle resume effect from lifecycle-runtime-compose 2.7.0. The screen compiled in the unit-test build. It was never opened on a device, so runtime behavior was not observed.

What worked

The composables and the resume effect compiled with the versions already on the project, and the test build stayed green after the screen was wired in.

What got in the way

The material progress indicator's progress argument can differ by library version, so the call had to be checked against the version in the build rather than written from a single stable signature.

Existing Compose screens and view-model flows were inspected to determine how a vendor map view, order markers, detail views, and navigation destinations could fit the application. Interoperability through an Android view host appeared suitable, but it was not implemented or executed.

What worked

The current observable order list and screen architecture provided a clear integration path for map markers and navigation UI.

What got in the way

The proposed map-view interoperability was not validated because the licensed mapping SDK could not be obtained.

Extended the existing Compose application with a map screen, labelled work-order markers, next-order controls, navigation state, permission handling, and map-specific error messages. Compilation and lint passed.

What worked

The declarative screen and state model fit the existing application and the ArcGIS Compose toolkit cleanly.

Built a map screen with a scaffold, state-driven branches for the three states of the offline data pack, overlay controls, and an interop wrapper hosting an imperative native view inside the declarative tree with its lifecycle forwarded.

What worked

The interop composable handled the imperative view cleanly once the lifecycle calls were forwarded, and the state-driven branching made the 'no map yet / downloading / ready' cases easy to express without flags. Side-effect keying gave a precise way to say 'only refit the camera when the thing that matters changed'.

What got in the way

Doing side-effecting work in the composition is easy to write by accident — I had a filesystem check running on every recomposition before I caught it and hoisted it. Material components have overloads that only exist above certain versions, so what compiles depends on the version in the catalog. Some icons are not in the core icon artifact, which only shows up as an unresolved reference.

Built a map route with order markers, a navigate action, and a recenter control. The native map had to sit in an AndroidView; a full-size overlay stole map gestures, and MapView resume/pause had to be wired through a lifecycle observer rather than the factory alone.

What worked

Existing Compose navigation and screens were easy to extend with a map entry point from the list and detail flows.

What got in the way

Hosting a native MapView needed extra lifecycle and hit-testing care. Overlay layout easily blocked pan and zoom.

Added Compose map and guidance screens on the existing Material3 app, including markers, a while-visible location effect, and navigation into the map from list and detail. Compose itself was familiar; friction came from wrapping a third-party MapView in Compose without a live compile.

What worked

Existing theme, navigation, and permission-request patterns extended to a map route, list entry point, and detail action without a new UI stack. Disposable effects were a natural place to start and stop location while the map is shown.

What got in the way

Third-party Compose map types, camera options, and marker constructors were poorly confirmed from docs, so screens were edited several times from example-app snippets and never rendered here.

Wrote the new map screen, permission flow, lifecycle-scoped location collection and navigation wiring in Compose, matching the app's existing style. None of it could be compiled here because the compiler plugin and the full UI dependency graph were not assemblable by hand, so it remains the least verified part of the change.

What worked

State hoisting into a view model and lifecycle-aware effects made the start/stop behaviour of a location source easy to express correctly. Navigation with an optional argument and a default value behaved predictably with the existing route pattern.

What got in the way

Cannot be type-checked outside a full build, which is painful in constrained environments. Smart-casting of hoisted state through branch chains does not hold, so code had to be restructured defensively rather than relying on the compiler to confirm it.

Embedded the native map view and in-app navigation chrome in the existing UI toolkit, including lifecycle-aware hosting and permission-gated location. The screens compiled; they were not exercised on a device.

What worked

Interop hosting was enough to place the map beside the existing order list and detail flows without a second activity stack.

What got in the way

Lifecycle-owner imports needed a non-deprecated source, and factory wiring for the map view took a couple of revisions. Runtime UI behaviour was not observed on hardware.

Added map screens, navigation routes, and order-list entry points in Compose, wrapping the MapLibre view and driving it from a ViewModel. Interop and map-style timing needed extra controller state so sources were applied after the style loaded.

What worked

Existing navigation, ViewModel, and Material components extended naturally with a map destination, a next-site action, and permission-aware UI state.

What got in the way

AndroidView plus an asynchronous style callback raced with the first data sync. Overlay layout and enabled-state for next-site also needed follow-up passes. Nothing was executed on a device.

Built a new map screen, a status card, navigation routes with an optional argument, and entry buttons from two existing screens. State-driven UI composed well with the view model, but hosting a traditional view-based map component meant hand-forwarding every lifecycle callback through the interop wrapper, which is error-prone and hard to verify without running it.

What worked

Declarative state collection, lifecycle-aware collection with a minimum active state, and effect blocks keyed on inputs made it easy to stop location updates when the screen is not visible. Navigation arguments and optional parameters were straightforward to thread.

What got in the way

Interop with a legacy view requires manually mirroring the host lifecycle into the view's callbacks in the right order, with no compile-time help if one is missed. Layout interactions between a fill-size child and a weighted sibling needed careful reasoning that a preview would have answered instantly.

The existing Compose screens provided clear insertion points for a map/list switch and a Navigate action. The planned vendor map view would need interoperation with Compose, but implementation did not start because external prerequisites were missing.

What worked

The screen and view-model organization made the proposed user-interface changes easy to locate and reason about.

What got in the way

No Compose integration was compiled or exercised, so map-view interoperation and lifecycle behavior remain unverified.

Implemented a Compose map screen with a local coordinate plot fallback, permission UI, and buttons from the orders and detail screens. The UI compiled into the existing navigation graph; no on-device visual pass was run, but debug assemble and unit tests succeeded.

What worked

Existing Material components and navigation arguments were enough to add a map route without a new icon library. A stub plot composable could stand in for a native map view, which kept CI builds working without the licensed AAR.

Wrote two new screens plus a reusable wrapper that embeds an imperative native map view inside the declarative tree, with lifecycle-tied start/stop/destroy, effect-driven camera and data updates, and overlay banners. Also extended three existing screens and the navigation graph. This layer could not be compiled in the environment, so it remains the one unverified part of the change.

What worked

Hoisting state and deriving screen state from streams kept the view models thin and the screens declarative. The interop wrapper for an imperative view is a well-defined seam, and driving camera updates from keyed effects with value-equality state objects gave cheap, correct restart behaviour.

What got in the way

Bridging a view with its own lifecycle into the declarative model is the fiddliest part — ordering of start, resume, stop and destroy against disposal has to be reasoned out by hand, and mistakes there surface only at runtime. The bundled core icon set lacked two glyphs I needed, so one became a substitute and one had to be hand-drawn on a canvas. Nested interop lambdas also share an implicit label, which is an easy trap.

Added a map screen and entry points from the orders, detail, and sync flows in Compose, wrapping the vendor MapView in AndroidView. Catalog download progress, guidance controls, and navigation arguments were composed on top of the existing Material theme. Official vendor guidance for Compose map hosting was missing, so AndroidView plus lifecycle hooks were inferred from examples and API docs.

What worked

Existing list and detail screens could deep-link into the map with outlined buttons and nav arguments. AndroidView is a workable host for a classic MapView. A when-expression on catalog state restored smart casts that a delegated state property did not.

What got in the way

The vendor Compose map-view document was not found. LocalLifecycleOwner looked deprecated, so lifecycle-runtime-compose was preferred. LinearProgressIndicator’s progress API differed across Material3 versions and had to be chosen without a compiler. Catalog download UI needed an extra local val or when-branch so Compose could smart-cast sealed state.

Hosted the map SDK inside an existing Compose app with an Android view wrapper, permission prompts, and lifecycle handling so location updates start and stop with the screen.

What worked

Existing screens and theming could open the map, and a view wrapper was enough to attach MapView without replacing the UI toolkit.

What got in the way

Permission and lifecycle wiring needed several passes so a already-resumed screen still requested location without double-starting. A Material 3 import path was wrong on the first attempt. The UI was never run on a device.

Built the map screen in Compose, embedding the native map view, starting location updates only while resumed, and navigating from the orders list and order detail into the map. The UI compiled with the rest of the app; no on-device Compose run was recorded.

What worked

AndroidView, lifecycle effects, and the permission launcher were enough to host the native map and gate GPS to the visible screen without a new navigation framework.

Wrote a new map screen, a selection bar, loading and empty states, and hooked a view model's state flow into it, following the existing screens' conventions. Could not compile or render anything here, so correctness is by construction only.

What worked

Composable structure made it straightforward to match the surrounding code's patterns, and lifting a view model's state into a single observed value kept the screen declarative. Effect handling gave a clean place to own a start/stop resource lifecycle once I knew the underlying calls were suspending.

What got in the way

Disposal callbacks are non-suspending while the resource APIs I needed to stop were suspending, which is a mismatch that compiles-in-your-head wrongly until you check signatures; it required restructuring to an effect that awaits cancellation and cleans up uninterruptibly. Whether a layout scope is inline also silently changes whether early returns behave as expected.

Built the map destination, permission states, marker selection controls, and navigation actions in the app's existing Compose UI. Integration was straightforward overall, but initially selected material icons were unavailable in the project's configured icon set and had to be replaced.

What worked

Compose fit the existing architecture and made it practical to embed the map view alongside permission prompts and order controls.

What got in the way

The first icon choices produced unresolved references during compilation, so available alternatives were required.