-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[firebase_admob] Fix firebase_admob issues caused by un-handled exception situations #1807
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here (e.g. What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
I signed CLA. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @archanpaul
Thanks for the contribution! I left you a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution!
Can you please update pubspec.yaml and CHANGELOG for release?
It looks like it should be possible to write a unit test for the added behavior (right now all the unit tests assert that dispose()
returns true). Could you please add that test here: https://github.com/flutter/plugins/blob/master/packages/firebase_admob/test/firebase_admob_test.dart
Thanks @collinjackson for your feedback. I think it is not easy to add a test case to simulate the exact scenario, which prompted me to added the patch. In the unit test we need to create a scenario in which, while Platform is working on For the benefit of plugin users, you may consider merging the current patch now and later add a comprehensive unit-test related to "
Do you want me to create 0.9.0+2 ? |
This is a unit test, not an integration test; you should be able to simulate the no_ad_for_id error in the You could either throw a PlatformException in the unit test or (my preference) update the native side so that
Yes. |
I have added unit test case in 24cdbe6 where I throw I prefer Platform to make Dart side of plugin aware that
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. This is looking good, I edited your changelog and I have one other nit
size: AdSize.banner, | ||
); | ||
final int id = banner.id; | ||
invalidAdId = banner.id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you're doing here is fragile and might cause the other disposeAd tests to fail depending on the order that the tests run, because they're re-using the same id testAdUnitId
.
You might want to reset invalidAdId
to null
in setUp()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@collinjackson thanks for pointing out. I have updated in f409fc4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm looking at this PR more carefully and I'm wondering what is the situation is causing dispose() to be called on a banner ad more than once. It seems to me that dispose()
should be a Future<void>
that can only be called once per ad, that calling dispose on an ad more than once should be prevented with a Dart assertion; in release builds where the assertion is disabled we could return early out of dispose()
rather than sending the request over the bridge where we know a platform exception will be generated. This would help developers catch bugs in their code where they are keeping around references to banner ads after disposal.
If you feel that being able to call dispose() on ads multiple times is an important use case I'd love to see an example of usage.
Thanks.
I do not have any use-case where BannerAd.dispose() is required to be called multiple times. The dispose() should return immediately in case of non-existent adID .. there is no need to wait for PlatformException to happen which is anyway inevitable in this case. Generally speaking, most of the app developers only care to know the bool return of dispose() and ensure that bannerAd = null after successful dispose. if you want to enforce the app developer to know that dispose is called on a non-existent adID, instead of assert (which actually does not give any meaningful reason in log), you can either throw a Dart exception informing the developer the reason explicitly or throw the PlatformException as it is (though not intuitive). I personally like to have hide() api call which should immediately hide the Ad instead of dispose(). As a Flutter app developer I will not like to await on dispose() to hide the Ad from UI. It is always preferable to have features like load() once (and sometimes await refresh() with corresponding event listner) the Ad and do show() & hide() as an when required to make Admob and this plugin intuitive/useful for the developer. This is my wish, not related to this PR. |
Migrated to firebase/flutterfire#37 |
Description
While using BannerAd from fairly complex application which expects BannerAd to be disposed gracefully there are multiple un-handled exception situations in the plugin which are addressed in following commits in https://github.com/archanpaul/flutter-plugins/commits/fix-firebase_admob
commit 7dfeeac (HEAD -> fix-firebase_admob, origin/fix-firebase_admob)
Author: Archan Paul [email protected]
Date: Sat Jul 6 18:36:29 2019 +0530
commit a2b1eac
Author: Archan Paul [email protected]
Date: Sat Jul 6 17:51:34 2019 +0530
Related code and log references