Grow your business by advertising on MSN, Xbox, and more!
There have been many recent discussions on the XAML version of the MSA Ads SDK. The top questions that we are hearing from the developer community are around z-index and focus issues.
The problemLet’s start with the easy one. A bug exists today where the ad control won’t relinquish UI focus in Windows build 8400.
The solutionThe good news is that this is a platform issue that has been resolved in later builds.
The problemThe SDK content lags behind the rest of the app when I scroll/pan my app fast.
The solutionSee last parapgraph.
The problemThe more challenging issue is around z-index. As some of you may have discovered, the ad control is always on top. This is not an ominous feature to ensure our ads are always shown, but rather an issue with the WebView control that we use in the SDK. See excerpt from the Dev portal.
WebView has the characteristic that other UI regions such as controls cannot be rendered on top of the WebView. This is because of how window regions are handled internally, particularly how input events are processed and how the screen draws. If you want to render HTML content and also place other UI elements on top of that HTML content, you should use WebViewBrush as the render area.
The challenge is that the WebViewBrush does not capture events.
The solutionUnfortunately there is no eloquent solution, but there is a work around (please don’t flame me). Here goes….
When you are rendering your content over the ads SDK, set the visibility of the ad control to collapsed and when the content is removed, set it back to visible. That does not play well with layout managers like stack panels so what I have found to work in those cases is a dummy rectangle that is the same size than the ad control. This rectangle is default collapsed. When you need to hide the ad control, you show the placeholder and vice-versa.
<StackPanel HorizontalAlignment="Left" Height="730" Margin="10,28,0,0" VerticalAlignment="Top" Width="300">
<UI:AdControl x:Name="myAdcontrol" ApplicationId="test_client" AdUnitId="Image_300x250" HorizontalAlignment="Left" Height="250" VerticalAlignment="Top" Width="300"/>
<Rectangle x:Name="myDummy" HorizontalAlignment="Left" Height="250" Width="300" Visibility="Collapsed"/>
<Image x:Name="Content" HorizontalAlignment="Left" Height="250" Width="300" Source="Assets/SmallLogo.png"/>
And with code behind
if (myAdcontrol.Visibility == Windows.UI.Xaml.Visibility.Visible)
myAdcontrol.Visibility = Windows.UI.Xaml.Visibility.Collapsed;
myDummy.Visibility = Windows.UI.Xaml.Visibility.Visible;
myAdcontrol.Visibility = Windows.UI.Xaml.Visibility.Visible;
myDummy.Visibility = Windows.UI.Xaml.Visibility.Collapsed;
This seems to work in basic layouts and I know it will be more complicated in complex layouts. One of the options we are exploring is to handle this internally and expose a method on the ad control e.g. Suspend() and Resume() that attempts to retain the real estate by using a dummy container or by temporarily converting to a webviewbrush. We will unfortunately not get away from requiring the developer to signal when they want to render content over the ads and/or suspend animation because of the scrolling lag etc.
Follow us on Twitter @MSAdvertising | Find us on Facebook and YouTube | Share your thoughts in the Forums | Subscribe
I've currently got airspace problems with a *tooltip*. It would be stupid to hide the ad control just because a tooltip was shown. Why don't you use a webviewbrush all the time, and hook into XAML events? What events do you need beyond clicking on the ad??
I'm having an issues with the IsPerformanceScrollingEnabled not working when navigating back from a page with a Bing Maps Control. Any ideas ?