Background Execution Implementation for iOS #5539

bkonyi · 2018-06-15T00:23:56Z

Fixes iOS side of issue #3671.

An example plugin receiving location updates in a background isolate can be found here.

zanderso · 2018-06-18T19:26:45Z

shell/platform/darwin/ios/framework/Source/FlutterHeadlessDartRunner.mm

 @implementation FlutterHeadlessDartRunner {
  shell::ThreadHost _threadHost;
  std::unique_ptr<shell::Shell> _shell;
 }

- (void)runWithEntrypoint:(NSString*)entrypoint {
+- (instancetype)init {


Does this function and dealloc below need to be added explicitly?

No we don't. There was some other functionality added there before, but I forgot to remove these during cleanup. Will remove.

zanderso · 2018-06-18T19:30:16Z

lib/ui/dart_runtime_hooks.cc

+    library = Dart_LookupLibrary(library_name);
+    DART_CHECK_VALID(library);
+  }
+  Dart_Handle closure = Dart_GetClosure(Dart_RootLibrary(), closure_name);


Dart_RootLibrary() -> library? Otherwise library is unused.

Yes, will fix.

zanderso · 2018-06-18T19:30:51Z

lib/ui/dart_runtime_hooks.cc

+  }
+  Dart_Handle owner = closure;
+  Dart_Handle url = Dart_Null();
+  // TOOD(bkonyi): do we need to do this loop?


What happens when the closure is a static of a class instead of a top-level?

zanderso · 2018-06-18T19:32:39Z

lib/ui/dart_runtime_hooks.cc

@@ -223,4 +226,51 @@ void ScheduleMicrotask(Dart_NativeArguments args) {
  UIDartState::Current()->ScheduleMicrotask(closure);
 }

