Repository navigation
Refactor service extensions - #3397
Conversation
|
cc @HansMuller for framework stuff Note: I expect this to conflict slightly with #3388 |
9b081cf to
51f9c6b
Compare
|
cc @devoncarew for service extension changes |
There was a problem hiding this comment.
The driver extension needs to be able to run in unchecked mode because it is used to test performance.
There was a problem hiding this comment.
Yeah, this requires the profile mode though. Release builds shouldn't have any service extensions, that's a security vulnerability.
I can turn on the service extensions temporarily until we have a solution for profile builds if you want.
There was a problem hiding this comment.
That sounds fine. Or the driver extension could have a separate registration path. I imagine most of the time developers will have separate entry points for their driver test apps that use fake server backends and such (for example the test app for Stocks could replace fetching data from the Internet with a canned list of stock tickers). For production builds we should probably disable observatory altogether, so registering service extensions is a noop (or an error).
There was a problem hiding this comment.
Ok I've made it so that service extensions are always registered, for now. Once we have actual profile builds we can revisit how this works.
|
LGTM |
|
lgtm |
a073cc7 to
dba5dbd
Compare
|
made requested changes; will land when travis goes green unless i hear otherwise |
Bindings now have a debugRegisterServiceExtensions() method that is
invoked in debug mode (only). (Once we have a profile mode, there'll be
a registerProfileServiceExtensions() method that gets called in that
mode only to register extensions that apply then.)
The BindingBase class provides convenience methods for registering
service extensions that do the equivalent of:
```dart
void extension() { ... }
bool extension([bool enabled]) { ... }
double extension([double extension]) { ... }
Map<String, String> extension([Map<String, String> parameters]) { ... }
```
The BindingBase class also itself registers ext.flutter.reassemble,
which it has call a function on the binding called
reassembleApplication().
The Scheduler binding now exposes the preexisting
ext.flutter.timeDilation.
The Renderer binding now exposes the preexisting ext.flutter.debugPaint.
The Renderer binding hooks reassembleApplication to trigger the
rendering tree to be reprocessed (in particular, to fix up the
optimisation closures).
All the logic from rendering/debug.dart about service extensions is
replaced by the above.
I moved basic_types to foundation.
The FlutterWidgets binding hooks reassembleApplication to trigger the
widget tree to be entirely rebuilt.
Flutter Driver now uses ext.flutter.driver instead of
ext.flutter_driver, and is hooked using the same binding mechanism.
Eventually we'll probably move the logic into the Flutter library so
that you just get it without having to invoke a special method first.
|
lgtm! It'll be nice to have clear places to put service extensions going forward. |
4 participants
Bindings now have a debugRegisterServiceExtensions() method that is
invoked in debug mode (only). (Once we have a profile mode, there'll be
a registerProfileServiceExtensions() method that gets called in that
mode only to register extensions that apply then.)
The BindingBase class provides convenience methods for registering
service extensions that do the equivalent of:
The BindingBase class also itself registers ext.flutter.reassemble,
which it has call a function on the binding called
reassembleApplication().
The Scheduler binding now exposes the preexisting
ext.flutter.timeDilation.
The Renderer binding now exposes the preexisting ext.flutter.debugPaint.
The Renderer binding hooks reassembleApplication to trigger the
rendering tree to be reprocessed (in particular, to fix up the
optimisation closures).
All the logic from rendering/debug.dart about service extensions is
replaced by the above.
I moved basic_types to foundation.
The FlutterWidgets binding hooks reassembleApplication to trigger the
widget tree to be entirely rebuilt.
Flutter Driver now uses ext.flutter.driver instead of
ext.flutter_driver, and is hooked using the same binding mechanism.
Eventually we'll probably move the logic into the Flutter library so
that you just get it without having to invoke a special method first.