Added a default entrypoint variable to match android syntax.

[gaaclarke]

relevant issue: flutter/flutter#33097

[matthew-carroll]

I'm not familiar with how things are packaged at the binary level in iOS, but do we not need a configurable bundle path along with the function name? The entrypoint on Android has both pieces in a data structure called DartEntrypoint...

[gaaclarke]

engine/shell/platform/darwin/ios/framework/Headers/FlutterEngine.h

Line 63 in cd0330e

- (instancetype)initWithName:(NSString*)labelPrefix project:(nullable FlutterDartProject*)project;

. You specify the bundle path when you create the FlutterEngine.

[matthew-carroll]

Is there a reason that's separated? Is the goal of this change to match Android? If so, shouldn't that involve pairing the entrypoint with the bundle path? The entrypoint only exists in a specific bundle, so if we think it's legitimate to lazily choose the entrypoint method, then it seems like you should be able to lazily choose the bundle path, right?

[gaaclarke]

I think that's a legitimate point. What you are proposing is a breaking change though. The idea with this PR is it gets us closer to Android without breaking. We can see what @xster thinks. I'd say that could be a different PR though.

[matthew-carroll]

We can see what @xster says, but seems like we could introduce a new constructor and a new dart entrypoint setter method, then soft deprecate the existing ones. That wouldn't be a breaking change, but it would move us forward for the future.

[matthew-carroll]

That DartEntrypoint contains 2 fields: an entrypoint function and a bundle path:

https://github.com/flutter/engine/blob/master/shell/platform/android/io/flutter/embedding/engine/dart/DartExecutor.java#L277

[xster]

ya, we're in kind of a pickle. The Android engine constructor doesn't ask for anything and everything's provided by the dart executor's execute.

The iOS engine asks for half of the stuff during init and the other half during run.

I think the ideal solution is probably:

• Deprecate the initWithName:(NSString*)labelPrefix project:(FlutterDartProject*)project init. If you give it a project, we'll just ignore it.
• Let the launchEngine:(NSString*)entrypoint libraryURI:(NSString*)libraryOrNil also have a withProject:(FlutterDartProject*)project to fulfill this API.
• Let there also be a launchDefaultEngine or some such so you can just [[[FlutterEngine alloc] initWithName:@"blah"] launchDefaultEngine] so that the most default engine can be launched without params or nils like Android.

It looks like _dartProject is only ever used in the launchEngine method in the FlutterEngine so moving it implementation wise shouldn't alter too much.

The break would be ok (but still needs announcing) since the only valid use of that API is add-to-app currently and we never shipped add-to-app yet.

[gaaclarke]

Hmm, I'll look into making this a bit deeper. If you want the API's to be closer though, shouldn't we introduce a class called FlutterDartEntrypoint in objc and make a method on FlutterEngine runWithDartEntrypoint:?

[xster]

Depends on how ambitious you want to get. If you want to go big, you can do flutter/flutter#33099 at the same time :)

[gaaclarke]

I'm unable to add the bundle to the run arguments. This would negatively affect our app launch time for full flutter apps since the engine is created and launch is only called after viewWillAppear:

There are still a few things I can do to make working with the FlutterEngine nicer though. I'll do everything but move the bundle to run/launch arguments.

[blasten]

q: is it main()or main? The Android embedding seems to use just main

engine/shell/platform/android/io/flutter/embedding/android/FlutterFragment.java

Line 202 in fde7c8c

private String dartEntrypoint = "main";

[matthew-carroll]

I can confirm that the literal value on Android is just the name of the function, no (). For the purpose of documentation it might be useful to represent it as "main()" for clarity.

[gaaclarke]

I've implemented the 3rd part of @xster's feedback, allow people to create and run FlutterEngine's with default values, [[[FlutterEngine alloc] initWithName:@"blah"] launchDefaultEngine] works.

I attempted to move the NSBundle/FlutterDartProject to run arguments but that will adversely affect startup time as mentioned in my previous comment. I suspect that Android will run into this as well.

I also attempted to deprecate FlutterDartProject, but that became a bit more involved and doesn't need to happen here.

[matthew-carroll]

Are you sure you want to allow nil here? I explicitly didn't allow that on the Android side. Instead I offered a factory method for DartEntrypoint.createDefault() to make it easy to resolve, but still explicitly selecting the entrypoint.

[gaaclarke]

I don't like the interface and I don't like the use of nil as placeholders for future calculations either. In this PR I've tried to make it so no one ever has to mention a nil to create or run an Engine. Truly eliminating the use of nil will require some excavation, a breaking change and some philosophy debates. I've avoided that to make some concrete progress on the issue.

[matthew-carroll]

Ok.