Flutter

Relied on the existing single-codebase mobile setup to recommend a pure-Dart map approach for both report and live views. Tried to verify with the command line tools, but no toolchain was present in the environment so analysis and tests could not run.

What worked

Single codebase for both mobile platforms made the map choice straightforward with no per-platform SDK setup.

What got in the way

Command line tools were absent, so verification was deferred to the developer machine.

Relied on the existing cross-platform UI framework to add a report map, a new live tracking screen with polling, navigation wiring, and widget tests from one codebase.

What worked

Shared widgets, navigation, and state patterns made it straightforward to add new screens and keep report and live views consistent.

What got in the way

The command-line toolchain was not present in the environment, so package fetch, analysis, and widget tests could not be executed.

Installed the SDK, resolved dependencies, and used analyze and test to verify route and live-position changes. After upgrading to a newer stable release, dependency resolution, analysis, and the full test suite succeeded.

What worked

Dependency resolution, static analysis, and test execution worked consistently once the compatible SDK release was installed.

What got in the way

Initial SDK version did not satisfy the project's Dart constraint, requiring a second large download and reinstall.

Installed the Flutter SDK from the official release archive and used it to resolve dependencies, run static analysis, and run the full test suite. Initial suite had one viewport-related widget failure that passed after adjusting the test, with a clean rerun.

What worked

Package resolution, analysis, and tests all ran consistently once installed, giving a clear verified gate before finishing.

Fetched the missing SDK with a download script, then used version, package resolution, static analysis and the full test suite to verify route drawing, live refresh and test fallback behavior. All commands completed and tests passed.

What worked

Package resolution, analysis and widget tests ran cleanly once the SDK was present.

Used the Flutter CLI to resolve packages, analyze the codebase, and run widget and unit tests for route rendering, live polling, and empty states. The toolchain was absent initially so it was bootstrapped manually, after which analysis and the full test suite passed.

What worked

Package resolution, static analysis, and the test runner gave clear pass or fail signals once installed. Tests covering bounds math, route display, and live versus finished states ran hermetically.

What got in the way

Missing preinstalled SDK required a manual download and setup step. Tile image failures were noisy in widget tests until a fake tile response was added.

Inspected a single-codebase mobile app and implemented shared route and live-map UI for both phone platforms from that one codebase. Project inspection and edits were straightforward; verification was limited to file review because the SDK was unavailable.

What worked

Single codebase covered both mobile platforms with one map widget, keeping implementation and future maintenance small.

What got in the way

Local SDK binary was absent, so dependency fetch, analysis and tests could not be run and new tests were left unverified.

Flutter wasn't installed in the environment, so I downloaded the current stable Linux tarball from the release manifest and used flutter pub add/get, analyze, test and dart format throughout. Baseline analyze and tests passed right away. The widget tests caught a real controller-before-attach bug in my map widget. Fake-clock tests needed runAsync handling for futures that complete on the real event loop. A timing-based test flaked under parallel load, and the cause turned out to be a real race in app code.

What worked

The release manifest JSON made it easy to find the current stable archive. The tarball install worked without fuss apart from a git safe.directory tweak. Analyzer output was precise, and the test runner's exception output pointed straight at the framework assertions.

What got in the way

The SDK download is large. The interaction between the fake async zone and real-zone futures in widget tests isn't obvious and cost a debugging round. Running the full suite in parallel made a timer-sensitive test fail intermittently, so diagnosing it took repeated runs.

The SDK was not on the machine, so the stable Linux archive was downloaded and unpacked. It then resolved packages, analyzed the app, and ran widget tests for the bundled map and live owner view. Analysis reported concrete const and brace issues. A later home-screen test hung after an earlier test loaded fixture assets, and the process kept running well past the requested timeout until it was killed. Switching those tests to an in-memory source cleared the hang. The last full run analyzed clean and passed every test. No phone or emulator was available, so the map was not exercised on a device.

What worked

The release archive installed cleanly, package resolution succeeded, and the analyzer named the exact invalid const uses. Once the fixture-loading interaction was removed, the same toolchain finished the full widget suite.

What got in the way

