Hacker News new | past | comments | ask | show | jobs | submit login

I think a lot of these comments are not necessarily valid or have been addressed already and we've lost the actual productive feedback in the mess.

- Integration testing - This exists and is very commonly used: https://docs.flutter.dev/cookbook/testing/integration/introd...

- Location - This 100% should be a core offering, its crazy that its not for mobile application.

- iOS dark mode - Flutter supports Dark Mode - https://api.flutter.dev/flutter/material/ThemeMode.html

- iOS keyboard dismiss decoration - Not sure on this.

- iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.

- iOS NavigationLink widget - Not familiar with this construct but easy to build yourself.

- iOS checkbox widget - Totally agree but also easy to build directly.

- Android camera that doesn't randomly crash (unfixed for 3 years) - We've got a couple application that use camera and never had this issue.

- Android date-time picker - This has been in for a long time: https://api.flutter.dev/flutter/material/showDatePicker.html

- Usable documentation for Navigator 2.0 - I think the updated docs on navigation have addressed this issue largely.

- Debugger visibility into Dart async tasks - You can 100% debug async tasks.

- Stop HTTP requests on timeout - This exists in Flutter https://stackoverflow.com/a/51489701

- Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.

- UI inspection tools that don't randomly stop working - Never had this happen.




Just an additional note: Integration testing was indeed completely broken for a while, with the docs stating otherwise. They reworked it a few releases ago and since then it works well for us (limited usage, but completely stable for what we do with it).


Do you have tests that run on your host machine, can start an API server and interact with it, and also drive the Flutter app? Or do your tests run on the mobile device?


The tests run on the mobile device, or rather mostly the emulator. No API server to interact with (and I would not know why?). The shop uses integration tests for three things: 1. Testing some migrations 2. Click through the app, as part of a release checklist 3. Run crypto operation to check multiple plugins for continued compatibility.


Integration testing supports only running tests inside the device. If your test needs to start an API server, then you must use the deprecated and broken flutter_driver module. See the bug I linked.

Flutter's Cupertino dark mode support is broken. Some text is invisible. Some widgets are unusable. Cupertino Dark mode theme support is completely absent. See the bug I filed, with a comprehensive reproduction with screenshots. It's like the dev who added it just decided to stop half-way.

> - iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.

Please use an iOS device and notice how nicely one can dismiss the keyboard in iMessage, FB Messenger, Instagram, etc. Getting that behavior in Flutter requires using a third-party package.

The Material date picker is not a date-time picker. Letting the user pick a date & time requires a lot of extra code. For example, I spent many hours writing a widget that displays the date & time and lets one click to change it, like in Google Calendar.

See the bugs I linked about Navigator. The docs have multiple omissions. I lost a day and a half on them.

Yes, you can debug tasks with a breakpoint. You cannot see which async tasks are running. You cannot pause a task. I needed to debug concurrent RPC problems and tried using print. Unfortunately, print provides no visibility into tasks running in standard library code, like timed-out HTTP requests that continue running.

You can timeout waiting for an HTTP request to finish, but the request still continues in the background. If it's a large upload then it can continue for minutes, draining the device's battery and transferring data. See the bug I linked.

> - Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.

How do you install on iOS? I tried `flutter build --flavor staging --release` and then `flutter install` which fails saying that I must supply `--flavor`. But when I supply `--flavor` it says the parameter is not supported. See the bug I linked. I spent a few hours and figured out how to first do a Flutter build and then use XCode to build again, then use Devices & Simulators to manually install the archive. But this requires that I remove the app from the device first, which destroys the app state. This makes manual testing extra slow. The process is noxious.

Flutter Inspector in Android Studio on macOS breaks 1 out of 5 times I try to use it. I often waste a few minutes trying to figure out why my code changes did not have the desired change on the widget tree. Then I finally realize that the widget tree pane is broken and I need to restart Android Studio. It's been like this since 2018 through multiple upgrades of Flutter, Android Studio, and macOS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: