mikkeli
314a3ea059
The presentation layer imported Iperf3Service directly, so the UI was welded to the MethodChannel transport: the view model named it, and the screen constructed one. Dependency direction was already inward-only, but the UI depended on an implementation rather than a contract. Iperf3Runner states that contract in the domain layer in five members, in pure Dart with no Flutter import, and Iperf3Service implements it. The view model and screen now take an Iperf3Runner; main.dart is the only file that names a concrete one, which makes it the composition root. Two consequences worth having. The UI can be driven against an in-memory runner with no MethodChannel, native library or device involved. And a test double implements five stable members rather than tracking every public member the transport happens to expose — the previous double, forced to implement the concrete class, broke twice while this branch's work was going on. Also drops flutter/foundation from the data layer: debugPrint gives way to dart:developer, leaving flutter/services (where MethodChannel lives) as that layer's only Flutter dependency. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
iperf3-gui
A Flutter-based Android GUI wrapper for iperf3, the popular network performance measurement tool.
Features
- Client-mode network throughput testing
- Configurable server, port, duration and parallel streams
- Live iperf3 output, streamed line by line while the test runs
- Stop a running test early
- Copy the transcript to the clipboard
- iperf3 3.19 compiled into the app as a native library — no external binary
Architecture
lib/
├── domain/
│ ├── models/ # TestConfiguration, Iperf3Result
├── data/
│ └── services/ # Iperf3Service (MethodChannel → JNI)
├── ui/
│ └── features/
│ └── test_run/ # TestRunScreen, TestRunViewModel
└── main.dart # App entry point
android/app/src/main/
├── kotlin/…/IperfRunner.kt # MethodChannel handler, runs tests off the platform thread
└── cpp/iperf_jni.c # JNI bridge into the iperf3 API
See docs/README.md for the data flow, the native API surface and the design decisions behind them.
Why JNI instead of executing a binary
Android SELinux in Enforcing mode blocks execve() from the untrusted_app
domain, so shipping an iperf3 ELF in assets and running it via Process.start()
fails with "Permission denied". iperf3 is therefore compiled as a shared library
(libiperf3jni.so) and called in-process over JNI.
assets/iperf3/ still holds the pre-compiled binaries from that earlier
approach. They are not declared in pubspec.yaml, so they are not packaged into
the APK, and nothing in the app reads them.
Building
Prerequisites:
- Flutter 3.47+
- Android SDK with platform android-36
- JDK 17
- NDK r28+ and CMake 3.22.1 (for the native build)
flutter pub get
flutter analyze
flutter test
flutter build apk --debug
adb install -r build/app/outputs/flutter-apk/app-debug.apk
Testing against a local server
iperf3 -s -p 5201 # on a machine on the same network
ip -4 addr show # note its address
Enter that address in the app, then press GO.
Dependencies
- Dart:
provider - Native: iperf3 3.19 + cJSON, built by CMake for
armeabi-v7aandarm64-v8a
License
MIT — bundled iperf3 3.19 is BSD-3-Clause licensed.