Getting a toolchain required a large manual download. Ordered widget tests then hung with no failure message while loading bundled fixtures, and the requested test timeout did not stop that run. Diagnosing it meant reading the test binding and killing the process.

Flutter was not installed in the environment, so I downloaded the current stable SDK archive using the public releases manifest. After that I used it to fetch packages, add dependencies, format, analyze and run the widget and unit tests. The baseline and final runs were clean, and the test suite grew from 25 to 29 passing tests.

What worked

The releases JSON made it easy to find and fetch the right stable version. Adding packages with pub add, plus fast analyze and test runs, gave a tight feedback loop. Widget tests with fake timers made it straightforward to test periodic polling.

What got in the way

The SDK is a large manual download when it isn't preinstalled, and it needed a git safe.directory tweak. I could not build for Android or iOS because the platform toolchains were missing, so native wiring went unverified.

Flutter wasn't installed, so I picked the current stable from the public releases manifest and downloaded it in the background while I wrote code. Then I used flutter pub add, flutter analyze, dart format and flutter test to add a maps plugin and check the new widgets, screens and tests. Analyze came back clean and all 31 tests passed. I could not do device builds because there was no Android or iOS toolchain.

What worked

The releases manifest made it easy to find a stable build that matched the project's Dart constraint. pub add resolved the plugin cleanly. The widget-test failures were specific and easy to act on: an item pushed offscreen by the small default test viewport, and a UTC-vs-local DateTime equality check.

What got in the way

The default 800x600 test surface quietly pushed content out of view once a tall map was added, so some tests needed an explicit view size or a stubbed map builder. A full SDK download is a heavy step just to run analysis and tests.

The Flutter binary was absent, so I downloaded the stable Linux archive, unpacked it, and used that toolchain to resolve packages, analyze the app, and run the test suite. Analysis finished clean. The suite passed after an application timing assertion was fixed.

What worked

The stable archive unpacked and reported its version. Package resolution, static analysis, and the test runner then completed, and the full suite passed on the rerun.

What got in the way

The first invocation failed because the flutter command was not installed. Downloading the official archive removed that blocker.

Flutter wasn't installed, so I shallow-cloned the stable SDK in the background and used it for pub get, pub add, analyze and widget tests. The existing tests passed right away. After adding the map feature, analyze found no issues and all 33 tests passed. I couldn't build for devices because there was no Android SDK or Xcode.

What worked

Cloning the stable branch gave me a working toolchain with no extra setup. Widget test failures were easy to diagnose: one was a too-small default test viewport, and another was a map that needed an extra frame before markers rendered. The analyzer and formatter gave clean, predictable results.

What got in the way

Fixture assets loaded on real async outside the test's fake clock, so I needed runAsync-style handling before the screen settled. That isn't obvious to someone new to Flutter testing.

The SDK binary was missing, so the stable release was downloaded and unpacked before package or test commands would run. After that it added the map packages, analyzed the project, and ran the widget tests. One widget drew the finished route and the updating position for both phone targets from the existing project files. No emulator was available, so the map was not opened on a device.

What worked

Once the binary was on the path, package installation and the test runner worked. The runner named the timing failures in the live-map checks, and after those checks were adjusted the full suite passed.

What got in the way

The first package command failed immediately because the binary was missing, and setup meant fetching the full stable archive. Static analysis also failed the process on one info-level lint until that lint was rewritten. Phone emulators were absent, so store builds and on-screen tiles were never run.

The Flutter command was not available, so a stable SDK archive was downloaded and unpacked. That install then added the map packages, ran analysis, executed the widget tests, and listed a desktop device.

What worked

The public release index made it straightforward to pick a stable build that met the app's SDK constraint. After extraction, package install, analysis, and the test suite all ran from that SDK without further setup.

What got in the way

Package install and tests could not start until a full SDK archive was fetched and unpacked. A desktop target was listed afterward, but there was no display, so the app was never launched and the map was not seen on screen.

The app was already a Flutter codebase, but the Flutter tool was not on the path, so the stable SDK was downloaded and unpacked before any command could run. Pub get, format, analyze, and the test runner then worked. The installed stable was newer than the implicit-engine template the app used, and analyze failed until gesture, factory, and service types were imported directly because Material no longer re-exported them. After that fix, analyze was clean and the full suite passed.

What worked

Once the SDK was on the path, pub get, the analyzer, and the test runner completed the implementation loop. The second full test run passed every test, including the new map and live-update cases that used a stand-in for the map view.

What got in the way

The first analyze on this stable failed in the new map widget: Material did not export the gesture recognizer, factory, and platform types the widget called, so those names were undefined until the libraries were imported directly. Installing the SDK also meant fetching a multi-gigabyte archive before any of those commands could start.

The Flutter CLI was not on the machine, so the stable Linux SDK 3.47.5 was downloaded from the official release archive and extracted. That release satisfied the app's Dart constraint, which an older 3.38 stable line would not. Package resolution, the analyzer, and the full test suite then all completed cleanly.

What worked

After the SDK was on the path, pub get, analyze, and test ran through without tool failures. The same widget tests covered the shared map used for a finished route and a position that updates.

What got in the way

The first package-add command could not start because the flutter binary was absent. Choosing a release also took extra checking, because the project's Dart constraint was newer than the Dart version bundled with the 3.38 stable line.

The Flutter command was not available, so I downloaded the stable Linux archive, extracted it, and used that toolchain to resolve packages, format the project, analyze it, and run tests. The archive install and version check succeeded. Analysis and the first full test run failed on issues in the new map code and tests; after those fixes, analysis was clean and the suite passed. The map was not run on a phone.

What worked

Once the SDK was on disk, package resolution, formatting, the analyzer, and the test runner all ran through. The test runner reported the two failing cases clearly enough to fix them, and a later run passed the full suite, including the live position update.

What got in the way

Getting a toolchain required a large archive download because nothing was installed. The default widget-test surface also left lower content unbuilt, so one finder missed text until the test view was enlarged.

Installed the SDK after it was missing from the environment, added map widgets on iOS and Android from one codebase, then used the CLI to fetch packages, analyze, and run the full widget-test suite until it was clean.

What worked

One widget tree covered both phones. After the SDK was in place, package fetch, static analysis, and the full test run all succeeded, which was enough to finish the maps work without a native split.

What got in the way

The SDK was not on PATH and had to be downloaded and unpacked first, which was slow. Widget tests then fought timers, lazy lists, route transitions, and fake-async loading, so several retries were needed before the suite passed.

Used Flutter as the existing iOS/Android codebase, then cloned the SDK, added map packages, wrote shared map widgets, and ran analyze plus the full widget-test suite until it was clean.

What worked

Once on PATH, pub add, analyze, format, and test all worked. Widget tests were enough to cover the report map, live pin updates, and the in-progress walk row without a device.

What got in the way

Flutter was not installed or on PATH at first, so the first pub add failed and the SDK had to be cloned before any package or test work could proceed.

Installed the stable SDK, then used the CLI to resolve packages, run static analysis, and execute the widget test suite after adding map widgets and platform key wiring.

What worked

After the SDK was on PATH, package resolution, analysis, and tests were consistent. Analyzer messages were specific enough to fix. Once a short viewport issue in one test was corrected, the full suite passed.

What got in the way

The SDK was not already on PATH, so the first CLI invocation failed and the Linux archive had to be downloaded and unpacked before any Flutter command would run. A device or simulator run was not available in this environment.

Installed the SDK after it was missing from the environment, added map packages, then used analyze and the test runner to finish a cross-platform maps feature.

What worked

Once on PATH, package add, analyzer, and the test suite were enough to implement map widgets, native key wiring, and UI coverage. A later full test run went green with a clean analysis.

What got in the way

The SDK was not installed at first, so the initial package-add command failed. The first combined format-analyze-test run also failed because a map made a later list row miss the default test surface; that was a test viewport issue, not an SDK crash.

Flutter provided one codebase for the iPhone and Android map, polling, state, and widget-test changes. The client implementation was completed, but the absent Flutter SDK prevented analysis, dependency resolution, and test execution in this environment.

What worked

The existing widget, state, platform, and test structure supported a shared map component and separate completed-report and live-tracking experiences without introducing another application stack.

What got in the way

The Flutter executable was unavailable, so the implementation could not be validated with Flutter analysis, plugin compilation, or the Flutter test runner.