Mobile Adverts plugin changes for r254

2 favourites
From the Asset Store
Customize the animation of character when item changed
  • For me that would the best solution. I like to let the user play a bit and gain some trust before showing the prompt. You only have one chance to get an "allow" from the user.

    I guess most developers would choose to show it on startup though.

  • fredriksthlm

    I test this on the simulator and on a device. So far they behave the same.

    I just realized that the IDFA explainer message is never shown. That is ok if you are in the EEA, but I just tried to spoof the location as outside the EEA and it still didn't show it.

    Right now I don't have too many ideas as to what might be wrong, i'll have to keep looking at it.

  • DiegoM

    I just realised, you cannot force to show the consent/IDFA automatically! You must keep the setting (like you had previously in the former Mobile Advert version) where you can chose to show it automatically on startup or to not show it automatically, and just show it with an event.

    Since in some circumstancus you are not allowed by Google by any means to show it (if the app exist in a featured program for users without ads for example), in those circumstances your app will be banned by Google if any ad-related things are shown at all, even the consent window. But for the other users I must show the consent/IDFA. (I can decide with IAP events when this comes into place)

    So this is a must have, like the plugin worked before. Just as boulerzzz also asked for.

    I had not realised this before.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Since in some circumstancus you are not allowed by Google by any means to show it (if the app exist in a featured program for users without ads for example)

    That makes sense. You would need to make a special build of your game for that case, wouldn't you? And it would be much easier to just change a single value rather than strip the whole plugin.

    The old plugin had the options to show the consent dialog for EU only, Always and Never. EU only is what it does now, which is the smart behavior where it figures out if it needs to show it or not. I don't think Always is needed anymore though, why would you want to force the consent dialog if you don't need to?

    So I think that just a toggle to choose whether to show it on start up or not is all that is needed.

  • > Since in some circumstancus you are not allowed by Google by any means to show it (if the app exist in a featured program for users without ads for example)

    That makes sense. You would need to make a special build of your game for that case, wouldn't you?

    The old plugin had the options to show the consent dialog for EU only, Always and Never. EU only is what it does now, which is the smart behavior where it figures out if it needs to show it or not. I don't think Always is needed anymore though, why would you want to force the consent dialog if you don't need to?

    So I think that just a toggle to choose whether to show it on start up or not is all that is needed.

    No, it is the same build unfortunately. That's why some apps can't have it on "Always show". But to have a toggle with Show / Not show , is fine. (where "Show" is only for EU)

    Then I can show it manually with the Show Consent event for the ones that should get it.

  • DiegoM

    I have now verfied the ConsentStatus bug.

    in r256 the consentstatus was not updated correctly "internally", but the actual consent was saved "externally".

    in r257 the consentstatus is updated correctly internally in the plugin. but you will get the UMP window every time you open it, with consentstatus UNKNOWN. So it seems it did not save the consent correctly(?)

    I can build the same project in 256 and 257 to verify the different behaviour. You should be able to reproduce it easily. It is the same for both Android and iOS. (If you already saved consent with a 256build, you might not get the issue in the 257 build, since it stored a cookie already. So uninstall and clean the device between every test)

  • fredriksthlm

    I test this on the simulator and on a device. So far they behave the same.

    I just realized that the IDFA explainer message is never shown. That is ok if you are in the EEA, but I just tried to spoof the location as outside the EEA and it still didn't show it.

    Right now I don't have too many ideas as to what might be wrong, i'll have to keep looking at it.

    Since we get the ATT prompt before the IDFA explainer is called, we will not get the IDFA explainer shown when that is called later since we already have Allow for ATT by then, and then you will not get the UMP window. I think you need to first correct the workflow in your plugin.

    (Also verify that the IDFA message is created and activated, this is not the same as the Consent message).

    Also the spoof location doesn't work at all. the "in EEA or unknown" is true regardless of spoof (if you are in eea but spoof to US). and also the consent validation doesn't listen to the spoof thinghy

  • Is it on purpose you haven't updated the Plugin Reference "Mobile Advert" since april?

  • DiegoM

    Thanks for the r258 bug fixes. For me all events concerning the statuses (and ads) are now working fine. So those bugs can ba classified as fixed. I've got iOS and Android apps uploaded to stores and got approved, with the latest plugin. I know also one other user who has verified this to me. So all good.

    Personally I still can't get the "spoof location" to work. I'm not sure how this DebugGeography should be implemented, I guess withing the RequestInfoUpdate call (?). But regardless if I set spoof location to "Outside the EU" in the plugin properties, the plugin still validates the condition "Is in EEA or unknown" to be true. Also the ConsentStatus is still REQUIRED. So the spoof location is not working properly in my tests at least. This is just a debug/test thing, so not needed for production apps. But if you decide to include it in your plugin I guess it should work :)

    Before going to Stable I would also advice you to update to the latest version, since there has been some improvements (at least for iOS concerning SKAdNetworks for example) within the latest updates.

  • Tjums

    Is it on purpose you haven't updated the Plugin Reference "Mobile Advert" since april?

    Yes.

    The manual will be updated once the feature reaches a stable release.

  • fredriksthlm

    Personally I still can't get the "spoof location" to work. I'm not sure how this DebugGeography should be implemented, I guess withing the RequestInfoUpdate call (?). But regardless if I set spoof location to "Outside the EU" in the plugin properties, the plugin still validates the condition "Is in EEA or unknown" to be true. Also the ConsentStatus is still REQUIRED. So the spoof location is not working properly in my tests at least. This is just a debug/test thing, so not needed for production apps. But if you decide to include it in your plugin I guess it should work :)

    Is this in Android or iOS? I have noticed a few things that don't work quite right in iOS. The first is that in iOS 14 or greater, DebugGeography will not work in a real device. I wrote a little bit about that on my update notes for r258 at the end of the first post in the topic.

    The other thing I noticed is that in iOS, if the device says is outside the EEA, the consent status will still be required if the ATT dialog hasn't been shown yet, and I think that is the User Messaging Platform SDK saying that, so I don't think that will be sorted any time soon.

  • Is this in Android or iOS? I have noticed a few things that don't work quite right in iOS. The first is that in iOS 14 or greater, DebugGeography will not work in a real device. I wrote a little bit about that on my update notes for r258 at the end of the first post in the topic.

    The other thing I noticed is that in iOS, if the device says is outside the EEA, the consent status will still be required if the ATT dialog hasn't been shown yet, and I think that is the User Messaging Platform SDK saying that, so I don't think that will be sorted any time soon.

    DiegoM

    It is regardless of platform. (I'm fully aware how ATT/IDFA/UMP works, which is not related to this).

    Just try this very simple example. This should state "NOT REQUIRED" and "NOT EEA", when spoof is "Outside EU". Which it doesn't do. It states "REQUIRED" and "EEA".

    I just built a signed apk for this project and loaded in my android phone...

  • DiegoM Since we now are in a new beta cycle.. maybe we can get a version bumb of this?

    (to the latest, from 1.17 to 1.23.1 as it looks now)

  • DiegoM

    Can you please verify if you have bumped the version of the plugin.

    Many of us have severe issues with our apps after update to ios15. Mostly regarding Admob.

    Google Admob SDK first got official support for ios15 in the v8.11 release

    developers.google.com/admob/ios/rel-notes

    This SDK was bumped in Ratsons Admob plugin in v 1.25

    github.com/admob-plus/admob-plus/blob/master/packages/cordova/CHANGELOG.md

    Last time I exported you were still on v1.17, can you please verify the above and bump the version asap. Since we experience severe issues at the moment with our previous builds

  • I just updated both plugins to the latest versions.

    admob-plus-cordova to version 1.25.0 and cordova-plugin-consent to version 2.2.0.

    The change will be available in the next beta release.

    I find it impossible to tell if that will help in any way thought.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)