+void LookupClosure(Dart_NativeArguments args) {


This code will probably propagate error handles correctly, but I like to check Dart_Handle return values with DART_CHECK_VALID() unless there's some reason not to.

zanderso · 2018-06-18T19:33:59Z

lib/ui/plugins.dart

+
+part of dart.ui;
+
+abstract class PluginUtilities {


Is it possible to write tests of these methods? If so, I think we should have some.

Yes, it should be. I'll go ahead and write some.

Tests added in latest commit.

a-siva · 2018-06-20T16:47:20Z

lib/ui/dart_runtime_hooks.cc

+
+void LookupClosureLibrary(Dart_NativeArguments args) {
+  Dart_Handle closure = Dart_GetNativeArgument(args, 0);
+  if (Dart_IsClosure(closure)) {


If the incoming arg closure is not a closure, don't you need a check that it is a Function Object? further down you are calling Dart_FunctionOwner on it and this method will return an error if it is not a function object.

Yes, good catch. I'll add a check.

a-siva · 2018-06-20T16:52:03Z

lib/ui/dart_runtime_hooks.cc

+      url = Dart_LibraryUrl(owner);
+      break;
+    }
+  } while (!Dart_IsLibrary(owner));


Why do you need this loop, if the owner is not a library object highly likely you are not going to get a library object by looping. This code only works for top level functions. For others you need to get the Class object and then call classobj.library() on it.

This loop isn't needed and is already removed in the next patch. Wasn't sure that this worked in the first place (hence the TODO) but I've replaced this code since it didn't work.

bkonyi · 2018-06-20T20:35:53Z

New changes, PTAL!

zanderso · 2018-06-20T20:48:32Z

lib/ui/plugins.dart

 abstract class PluginUtilities {
-  static Function getClosureByName({String name, Uri libraryUri, String className}) {
+  /// Get a closure instance for a specific static or top-level function given


This should warn that it will fail to find the closure and return null if the closure is not otherwise used in the program. That is, it may get tree-shaken away in an AOT build.

zanderso

lgtm

bkonyi · 2018-06-20T23:42:04Z

Waiting on review from @cbracken (should be done today) and for this SDK change to be rolled into the engine.

cbracken

Dart comments attached. Taking a look at Obj-C next.

cbracken · 2018-06-22T20:31:39Z

lib/ui/plugins.dart

+  ///
+  /// **Warning:** if the function corresponding with `name` is not referenced
+  /// explicitly (e.g., invoked, passed as a closure, etc.) it may be optimized
+  /// out of the compiled application. To prevent this, avoid hard coding names


nit: hardcoding

cbracken · 2018-06-22T20:35:53Z

lib/ui/plugins.dart

+  /// retrieve the function's name.
+  ///
+  /// `name` is the name of the function we want a closure for. This is a
+  /// required parameter.


Typical wording is 'This must not be null.'

cbracken · 2018-06-22T20:37:30Z

lib/ui/plugins.dart

+  /// path for.
+  ///
+  /// Returns a [String] representing the path to the library which contains
+  /// `closure`. Returns `null` if an error occurs or `closure` is not found


Trailing period.

cbracken · 2018-06-22T20:37:52Z

lib/ui/plugins.dart

+  /// Get the path for the library which contains a given method.
+  ///
+  /// `closure` is the closure of the function that we want to find the library
+  /// path for.


Add: 'This must not be null.'

cbracken · 2018-06-22T20:38:32Z

lib/ui/plugins.dart

+  /// Get the name of a [Function] as a [String].
+  ///
+  /// Returns a [String] representing the name of the function if the function
+  /// exists, otherwise `null` is returned.


Document that closure must not be null.

cbracken · 2018-06-22T20:38:49Z

lib/ui/plugins.dart

+  /// Returns a [String] representing the name of the function if the function
+  /// exists and is a member of a class, otherwise `null` is returned.
+  static String getNameOfFunctionClass(Function closure) {
+    if(closure == null) {


nit: if (closure == null) {

cbracken · 2018-06-22T20:41:03Z

lib/ui/plugins.dart

+  static Function getClosureByName({String name, String libraryPath, String className}) {
+    if (name == null) {
+      throw new ArgumentError.notNull('name');
+    }


Here and elsewhere: for null checks, generally prefer: assert(name != null);

We typically reserve ArgumentError for malformed values -- e.g. we're passed a list of length 3 when we document it must be 4, etc.

cbracken · 2018-06-25T17:30:06Z

lib/ui/plugins.dart

+
+  /// Get the name of a class containing [Function] as a [String].
+  /// 
+  /// `closure` must not be `null.


Missing a close quote on null. Generally speaking though, we don't offset 'null' in monospace, so I'd remove them here and elsewhere in this patch.

cbracken · 2018-06-25T18:25:58Z

shell/platform/darwin/ios/framework/Source/FlutterChannels.mm

@@ -166,6 +166,11 @@ + (instancetype)methodChannelWithName:(NSString*)name
      autorelease];
 }

+- (void)setBinaryMessenger:(NSObject<FlutterBinaryMessenger>*)messenger {
+  [_messenger release];
+  _messenger = [messenger retain];


If _messenger and messenger are the same object this may result in the object being freed. Typically add a guard to avoid this:

if (_messenger != messenger) { [_messenger release]; _messenger = [messenger retain]; }

Actually, this method doesn't need to be here anymore. Must have forgotten to remove it.

cbracken · 2018-06-26T17:27:30Z

bkonyi · 2018-06-28T23:49:04Z

Blocked until this change is made available in the engine after the Dart SDK roll.

Hixie · 2018-07-02T22:25:39Z

lib/ui/plugins.dart

+part of dart.ui;
+
+/// Functionality for Flutter plugin authors.
+abstract class PluginUtilities {


can you talk about why you need these?

These are needed to lookup callback methods which are top-level functions or static methods in a class by name. The general flow is something like this:

Plugin user passes callback fooBar to the plugin.

The plugin calls PluginUtilities.getPathForFunctionLibrary, PluginUtilities.getNameOfFunction, and PluginUtilities.getNameOfFunctionClass to get the library URL, function name, and class name (if applicable). These values are passed from native as strings to a callback handler (this is a Dart method) setup by the plugin when a background event is triggered (e.g., AlarmManager fires).

When in the callback handler is invoked, PluginUtilities.getClosureByName is called with the function name, class name, and library path to retrieve the closure for the plugin user's callback. The plugin can then invoke said closure.

I am concerned about this API. From most serious to least serious concerns:

If someone uses this API directly with input that is in any way under the control of the user, it's a ripe for becoming an attack vector, where the user causes the app to jump to arbitrary top-level static functions.

This seems like it will be abused. For example, someone might store this data, pass it over the network to another instance of the program, then look up the address to jump to and do that. This would be very sketchy code, but this API doesn't make it feel bad.

What happens if someone caches these values across version updates, then uses them in a subsequent version of their code where the function has been tree-shaken out?

Least serious: if we have to have this API, it seems like we should have a single type that represents the path, name, and class of the closure.

Can you talk more broadly about what problem these methods solve? Maybe we can find a safer solution to this problem.

Good point. I feel like a lot of your concerns could be addressed by an opaque class with static methods that could:

Create an instance of the class given a closure which contains all the path, name, and class information.

Take in an instance of this class and return the closure it references.

This way, we can avoid having these strings visible and modifiable by the user, prevent abuse of what are basically Dart VM APIs, and make caching difficult. The only difficulty I see with this approach is passing said object over method channels since it would have to be serialized and deserialized in such a way that the data itself still remains private, but anyone can listen to a method channel if they know the name of the channel. I'd have to give this part some thought...

Your latest update resolves my concerns. Thanks!

strings.

Hixie · 2018-07-10T20:20:06Z

lib/ui/plugins.dart

+  /// [PluginUtilities.getCallbackFromHandle] to retrieve a tear-off of the
+  /// original callback. If `callback` is not a top-level or static function,
+  /// null is returned.
+  static int getCallbackHandle(Function callback) {


rather than return an int, you could return an object with a single field that's an int. That way you get better type checking and the APIs end up self-documenting more.

The main reason I hadn't done that in the first place was that the object would need to be serialized and then deserialized by the plugin author when being passed over the method channels. If that's not a problem, I'll go ahead and add described object.

Well they're going to have to serialize and deserialize the int, it's barely any more effort for them to do that using the int property of an object they're holding instead of just an int they're holding.

Fair enough. Added in the latest commit.

PluginUtilities.getCallbackHandle

googlebot · 2018-07-11T19:37:53Z

CLAs look good, thanks!

Added sentences stating that objects returned from getCallbackHandle and getCallbackFromHandle should be cached to avoid potentially expensive lookups.

zanderso · 2018-07-11T22:54:43Z

shell/platform/darwin/ios/framework/Headers/FlutterCallbackCache.h

+   Dart method `PluginUtilities.getCallbackHandle`.
+ - Returns: A FlutterCallbackInformation object which contains the name of the
+   callback, the name of the class in which the callback is defined, and the
+   path of the library which contains the callback.


It looks like this returns a triple of empty strings if the handle is bogus. Should it return nullptr instead?

zanderso · 2018-07-11T22:55:47Z

lib/ui/plugins/callback_cache.cc

+  if (iterator != cache_.end()) {
+    return iterator->second;
+  }
+  return {"", "", ""};


Should this returns something else to more clearly indicate the error?

zanderso · 2018-07-11T23:05:20Z

lib/ui/plugins.dart

+  /// original callback. If `callback` is not a top-level or static function,
+  /// null is returned.
+  ///
+  /// The result of this method should be cached in order to avoid repeated


Oh, I guess you could add a cache in this class.
static Map<Function, int> _forwardCache;
static Map<int, Function> _backwardCache;

getCallbackHandle(Function callback) {
// return if it's in _forwardCache
// otherwise do the _getCallbackHandle and add to both _forwardCache and _backwardCache
}

and similar for getCallbackFromHandle.

zanderso · 2018-07-12T19:54:33Z

analysis_options.yaml

@@ -42,7 +42,7 @@ linter:
    # - avoid_bool_literals_in_conditional_expressions # not yet tested
    # - avoid_catches_without_on_clauses # we do this commonly
    # - avoid_catching_errors # we do this commonly
-    - avoid_classes_with_only_static_members
+    # - avoid_classes_with_only_static_members # required for PluginUtilities caching / lookup methods


I think we'd have to check with @Hixie and/or @tvolkert , but I wonder if the intention here is to encourage use of the pattern of using singleton instances instead of all-static classes to make it easier to create mocks for testing, etc.. So instead of PluginUtilities being all-static, there would be one global instance of it set up when the framework is initialized.

Please don't comment out this line, though feel free to add additional comments based on the following to explain why this is set:

We want to avoid classes that can be instantiated or extended but only have statics, as in:

class A { static void test() { } } // ... A foo = new A(); // what is this?? // ... class B extends A { } // what is this??

The way we avoid allowing this to be instantiated is to have an invalid private factory constructor. The pattern is:

class A { // This class is only a namespace, and should not be instantiated or // extended directly. factory A._() => null; void test() { } }

Adding this will silence the warning.

zanderso

lgtm

bkonyi added 2 commits June 14, 2018 16:55

Background execution implementation for iOS

4aa0ace

Updated licenses + removed extra line of code

59f4c05

bkonyi requested review from chinmaygarde, cbracken and zanderso June 15, 2018 00:23

googlebot added the cla: yes label Jun 15, 2018

zanderso reviewed Jun 18, 2018

View reviewed changes

a-siva reviewed Jun 20, 2018

View reviewed changes

bkonyi added 2 commits June 20, 2018 11:08

Addressed some comments

2f3e0d8

Added tests for PluginUtilities and updated function params.

ddbd5f3

zanderso reviewed Jun 20, 2018

View reviewed changes

Updated documentation for getClosureByName

b15e35c

zanderso approved these changes Jun 20, 2018

View reviewed changes

cbracken reviewed Jun 22, 2018

View reviewed changes

Updated docs for plugins.dart and changed ArgumentErrors to asserts

9806222

cbracken reviewed Jun 25, 2018

View reviewed changes

Removed unused method and s/null/null/g

3341e83

This was referenced Jun 26, 2018

alarm_manager plugin stopped working (Could not launch engine in configuration) flutter/flutter#17566

Closed

Flutter should provide an abstraction for background execution flutter/flutter#3671

Closed

cbracken approved these changes Jun 26, 2018

View reviewed changes

bkonyi mentioned this pull request Jun 28, 2018

Updated background execution implementation for Android #5640

Merged

Hixie reviewed Jul 2, 2018

View reviewed changes

Updated callback lookup/passing to use handles instead of human readable

8373f88

strings.

Hixie reviewed Jul 10, 2018

View reviewed changes

Added CallbackHandle wrapper for handles returned from

f4d23c2

PluginUtilities.getCallbackHandle

googlebot added cla: no and removed cla: yes labels Jul 11, 2018

bkonyi force-pushed the headless_plugin branch from 6f27b97 to 59f4c05 Compare July 11, 2018 19:37

googlebot added cla: yes and removed cla: no labels Jul 11, 2018

flutter deleted a comment from googlebot Jul 11, 2018

bkonyi added 6 commits July 11, 2018 13:06

Updated licenses

87d3d80

Fixed analyzer complaints

14e7aca

Merge branch 'master' into headless_plugin

af25c66

Update licenses_flutter

2ff7690

Update licenses_flutter

48261fd

Updated docs for plugins.dart

abcabee

Added sentences stating that objects returned from getCallbackHandle and getCallbackFromHandle should be cached to avoid potentially expensive lookups.

zanderso reviewed Jul 11, 2018

View reviewed changes

bkonyi added 3 commits July 11, 2018 16:38

Added caching in PluginUtilities

2ec1ef4

Fix analyzer issues

8cc4394

Addressed comments

81492d6

zanderso reviewed Jul 12, 2018

View reviewed changes

bkonyi added 2 commits July 12, 2018 14:52

Update analysis_options.yaml

514df89

Added private factory to make analyzer happy

c6a955d

zanderso approved these changes Jul 12, 2018

View reviewed changes

bkonyi merged commit 672e587 into master Jul 13, 2018

zanderso mentioned this pull request Jan 17, 2023

PluginUtilities.getCallbackHandle and tree-shaking flutter/flutter#118608

Open

Background Execution Implementation for iOS #5539

Background Execution Implementation for iOS #5539

Uh oh!

Conversation

bkonyi commented Jun 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkonyi commented Jun 20, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zanderso left a comment

Choose a reason for hiding this comment

Uh oh!

bkonyi commented Jun 20, 2018

Uh oh!

cbracken left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

bkonyi commented Jun 15, 2018 •

edited

Loading

cbracken Jun 25, 2018 •

edited

Loading