This reverts commit 92ef2b9ce1.
This requires either runApp() or
WidgetsFlutterBinding.ensureInitialized() to have been called before
using any MethodChannels. Plugins broadly rely on MethodChannels and
right now there's no general requirements that they be constructed
within the runApp call, so the ecosystem breakages from this are broader
than originally thought. Reverting for now.
* Make it possible to override the FLUTTER_TEST env variable without unsetting it.
* Switch to using platform instead of Platform.
* Document the bindings, and introduce tests that initialize multiple WidgetsBindings with different environments.
* Add tests for the flutter platform test.
* Add license headers
* Fix lints
* Remove trailing whitespace
* Respond to Jonahs comments
* Respond to Ians comments
* Mock out the HttpServer in flutter_platform_test
* Mock out the HttpServer in flutter_platform_test
* Explain why we mock out the HttpServer in flutter_platform_test
* Prepare for HttpClientResponse Uint8List SDK change
An upcoming change in the Dart SDK will change `HttpClientResponse`
from implementing `Stream<List<int>>` to instead implement
`Stream<Uint8List>`.
This forwards-compatible change to `_MockHttpClientResponse` is being
made to allow for a smooth rollout of that SDK breaking change. The
current structure of the class is as follows:
```dart
_MockHttpClientResponse extends Stream<List<int>> implements HttpClientResponse {
...
}
```
This structure would require that the Dart SDK change land atomically
a change to the class (`extends Stream<Uint8List>`). This atomic landing
requirement doesn't play well at all with Flutter's roll model vis-a-vis
the Dart SDK's roll model to Google's internal repo. As such, this commit
changes the structure of `_MockHttpClientResponse` to be:
```dart
_MockHttpClientResponse implements HttpClientResponse {
final Stream<Uint8List> _delegate;
...
}
```
Once the Dart SDK change has fully rolled out, we can simplify this class
back to its former structure.
https://github.com/dart-lang/sdk/issues/36900
* Review comment
# Description
Currently the benchmarks test prints a scary warning message, even when it passes, that a benchmark is being run with asserts enabled.
Normally we don't want developers to do this, because the performance of code with asserts is not characteristic of what end-users will experience. However, we need to unit-test benchmarkWidgets, so I've added a contraindicated option to suppress the warning for the test.
# Related Issues
25049 (comment)
This PR solves two problems: currently, the onExit is called for a mouse pointer the moment the removal message is received, except that by the time it actually calls it, there is no _lastEvent for it in the mouse tracker (it's already been removed), resulting in an event being passed to the onExit that contains nulls for the position. Also, removePointer events don't actually get created with a position, although they easily could be, so that even the the _lastEvent in the mouse tracker were still populated, it would still give a null position and delta.
This PR adds support for the position and delta in a PointerRemovedEvent, and populates them. In addition, when a remove event is received, it doesn't actually remove the pointer until the mouse position check that gets scheduled actually happens.
* Deprecates `BinaryMessages` in favor of a default instance of `BinaryMessenger`, called `defaultBinaryMessenger`
* Platform channels use the `defaultBinaryMessenger` for their binaryMessenger default argument.
