flutter/samples

1. This repository is a monorepo of independent Flutter samples, not a single product app. Each sample is usually self-contained and can be run from its own directory, with the repository root acting as the catalog, docs, and CI entry point.

2. The top level is organized by sample category: quickstarts and demo apps (animations, form_app, navigation_and_routing, testing_app, etc.), native platform samples (add_to_app, platform_channels, platform_view_swift, ios_app_clip), and web embedding samples (web_embedding). The root README is the main index that explains which pattern each subproject demonstrates.

3. Most Flutter samples follow the standard cross-platform Flutter layout: lib/ for app logic, test/ for widget/unit tests, and platform folders like android/, ios/, linux/, macos/, windows/, and web/ where needed. These platform folders are mostly bootstrap shells; the real sample logic typically lives in Dart under lib/.

4. A recurring boundary in the repo is “Flutter UI vs native host.” This is most explicit in add_to_app, where Android and iOS host apps embed a Flutter module either as a full-screen view, a prebuilt module, a plugin-using module, or a multi-engine setup. The architecture here is about integration seams between host lifecycle/code and Flutter engine/module code.

5. Another major boundary is platform communication. platform_channels demonstrates the Flutter-side consumption of MethodChannel, EventChannel, BasicMessageChannel, and custom codecs, with native handlers on Android and iOS providing sensor/data streams and commands. pedometer goes further with direct native interop via FFI/JNI-style generated bindings, showing a lower-level Dart-to-native path than platform channels.

6. Several samples are structured around explicit layers or clean boundaries. compass_app is the clearest example: it splits into data/ (repositories, services, API clients, local storage), domain/ (models and use cases), ui/ (screens, view models, widgets), routing/, config/, utils/, and testing/. It also includes a companion server/ package, so the architecture diagram should show a Flutter client talking to a separate Dart backend.

7. Generated code is an important repo-wide mechanism. Many samples use codegen for immutable models and JSON serialization (*.freezed.dart, *.g.dart), and some examples include Pigeon-generated or FFI-generated bindings. This means part of the “source of truth” is in handwritten schema/model files plus generated outputs that bridge typed data across layers or platforms.

8. Several samples are UI galleries rather than business apps. animations, cupertino_gallery, and material_3_demo are primarily presentation and interaction showcases, with their main flow being navigation from a home/catalog screen into feature demos. Their architecture is dominated by reusable widget pages, themed screens, and test coverage around each showcased interaction or component.

9. Navigation-focused samples isolate route structure as a first-class concern. navigation_and_routing has app/scaffold/auth/data/screens/widgets layers and demonstrates screen transitions and nested routes. The important boundary is between shared app shell state and route-specific screens like authors, books, details, settings, and sign-in.

10. Testing is a core theme in testing_app, which is split into app screens, model/state logic, and layered tests including integration tests. Its architecture is meant to show how UI state, model state, and automated tests fit together, rather than introducing external services.

11. Web embedding is another distinct subsystem. In web_embedding/element_embedding_demo, Flutter is embedded into a custom DOM host element, while web_embedding/ng-flutter combines an Angular host app with a Flutter sub-app. The boundary here is not native mobile code but browser DOM/JS integration versus Flutter-rendered content.

12. A small number of samples center on specialized platform features: simple_shader and simple_sdf focus on fragment shaders; google_maps focuses on plugin-backed map rendering and local asset data; android_splash_screen and dynamic_theme demonstrate platform-specific UX/system integration. In these, the architecture is mostly “Flutter app plus one specialized platform capability.”

13. Tooling and automation are repo-wide support systems rather than sample features. GitHub Actions workflows build Android/iOS and run maintenance/review automation, and the tool/ directory contains scripts for CI, cleanup, and release tasks. These do not affect sample runtime architecture, but they define how the samples are validated and published.

14. Overall, the repository’s architectural pattern is: many small, runnable examples sharing the Flutter/Dart ecosystem, each emphasizing a different boundary—UI composition, routing, testing, native embedding, platform channels, FFI, or web integration. An architecture diagram should therefore show a cataloged set of independent sample apps, not one shared application core.