Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android embedding refactor PR1: JNI Extraction to FlutterJNI.java #7098

Conversation

matthew-carroll
Copy link
Contributor

@matthew-carroll matthew-carroll commented Dec 5, 2018

PR Context:
The Android embedding refactor is being decomposed, re-reviewed, and merged as experimental into master. This is the 1st such PR to begin decomposing and merging.

The code in each PR is extracted from a staging branch that has accumulated months of work up to this point: https://github.com/flutter/engine/compare/21008_rewrite-android-embedding-to-reduce-coupling

What this PR does:
This PR attempts to start with the smallest change possible in a core area that will allow for expansion in future PRs. Therefore, this PR introduces FlutterJNI.java as an extraction of JNI calls from FlutterView.java and FlutterNativeView.java. This extraction is a big part of what will allow development of a new embedding without further effecting the existing embedding.

This PR is one of the few PRs that alters existing code, but the modifications are relatively narrow in scope.

Reminder of approach:
Though somewhat dated, the approach towards this refactor is available to Google devs here:
https://docs.google.com/document/d/1TaDV1ZAwBeVBkBA2rtBbt1BRr96WSFqEv6MNAHdgmGY/edit?usp=sharing

@matthew-carroll
Copy link
Contributor Author

matthew-carroll commented Dec 5, 2018

  • Source tree is unfrozen

Copy link
Contributor

@amirh amirh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed everything but platform_view_android_jni.cc which I'm less comfortable with.
Overall looks good, left a few nits.


private FlutterRenderer.RenderSurface renderSurface;
private PlatformMessageHandler platformMessageHandler;
private final Set<EngineLifecycleListener> engineLifecycleListeners = new CopyOnWriteArraySet<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we expected to modify this from different threads?
If so would be nice to note in e.g addEngineLifecycleListener that this is thread safe.

}
//------ END TextureRegistry IMPLEMENTATION ----

// TODO(mattcarroll): describe the native behavior that this invokes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment for all of this, I think there are good chances for these TODO comments to be forgotten, so I'd rather either solving the documentation TODOs right now, or linking Github issues for each of them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I missed these comments when I added GitHub issue links to the TODOs. I will try to remember to address these TODO comments in the next PR that I'm preparing.

shell/platform/android/platform_view_android_jni.cc Outdated Show resolved Hide resolved
Copy link
Contributor

@amirh amirh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that it would make it easier for me to followup on the review if you add new commits on top of the original one (this way I can more easily see the delta since I last reviewed).

}

public void addEngineLifecycleListener(@NonNull EngineLifecycleListener engineLifecycleListener) {
engineLifecycleListeners.add(engineLifecycleListener);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd avoid assumptions regarding what IDE is used (as you know some people just use text editors).
I'd think that in this case an assertion could potentially save some debugging time (if this ends throwing an NPE later you'll need to figure what set a null value here).

@matthew-carroll
Copy link
Contributor Author

@amirh just so you know, it looks like when you comment on specific commits, I lose the ability to reply. For example, I don't see an option to reply to your latest 3 comments above this.

@matthew-carroll
Copy link
Contributor Author

@chinmaygarde @jason-simmons @amirh @dnfield - I have a question on naming for you. I'm considering renaming FlutterEngine to FlutterApplication. I'm not sure if that's a great rename or not, but I thought it might make more sense, semantically. Do any of you have any opinions on that?

@jason-simmons
Copy link
Member

Currently we use FlutterApplcation as the name of an android.app.Application subclass that initializes Flutter on startup. I'd prefer to keep that and use FlutterEngine for the class that wraps the Engine object in the Flutter runtime.

@matthew-carroll
Copy link
Contributor Author

@jason-simmons Makes sense. I'll leave it as-is.

@tvolkert
Copy link
Contributor

Can you sync and resolve conflicts? I tend to be gun-shy of reviewing code that may be out-of-date 😄

@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

1 similar comment
@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

@matthew-carroll
Copy link
Contributor Author

matthew-carroll commented Dec 19, 2018

  • fix my bad author history on this PR

@matthew-carroll
Copy link
Contributor Author

@tvolkert I've merged in the latest from master so you should be good to go

@matthew-carroll
Copy link
Contributor Author

@sbaranov this is the PR I mentioned where I merged in your recent changes to the bundle paths. Please take a look when you get a chance to make sure that I didn't break your changes.

@matthew-carroll
Copy link
Contributor Author

@amirh can you take a 2nd pass on this PR? I believe I've addressed all the comments that seemed directly actionable.

@matthew-carroll
Copy link
Contributor Author

@jason-simmons would you mind taking a look through this PR, especially the native and JNI pieces? I think your LGTM will be important for the embedding refactor PRs.

@matthew-carroll
Copy link
Contributor Author

@cbracken can you take a pass through this PR for an LGTM?

@matthew-carroll
Copy link
Contributor Author

FYI - I'm going to do some force pushes as I attempt to correct my author history.

@cbracken
Copy link
Member

cbracken commented Dec 21, 2018

@cbracken you're talking about a newline after the final brace?

I'm talking about an end-of-file newline.

Is there a reason behind such a policy? Does that enable something I'm unaware of?

That's how lines in a file are defined in the POSIX standard:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

Lots of tools deal with this just fine, but best not to tempt fate.

As one example, C++ standards prior to C++11 require trailing newlines. From section 2.1/2:

If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character, the behavior is undefined.

@matthew-carroll matthew-carroll force-pushed the android_embedding_refactor_pr1_jni_extraction branch from dda02e2 to cb00a5e Compare December 21, 2018 01:21
@googlebot
Copy link

CLAs look good, thanks!

1 similar comment
@googlebot
Copy link

CLAs look good, thanks!

@matthew-carroll matthew-carroll merged commit 6b85ed3 into flutter:master Dec 21, 2018
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Dec 21, 2018
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Dec 21, 2018
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Dec 21, 2018
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Dec 21, 2018
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Dec 22, 2018
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Dec 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants