Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
* Clean up some flutter_tools tests
* Remove arbitrary retry that happens even for fundamental errors, and generally clean up _DevFSHttpWriter.
* Update dependencies (requires fixes; see next commit)
* Fixes for new dependencies.
The current API was broken in that you registered multiple
callbacks at once, but when you removed listeners, only the
primary listener was used to determine what was removed.
This led to unintuitive cases where the caller could get
unexpected behavior.
This updates the API to add and remove listeners using
a newly introduced [ImageStreamListener] object, a value
object that has references to the individual callbacks
that may fire.
flutter/flutter#24722flutter/flutter#32374flutter/flutter#32935
* add trailing commas on list/map/parameters
* add trailing commas on Invocation with nb of arg>1
* add commas for widget containing widgets
* add trailing commas if instantiation contains trailing comma
* revert bad change
This adds a keycode generator that incorporates input from the Chromium and Android source trees, as well as some local tables, to generate static constants for the LogicalKeyboardKey and PhysicalKeyboardKey classes, as well as mappings from each of the platforms we support so far (currently only Android and Fuchsia).
This code generator parses the input files, generates an intermediate data structure (`key_data.json`) that is checked in, and then generates the Dart sources for these classes and some static maps that will also be checked in (but are not included in this PR).
The idea is that these codes don't change often, and so we don't need to generate them on every build, but we would like to be able to update them easily in the future if new data becomes available. If the existing data disappears or becomes unusable, we can maintain the checked-in data structure by hand if necessary, and still be able to generate the code.
This PR only contains the code generator, not the classes themselves. In another follow-on PR, I'll run the generator and check in the output of the generator.
