Skip to content

[firebase_dynamic_links] support v2 embedding #1372

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

Merged
merged 13 commits into from
Nov 21, 2019

Conversation

bparrishMines
Copy link
Contributor

@bparrishMines bparrishMines commented Nov 5, 2019

Description

Fixes flutter/flutter#41872

@bparrishMines bparrishMines requested a review from amirh as a code owner November 5, 2019 22:54
@bparrishMines bparrishMines changed the title [firebase_dynamic_links] support v1 embedding [firebase_dynamic_links] support v2 embedding Nov 5, 2019
android {
dependencies {
def lifecycle_version = "1.1.1"
compileOnly "android.arch.lifecycle:runtime:$lifecycle_version"
Copy link
Contributor

Choose a reason for hiding this comment

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

are there existing androidx transitive dependencies? (since there's an androidx annotation already) Is this a downgrade?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These use the latest instruction from the migration wiki: https://github.com/flutter/flutter/wiki/Experimental:-Create-Flutter-Plugin.

Quoting: flutter/plugins#2221 (comment)
We introduced a constraint that the app uses the plugin has to be migrated to androidx. This patch removes the constraint.

Copy link
Contributor

Choose a reason for hiding this comment

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

@mklim @blasten we had this conversation separately too. I guess we're saying mixing is ok and we're just letting plugins build as aars as fallbacks?

implements FlutterPlugin, ActivityAware, MethodCallHandler, NewIntentListener {
private Registrar registrar;
private MethodChannel channel;
private ActivityPluginBinding activityBinding;

private FirebaseDynamicLinksPlugin(Registrar registrar, MethodChannel channel) {
this.registrar = registrar;
this.channel = channel;
Copy link
Contributor

Choose a reason for hiding this comment

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

You don't have to pass this in right? The less potentially dangling nulls there are (depending on the path you take), the less likely there will be accidental null pointer exceptions

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 should need it. The FirebaseDynamicLinks plugins makes callbacks to dart: https://github.com/FirebaseExtended/flutterfire/pull/1372/files#diff-3f6c424218a2662c8ddc4b322f30bf66R81.

I could hold on to a BinaryMessenger and instantiate a MethodChannel every time we want to call invokeMethod, but I think this looks cleaner.

implements FlutterPlugin, ActivityAware, MethodCallHandler, NewIntentListener {
private Registrar registrar;
private MethodChannel channel;
private ActivityPluginBinding activityBinding;

private FirebaseDynamicLinksPlugin(Registrar registrar, MethodChannel channel) {
Copy link
Contributor

Choose a reason for hiding this comment

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

You added annotations right? Tag Registrar nonnull. Even better, since you only pull the activity out of the registrar, just change the instance variable to activity so future maintainers don't accidentally do registrar.messenger() and expand the encapsulation in the future and trip on a null half of the time.

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 removed the annotations in this PR because the ecosystem team decided that we won't include androidx in any plugin that doesn't require it. It's so that a Flutter app that doesn't include androidx can use this plugin.

However, this is a good point about someone accidently using the registrar. What about adding the @Deprecated annotation with an explanation about registrar remaining until we decide to only support v2 embedding flutter apps.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This does remind me that I also need to add documentation for the plugin now. Updated PR

Copy link

@mklim mklim Nov 13, 2019

Choose a reason for hiding this comment

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

Sorry, this tab was open and I missed the new comments. I agree with Maurice's summary about annotation, commented here.

For @Deprecated, I vaguely remember floating the idea by @amirh offline and he was against it. If I'm remembering right the reason being was that for now the static registrar registerWith method is fully supported, and we don't want to flag it as deprecated before we're actually really deprecating it. I think those uses will show up as compile time warnings too, so probably better not to bring them in.

Copy link
Contributor

Choose a reason for hiding this comment

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

We don't want to @Deprecate the actual Registrar API in the engine like @mklim said.
If you meant @Deprecate the instance variable, that sounds ok. I don't have a strong opinion. I was just making a general comment (regardless of what the class is) to minimize access. If your plugin instance wants an activity, just keep an activity and not its provider.

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 agree. I remember that we originally kept an instance of Registrar and not Activity because the method Registrar.getActivity() would sometimes return different activities in add-to-app scenarios.

Since we're now migrating to v2 embedding, I don't this this would be the case anymore. I updated the plugin to hold a reference to Activity.

private OnCompleteListener<ShortDynamicLink> createShortLinkListener(final Result result) {
return new OnCompleteListener<ShortDynamicLink>() {
@Override
public void onComplete(@NonNull Task<ShortDynamicLink> task) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Were these causing issues?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

answered in #1372 (comment)

import android.content.Intent;
import android.net.Uri;
import androidx.annotation.NonNull;
Copy link
Contributor

Choose a reason for hiding this comment

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

You went from androidx to android.arch in the gradle, which seems to cause this to not work. Though I'm not sure if it's intentional. Or did firebase already conceptually "upgrade" to androidx @mklim

Copy link
Contributor Author

Choose a reason for hiding this comment

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

answered in #1372 (comment)

Copy link

Choose a reason for hiding this comment

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

The latest thing we've talked about here is:

  1. android.arch for the magic lifecycle dependencies in the Gradle script. That way Jetifier can run on the artifacts in cases where it's needed, and it will resolve as-is for unmigrated apps.
  2. annotation should just be removed from both Gradle and source code files entirely. If it's present in source code Jetifier won't be able to run on it and it will cause compile failures for when there's AndroidX incompatibilities. I don't think that's worth just having the annotations.

If this is being stripped from the source code but it's still in the Gradle files as android.arch.annotation it should probably be removed from the Gradle files too. If it's not in the Gradle files at all this makes sense to me and shouldn't be causing known issues.

@xster
Copy link
Contributor

xster commented Nov 12, 2019

LGTM

@xster
Copy link
Contributor

xster commented Nov 21, 2019

LGTM

@bparrishMines bparrishMines merged commit 8bf9b22 into firebase:master Nov 21, 2019
@bparrishMines bparrishMines deleted the dynamic_embedding branch November 21, 2019 19:05
thatfiredev pushed a commit to thatfiredev/flutterfire that referenced this pull request Nov 26, 2019
* bump core version to 0.4.1+4 (firebase#1395)

* Remove deprecated firebase-core dependency (firebase#1417)

* Remove deprecated firebase-core dependency

* [firebase_auth] getIdToken use actual refresh value instead of checking if object exists (firebase#1334)

* getIdToken use actual refresh value instead of checking if object exists

* getIdToken refresh integration test

* update xcode to v11 (firebase#1420)

* Update FirebaseApp creation in tests (firebase#1406)

* [firebase_database] Support v2 android embedder. (firebase#287)

* [firebase_remote_config] Support v2 android embedder. (firebase#282)

* [CI] Add version to example apps (firebase#1426)

* Add hardcode version to example apps

* [firebase_core] Add platform interface (firebase#1324)

* Move firebase_core to firebase_core/firebase_core
* Add firebase_core_platform_interface package
* Update cirrus scripts and documentation

* [firebase_dynamic_links] Add support of expanding from short links (firebase#1381)

* Fixes strict compilation errors. (firebase#1331)

* Upgrade crashlytics to v2 plugin API (firebase#1370)

* Upgraded Crashlytics to v2 of Flutter Plugins.

* Format documentation lists (See also & Errors) correctly (firebase#298)

Fix documentation list format.

* [firebase_auth] Fix NoSuchMethodError exception in `reauthenticateWithCredential` (firebase#237)

* [firebase_auth] Fix NoSuchMethodError exception

Fix NoSuchMethodError exception when calling FirebaseUser.reauthenticateWithCredential

* add integration test

* Fix analyzer warnings

Co-Authored-By: Collin Jackson <[email protected]>

* [cloud_firestore] [firebase_performance] fix analyzer warnings (firebase#1453)

* fix analyzer warnings

* [CI] Skip flaky firebase_performance driver tests (firebase#1452)

* Skip flaky firebase_performance driver tests

* [firebase_auth] Added missing Exception to the reauthenticateWithCredential docs (firebase#1448) (firebase#1449)

* Added missing Exception to the reauthenticateWithCredential docs (firebase#1448)

* [firebase_remote_config] Bumps Android Firebase dependency to 19.0.3 (firebase#1443)

* Bump AGP, Gradle & Google Services Plugin

* Bumps dependency to Firebase Config 19.0.3

* Replaces a deprecated method usage with the updated version

* [firebase_messaging] Use UNUserNotificationCenter for ios 10+ (firebase#121)

* Use UNUserNotificationCenter for ios 10+

* Add swift documentation

* Move http test to README

* Update CONTRIBUTING.md (firebase#1473)

Removes obsolete recommendations about removing mockito (which is now used in testing federated plugins).

* [firebase_core] Migrate to platform_interface (firebase#1472)

* [firebase_messaging] Add an ArgumentError when passing invalid background message (firebase#252)

* [firebase_dynamic_links] support v2 embedding (firebase#1372)

* [cloud_firestore] Fix test that used FirebaseApp.channel (firebase#1476)

* [cloud_firestore] Fix test that used FirebaseApp.channel

* dartfmt

* bump version

* Fixed dynamic issue

* Fixed dynamic issue

* FIxed Object to list of object mapping

* Fixed text result expectation

* Reverted some changes

* Satisfying formatter

* Added android x to pass the test

* Fixed changed log auto formatting
@firebase firebase locked and limited conversation to collaborators Aug 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[firebase_dynamic_links] Support the v2 Android embedder plugins API
4 participants