iOS SDK b7 - ad does not get destroyed, causes endless problems

[igz]

Hi there,

We have recently gone ahead and upgraded our IMA SDK to v3b7 due to b6's poor performance under iOS 8 (too much lag between load/play events.)

However, b7 has presented us with a slew of new problems. The biggest deal-breaker at the moment is that the ad does not seem to get destroyed when it should be; this seems to be exacerbated by attempting to destroy it in the background.

Consider the following real-world scenario:

- ad is loaded in background, starts playing in background (it is an audio ad)

- ad finishes or is skipped using remote control; we call destroy on our IMAAdsManager instance

- now our app begins playback of our audio content

- in foreground or background, if we now toggle playback using a remote control, it will toggle not only our audio, but ALSO the ad that was supposed to have been destroyed

So now we have a situation where either the ad will play over our app's audio (or, if we pause app audio using our app's pause/play button, they will toggle out of phase and either one will play or the other.)

Worse: let's say that ad A was loaded as in the scenario above, and ad B is loaded, plays and finishes in the foreground, next time we use the remote control pause/play toggle, it'll unpause ad A (and sometimes we'll get a 200-300 ms snippet of audio from ad B, as if it had never been cleared from a buffer.)

To add a perverse cherry to the top of this mess, the ad playback now competes for our app's now playing info in the MPNowPlayingInfoCenter. Under b6, we managed this information to show the user what's playing (with artwork, to boot.) Now the MPNowPlayingInfoCenter shows the URL of the ad that's currently playing.

It certainly seems that the SDK moved from an AVPlayer-based solution to a UIWebView-based solution, which is causing all of these issues. None of these issues were present in b6. The only reason we moved to b7 was due to the awful performance under iOS 8 (events during payload and playback that usually took 0.5-2 seconds now take 5-10).

Please advise.

[Shawn Busolits (IMA SDK Team)]

Hi there,

Could you clarify what you mean when you say you're using a remote control to finish or skip an ad? What action are you taking with respect to the SDK when the user skips the ad or when the ad is finished? If you could send us a sample app or, even better, some sample code that demonstrates the problem, it would greatly help in getting this resolved.

As far as your MPNowPlayingInfoCenter issue goes, I will need to look into that further on my end to see what we can do to resolve that issue.

Thanks,

Shawn Busolits

IMA SDK Team

[Ignacy Zulawski]

Hi Shawn,

By 'using a remote control', I mean that messages get routed through [MPRemoteCommandCenter sharedCommandCenter]. So, this applies to headphone single-/double-/triple-taps, iOS 7 control center pause/play skip, etc. These commands are routed to our app's player code, which either controls mp3 playback (app audio), or routes to our ad controller, which calls the IMAAdsManager instance's pause or resume. When "skipping" a video ad, we call unloadAdsManager, which matches the IMASampleViewController.m code (ie: call adsManager destroy, set it to nil, set the display container to nil.)

The caveat is that our ads are set to not be skippable; this is so we can control the look and feel of our skip button. With b6, calling our destroy routine cleared out the ad fine; now, with b7, it seems to hang around. Letting the ad finish playing naturally (which also calls the destroy routine) works a little better in that the ad doesn't start playing from the beginning again, but snippets of the ad can be heard when playing/pausing app audio using a headphone remote. The MPNowPlayingInfoCenter issue remains even when the ad is allowed to finish naturally - ie: our now playing info (of the actual app audio) will appear correctly, but then get cleared out seemingly randomly, long after an ad has finished playing.

Unfortunately, I don't have a sample app or sample code to share at the moment. I will try to cobble something together for you.

thanks

i

--
You received this message because you are subscribed to the Google Groups "Interactive Media Ads SDK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ima-sdk+u...@googlegroups.com.
To post to this group, send email to ima...@googlegroups.com.
Visit this group at http://groups.google.com/group/ima-sdk.
For more options, visit https://groups.google.com/d/optout.

[igz]

Hi Shawn,

A followup. Upon further experimentation, when in this "headless" state, the IMAAdsManager has been destroyed, but the media is kept alive (somehow - I'm guessing a strong reference to a webview?) This means that the media is now acting independently of the IMA SDK - no ad events are fired, nor are callbacks called, which makes sense since the IMAAdsManager instance was destroyed. If this is the case, then it seems like the issue is ensuring that the underlying media actually gets destroyed along with the IMAAdDisplayContainer instance.

As an experiment, I've tried explicitly removing all appropriate subviews from their superviews in our tear-down routine, including the webview that I'm guessing contains the ad media player. No dice - I can still trigger the media using MPRemoteCommandCenter commands.

Hope this helps. I'll keep you posted if I find anything else.

i

[Ignacy Zulawski]

Hi Shawn,

I may have found a [hacky] solution to this issue: before destroying the IMAAdsManager instance, recurse through all subviews of the video view, and tell any UIWebView to clear out its contents. eg:

- (void)forceCleanup:(UIView *)view {

    [view.subviews enumerateObjectsUsingBlock:^(UIView *subview, NSUInteger idx, BOOL *stop) {

        if([subview isKindOfClass:[UIWebView class]]) {

            @try {

                [(UIWebView *)subview loadHTMLString:@"<script>document.writeln('')</script>" baseURL:nil];

            }

            @catch (NSException *e) {

//

            }

        }

        [self forceCleanup:subview];

    }];

}

I'm not proud of it, but certainly seems to work.

i

[Shawn Busolits (IMA SDK Team)]

Hi,

Thanks for the additional info. That should be enough for us to look at this internally and find a way to resolve the issue. In the mean time if you are able to send me a sample app please do so so we can test potential solutions.

Thanks,

Shawn Busolits

IMA SDK Team

To unsubscribe from this group and stop receiving emails from it, send an email to ima-sdk+unsubscribe@googlegroups.com.

[Pedro Cid]

Hi! Thanks for this solution but is not working for me. Any news about this issue?

[Shawn Busolits (IMA SDK Team)]

Hi Pedro,

We're still looking into this one. At this point we think it may be a bug in iOS 8. We're doing everything we can on our end to clean up the video player, but when the remote controls are used it still trying to play our (now non-existent) video player. As soon as I have any more info I'll let you know.

Thanks,

Shawn Busolits

IMA SDK Team

[Shawn Busolits (IMA SDK Team)]

Hi all,

This issue should be fixed in beta 12 of the iOS SDK. If you're still seeing the issue after updating let us know.

Thanks,

Shawn Busolits

IMA SDK Team