Learn what Felgo offers to help your business succeed. Start your free evaluation today! Felgo for Your Business


OverviewFelgo Plugins Support › AdMob rewarded video error when using 2 videos

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #17053


    Hi Felgo,
    Yeah, it looks like like I found another one ūüôā
    It’s Rewarded video with AdMob.

    When you use more than one rewarded video elements, and loading video on second RewardedVideo, then listener is triggered on first video.
    I think this behavior is incorrect.

    As always, simple example.
    Please check if this behaves in wrong way for you as well.

    Expected behavior: when you click the button listener on secondVideo.onRewardedVideoReceived should be trigger but listener on firstVideo is triggered instead.
    Didn’t test other listener but this issue is maybe not specific to this one only.
    Of course you need to provide license and two valid AdMob unit ids, but different.

    import Felgo 3.0
    import QtQuick 2.0
    import Felgo 3.0
    import "pages"
    import "helper"
    GameWindow {
        id: gameWindow
        activeScene: scene
        screenWidth: 640
        screenHeight: 960
        licenseKey: "<your-license-key>"
        Scene {
            id: scene
            width: 320
            height: 480
            Rectangle {
                id: rectangle
                anchors.fill: parent
                color: "grey"
            SimpleButton {
                anchors.centerIn: parent
                width: 150
                height: 150
                text: 'Click me'
                onClicked: {
            AdMobRewardedVideo {
                id: firstVideo
                adUnitId: '<your-unit-id-1>''
                onRewardedVideoFailedToReceive: {
                    console.log('========= Failed to receive the video at FIRST VIDEO')
                onRewardedVideoReceived: {
                    console.log('========= Received the video at FIRST VIDEO')
            AdMobRewardedVideo {
                id: secondVideo
                adUnitId: '<your-unit-id-2>'
                onRewardedVideoFailedToReceive: {
                    console.log('========= Failed to receive the video at SECOND VIDEO')
                onRewardedVideoReceived: {
                    console.log('========= Received the video at SECOND VIDEO')




    Felgo Team

    Hi Marcin,

    you are right, there’s probably something going wrong with registering / triggering the signals.

    Thanks for reporting the issue!




    Hi G√ľnther,
    No problem.
    In the end the bug really affects my project so of course it is important for me to report this ūüėČ


    Felgo Team


    One side question: As the rewarded video acts as an overlay to the whole app anyways, is it required for you to use two AdMobRewardedVideo items in parallel?

    Is using one item to show the video on demand also an option or is there a reason this is not possible for your project?



    Hi G√ľnther

    Short answer: I need two RewardedVideo, or maybe more in the future, because I need to analyze/tweak things separately.
    Either locally by using for example Google Analytics or remotely using AdMob console and their stats.
    If needed, need to be able even to disable one of them from the AdMob console, not from code.

    My use case:
    – two different locations for rewarded video
    – possible more if needed
    – need ability to separately track them, usage both locally in the app with analytics which I call and separately in AdMob console
    – need to know upfront which rewarded videos are available, before I call load, because I also have Chartboost and some logic which chooses based on availability what to show
    – I sometimes cache videos on the same location multiple times(after displayed) and at some point, if I don’t get it from one source(Chartboostor Admob), can show the second
    – this logic was working fine when I was using temporary normal video from AdMob, now it is a problem for me



    To clarify one thing, this one fix is not that crucial.
    The most important for me was the ability to have second rewarded video provider to implement the functionality and test it.
    This one thing is essential for me to go live but it won’t happen that soon.
    So can wait a month or two.


    Felgo Team

    Hi Marcin!

    We’ve had a look at the problem, here’s what we found:

    • For interstitial, having 2 instances of the QML item works fine, you get the callbacks only on the correct item.
    • For rewarded video, this is not possible, because (on both Android and iOS) the native rewarded video object (from the AdMob SDK) is a singleton
      This means only one rewarded video can be loaded at a time. There isn’t much we can do about it except forward the request to Admob itself.

    So unfortunately, you can only use one AdmobRewardedVideo, or unload the component with a Loader to create a new one for a different adUnit.




    Hi G√ľnther,

    F***ing anti-pattern singletons and global state ūüôā
    Ok, get it.
    If that is really the case then it’s a pity.
    Maybe I will forward request to AdMob on my own, or will look at their docs how they suggest to handle things.

    That wouldn’t be an issue so much if not the fact that one reward video is on revive screen and the second right after at game over screen(if you skip the revive).
    I am afraid of race conditions if I call them right after each other.
    I am pretty sure I can come up with some solution to handle the states to be able to tell which video was just cached, or for which video caching failed.
    Just I always wanted to know upfront if the video is available or not, and not to force user to wait while the video is downloading.

    Is there a way I am able to tell if video is available before I call load, if not based on “cached successfully” listener?
    I know in Chartboost there is hasRewardedVideo or similar, which is super helpful.
    I am afraid it is not possible in AdMobRewardedVideo unfortunately.
    There is no hasRewardedVideo equivalent of Chartboost.
    Am I right?

    Maybe it would be good to update the AdMobRewardedVideo Qml item documentation to make this limitation clear.



    One more question then.

    I didn’t validate it yet but it means all listeners will be triggered this way because of singleton, right?
    For example video reward given/completed or closed.


    Felgo Team

    Hi Marcin!

    Yes, we already added a note about the limitation of having only one AdMobRewardedVideo to our docs (will be online with the next doc update we push to our webserver). As the AdMob item is a singleton, only one video can be correctly configured and all events like reward given/completed/closed are fired globally and only exist once.

    AdMob does not offer a hasRewardedVideo like Chartboost, but you can have a look at the OneCard demo, where we created something similar based on the available signals. A possible solution could look something like this:

      AdMobRewardedVideo {
        id: adMobVideo
        // keep state of cached video
        property bool hasVideo: false
        property bool displayWhenLoaded: false
        // handle received
        onRewardedVideoReceived: {
          adMobVideo.hasVideo = true
        // handle failed
        onRewardedVideoFailedToReceive: {
          adMobVideo.hasVideo = false
        // load video at app start to cache it
        Component.onCompleted: {
        onRewardedVideoClosed: {
          // request new interstitial
          adMobVideo.hasVideo = false

    This solution loads and caches a video at app start, and also loads a new one immediately after a loaded video was shown/closed. Based on the signals, the hasVideo property is updated accordingly to allow checking if a video is available.


    Hope this helps!




    Thank you for the clarification and code example.
    It looks like will try to update my own solution, won’t¬† be a big issue.

    The truth is the code example you gave me, I already do it and probably do it for months ūüôā
    I also abstracted it much more with common interface regardless if I use Chartboost, AdMob or anything else, if I want.
    I just use a proxies which work as adapters for lower Chartboost or AdMob implementation.
    On higher, more abstract level I just use one common interface which is not aware of the adapter which I use internally.
    Also have some bindings like in my AdvertHandler.qml:
    reviveScreenVideoAvailable: chartboostReviveAvailable || adMobReviveAvailable
    leaderboardsScreenVideoAvailable: chartboosLeaderboardsAvailable || adMobLeaderboardsAvailable
    and similar I use it later in code in a way:
    advertHandler->initLeaderboardsScreen()//this is where the caching happens and assigning availability based on that
    advertHandler->initReviveScreen()//this is where the caching happens and assigning availability based on that
    and later
    if (advertHandler.reviveScreenVideoAvailable) etc.
    Anyway, won’t put more off topic stuff here.

    Again, thank you for all the help, will find a way to adapt to new circumstances.

Viewing 11 posts - 1 through 11 (of 11 total)

RSS feed for this thread

You must be logged in to reply to this topic.

Qt_Technology_Partner_RGB_475 Qt_Service_Partner_RGB_475_padded