You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(TODO upstream issue)
It seems sometimes the Future for an HTTP request remains uncompleted indefinitely (hours at least). This would likely be a bug in HttpClient (from dart:io) or some layer beneath it. Needs debugging to pin down. Consider overall timeout for long-poll requests #514 (comment)
(TODO upstream issue)
Running just dart pub get (or flutter pub get) can cause dependencies in pubspec.lock to change, in particular for the "supporting libraries" like collection that are bundled in the Flutter SDK. That's perhaps OK in itself (modulo the desire for pinning Flutter, listed separately above) — but it should really print some kind of message explaining why. I (Greg) was confused by this for months, and I bet it confuses lots of other Flutter developers too: pubspec.lock sometimes doesn't work as a lockfile #85
Dart linter
We'd like to catch when a future is accidentally discarded that should be awaited. There's a lint rule called discarded_futures, but it doesn't accomplish that: it flags many cases where the future isn't discarded at all.
Upstream issue, at Greg's comment explaining our view of the problem: Possible false positive in discarded_futures lint dart-lang/sdk#58889 (comment)
This is a frequently-requested feature in the community, as illustrated there.
Corresponding thread in our own tracker: Lint on unawaited futures #731
package:http
(For issues in this section, the right answer may be to abandon the pure-Dart package:http in favor of package:cronet_http on Android and package:cupertino_http on iOS. See #461 (comment) . In particular it seems like we've run into a couple of issues where the upstream answer for missing features in package:http is that package:http is not the future and people should use those packages instead.)
(TODO upstream issue) package:http should have the option to trust additional CAs.
Then ideally the Flutter embedding for Android would gain the ability to read the app's "network security config" XML file and respect a setting there by making package:http trust any additional CAs the user has added in system settings.
We would set that setting in our Android "network security config"; or pending that Flutter feature, would use the package:http option directly.
This tracking issue collects notes on potential work in Dart upstream that would benefit the (new) Zulip mobile app. See also:
Some of these are much more important to us than others. They're organized by where the work would happen, not by importance.
Dart standard library
Dart needs a way to make code using
DateTime.now
be testable:Code that uses DateTime.now is untestable dart-lang/sdk#28985
(TODO upstream issue)
Dart needs a way to make code that uses the local timezone be testable.
An upstream thread nearly on-point for this is:
Add support for running tests in multiple timezones dart-lang/sdk#44928
and see also the
DateTime.now
thread mentioned above.(TODO upstream issue)
It seems sometimes the
Future
for an HTTP request remains uncompleted indefinitely (hours at least). This would likely be a bug inHttpClient
(fromdart:io
) or some layer beneath it. Needs debugging to pin down.Consider overall timeout for long-poll requests #514 (comment)
Native assets / FFI
We'll want ICU data for:
Sort channel names the same way as Zulip web #1165
autocomplete: In @-mention results, match insensitively to diacritics #237
For emoji autocomplete, match insensitively to diacritics #1067
dart:convert
/ JSON decodingZulip impact: Potentially would save on the order of 10–50ms CPU time, and some memory, when loading server data. (The status quo is chunked so shouldn't drop frames; but we could move on from the loading screen a few frames sooner.)
Some measurements of status quo here: api: Use streaming UTF-8 + JSON decoding for the response #972
dart pub
Running just
dart pub get
(orflutter pub get
) can cause dependencies inpubspec.lock
to change, in particular for the "supporting libraries" likecollection
that are bundled in the Flutter SDK. That's perhaps OK in itself (modulo the desire for pinning Flutter, listed separately above) — but it should really print some kind of message explaining why. I (Greg) was confused by this for months, and I bet it confuses lots of other Flutter developers too:pubspec.lock sometimes doesn't work as a lockfile #85
Dart linter
discarded_futures
, but it doesn't accomplish that: it flags many cases where the future isn't discarded at all.Upstream issue, at Greg's comment explaining our view of the problem:
Possible false positive in
discarded_futures
lint dart-lang/sdk#58889 (comment)This is a frequently-requested feature in the community, as illustrated there.
Corresponding thread in our own tracker: Lint on unawaited futures #731
package:http
(For issues in this section, the right answer may be to abandon the pure-Dart
package:http
in favor ofpackage:cronet_http
on Android andpackage:cupertino_http
on iOS. See #461 (comment) . In particular it seems like we've run into a couple of issues where the upstream answer for missing features inpackage:http
is thatpackage:http
is not the future and people should use those packages instead.)(TODO upstream issue)
package:http
should respect HTTP cache-control headers, at least optionally.Make use of caching headers on server emoji data #950
(TODO upstream issue)
package:http
should have the option to trust additional CAs.package:http
trust any additional CAs the user has added in system settings.package:http
option directly.Trust user-added CAs on Android #461 (comment)
The text was updated successfully, but these errors were encountered: