problem with local DefaultHouseAd

May 31, 2012 at 10:32 AM

My goal: to show the local DefaultHouseAd (MyDefaultAd UserControl). I failed to do so in my App so I tried the same with the AdRotatorExample: first I changed the SettingsUrl property in AdRotatorControl in MainPage.xaml to an invalid url - so that the local defaultAdSettings.xml is taken. Then I edited the defaultAdSettings.xml: removed all cultures but default and gave the DefaultHouseAd a high probability to be shown on a regular base.

<AdCultureDescriptor CultureName="default">
      <Probabilities Probability="5" AdType="AdDuplex" AppID="2859"/>
      <Probabilities Probability="95" AdType="DefaultHouseAd" AppID=http://xna-uk.net/AdRotator/SampleRemoteHouseAd.xaml />
 </AdCultureDescriptor>

 As long as I keep the AppID for the DefaultHouseAd everything is fine: the xaml file is loaded from the url and the Ad is shown in the AdRotatorExample App. But if I remove this AppID property to get my local MyDefaultAd control there is a problem: the control is not presented! Is it me doing something wrong or is there a problem with the code?

Thanks for any advice!
Hans-Peter

Coordinator
May 31, 2012 at 10:40 AM

The "AppID" in the configuration XML is to specify a "Remote" House ad for use in your project, this enables you to remotely change your Ad without rebuilding your project.  The AppID is optional.

 

If you want to use XAML or a control locally in your project then you have to do so in code as shown in the example.

The logic follows like this:

If an AppID for a houseAd is specified it will try and download the XAML (only xaml no code) from the URL supplied, if it cannot it will try and load your local version (if configured) and if that fails it will disable the control (providing you don't have other active providers)

If an APPID is not supplied it will just try and use your local version if available.

 

If you only want to use House ads you don't have to provide other AdProviders if you don't want to, it's very flexible.

 

I'm still in the process of finding the time to write up the updated house ad implementation, will see if I can get that done soon.

 

Hope that helps.

May 31, 2012 at 10:59 AM

Thanks for the quick reply. As far as I can see, I have done it just as in your explanation. Take the AdRotatorExample and remove the AppID property from the DefaultHouseAd - the local control is not shown!

I debugged it and I can see that the MyDefaultAd is created in the NavigationTo method and later it is assigned to the Content Property of DefaultHouseAd Control - so that seems to be ok - but it is not presented.

Coordinator
May 31, 2012 at 11:15 AM

How does your local house ad compare to the one used in the example?

Try hooking up to the "Log" event from the control and output it to the Debug window to see if that helps you find the root cause of the issue

Hope this helps

May 31, 2012 at 11:53 AM

It is the AdRotatorExample which I downloaded. I only edited the settings file (removed the AppId).

Coordinator
May 31, 2012 at 12:02 PM

Ok, I'll check that out and get back to you.

Coordinator
May 31, 2012 at 5:15 PM

Ok, resolved that little issue.  However you'll have to use the source version to make use of it.  Just download the source and attach the AdRotator project to yours instead of just referencing the DLL.

 

The issue stems from how Silverlight does and does not like to use local User Controls, plus a huge oversight in my testing when checking it in.  I've patched that now but may re-think the approach as it is a bit messy.

Will probably convert the local method to emulate the remote method (just using XAML, not UserControl) which would be cleaner but that'll take more free time that I have at this moment to do properly.

 

Hope this helps.

Jun 1, 2012 at 10:01 AM

thanks a lot!

Jun 4, 2012 at 11:53 PM

I have the same issue, and I'll follow the instructions for the solution. 

I have a follow-up question, though.  The way this is implemented now, is the expectation that an app will have either a remote default ad or local one?  It would be nice to have both available because they serve different purposes in my understanding:

  • The remote default ad would be used when none of the ad networks returns an ad.
  • The local default ad would be used when there is no network connectivity at all.

Thanks,

Dave

Coordinator
Jun 6, 2012 at 10:09 PM

In answer to your query, it's designed to work with both or either, it's completely up to you.

The way it's designed its intended that you would have a local ad defined (just for the instance you describe where the first or possibly all launches don't have an internet connection and you still want an ad to be displayed) and also have a remote ad configured that would be downloaded at each launch to allow for updates. 

This provides more flexibility than most ad providers as you can guarantee an ad will be available of your design and lets you remotely update it without rebuilding and submitting your app.

Nov 29, 2012 at 4:12 AM
Edited Nov 29, 2012 at 4:14 AM

Was this issue resolved for 1.2?

I can't seem to get my local house ad to show. (the same code was working fine for 1.1)

Coordinator
Nov 29, 2012 at 11:43 AM

InquisitorJax

The fix is still just in source and was located in the 1.2 release, we've yet to release an updated 1.3 dll 

Coordinator
Dec 3, 2012 at 5:00 PM

Hi all

 

Managed to find some time to work on AdRotator V1 this week, have fully tested the fix for the above issue and will publish 1.3 soon.

Having "Just" a Default house Ad without an APPID has been fully tested and working.

Dec 18, 2012 at 5:48 AM
Edited Dec 18, 2012 at 5:53 AM

Darkside,

Loaded the latest 1.3 libraries - the default house ad loads great the first time round - but falls over with an exception when trying to load it for the second time.

ArgumentException: parameter is incorrect

StackTrace: 

   at MS.Internal.XcpImports.CheckHResult(UInt32 hr)   at MS.Internal.XcpImports.SetValue(IManagedPeerBase obj, DependencyProperty property, DependencyObject doh)   at System.Windows.DependencyObject.SetValue(DependencyProperty property, DependencyObject doh)   at System.Windows.Controls.UserControl.set_Content(UIElement value)   at AdRotator.DefaultHouseAd.LoadProjectDefaultAd()   at AdRotator.DefaultHouseAd.GetDefaultHouseAd(Object LocalHouseAdBody, String URL)   at AdRotator.AdRotatorControl.CreateDefaultHouseAdControl()   at AdRotator.AdRotatorControl.Invalidate(Boolean selectNextAdType)   at AdRotator.AdRotatorControl.<SlideOutAdStoryboard_Completed>b__1b()   at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)   at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, StackCrawlMark& stackMark)   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)   at System.Delegate.DynamicInvokeOne(Object[] args)   at System.MulticastDelegate.DynamicInvokeImpl(Object[] args)   at System.Delegate.DynamicInvoke(Object[] args)   at System.Windows.Threading.DispatcherOperation.Invoke()   at System.Windows.Threading.Dispatcher.Dispatch(DispatcherPriority priority)   at System.Windows.Threading.Dispatcher.OnInvoke(Object context)   at System.Windows.Hosting.CallbackCookie.Invoke(Object[] args)   at System.Windows.Hosting.DelegateWrapper.InternalInvoke(Object[] args)   at System.Windows.RuntimeHost.ManagedHost.InvokeDelegate(IntPtr pHandle, Int32 nParamCount, ScriptParam[] pParams, ScriptParam& pResult)

 

Have you tested the default house ad where no remote url is specified - only a local house ad?
It looks like it's attempting to load a remote one - but there is no url specified in the config. 

PS: The adDuplex & MS Advertising binaries are missing from the 1..3 download package.

Coordinator
Dec 18, 2012 at 2:59 PM

I'll investigate the issue.

In answer to your questions, yes we fully tested using Just a local house ad and just a remote ad plus a combination of the two in connected and disconnected modes without issue.

As for the Dll's, AdDuplex is now sourced from NuGet ad they have changed their delivery mechanism and on Win 8 the only route is NuGet so we stopped shipping it to avoid confusion with versions, pretty much the same with the PubCenter Dll's as the official MS version has changed delivery.

If you prefer you can also use the NuGet versions of AdRotator now as the WP supports both WP7 and WP8 in one package (but we are also going to ship separate versions based on some feedback), and for Win 8 Nuget is the only way to get it because of how Win 8 operates.

 

Do you have an example of the House Ad control you are using that is causing the issue?

Dec 18, 2012 at 6:31 PM

It's a simple UserControl - nothing special.

Don't know if it makes a difference - but the rotator control is created and added to a grid at runtime from code.

Weird that the houseAd loads fine the first time - but as soon as it tries to load a second time it falls over :|

Coordinator
Dec 18, 2012 at 10:59 PM

Right, that configuration hasn't been tested with AdRotator as it's not one we support.

I suspect there are some elements of AdRotator left in memory when you try to add the control a second time to the page.  Possibly consider making the AdRotator control static and storing an instance of it in your App.XAML and ensure you are not initializing it twice.

Alternatively, place AdRotator in a User control and add that to the page in code, that should clear up any possible issue (maybe)

Dec 19, 2012 at 4:47 AM
Edited Dec 19, 2012 at 5:09 AM
Nope - ad rotator only gets added once.
I literally open the app and do nothing - I then wait for the house ad to show a second time - and boom it crashes.
Sample code here:
https://skydrive.live.com/embed?cid=5FADC16984914668&resid=5FADC16984914668%21555&authkey=AGroJptwGaUJvMg
PS: The control is loaded from code for performance reasons / and only when necessary (if the app is trial for ex)
Coordinator
Dec 19, 2012 at 1:37 PM

Right, I've found the answer to your issue.

It seems XAML is taking offense to a local control being used more than once, or when a controls parent container (in this case AdRotator) is destroyed, it won't allow a previous child control to be added to another control.

Various investigations in to why this is only happening now as it's worked fine in the past.

So I've changed the implementation which in the end I feel is a much better solution anyway.  instead of passing an instance of your Local House ad, you will only need to mention the namespace/control name and AdRotator with initialise it for you, this means we'll avoid any possible issue relating to this in the future.

Should have the updated control (which i'll package as 3b as it will just be this  fix) out soon

Dec 19, 2012 at 2:52 PM

Excellent! pls post reply on this thread once posted :)

Coordinator
Dec 19, 2012 at 3:30 PM

Posted the updated Windows 8 and Windows Phone packages to NuGet.

Before you apply the package remove any Ad Provider references you had before including AdRotator

Then Just apply the latest package and:

  • Change the DefaltHouseAd setting to be a string of "<ProjectNamespace>.<HouseAdType>" (in you examples I used "PhoneApp2.WindowsPhoneControl1")
  • Check the "defaultAdSettings.xml" file build action is set to content (for some reason the build actions are different)

Hope this helps

Dec 21, 2012 at 5:08 AM

Thanks Darkside.

The build action is "Resource" because the default of content wasn't working. (not sure if 1.3 fixed the issue - I'll check)

Also - this post:
http://darkgenesis.zenithmoon.com/adrotator-for-windows-phone-silverlight/
confirms the build action must be resource. 

Dec 21, 2012 at 5:35 AM
Edited Dec 21, 2012 at 5:44 AM

downloaded 1.3 for silverlight - still seems like the same behaviour = defaultHouseAdBody is still of type object.

EDIT: uninstalled and re-installed via NuGet (didn't pick up that there was an update) - works like a charm - thanks!

Coordinator
Dec 21, 2012 at 8:52 AM

Gah, beat me to it :D

 

Glad your now working, not had time yet to update the install package here yet.

Dec 24, 2012 at 5:41 AM

One final tweak request - would be nice if you could specify a namespace in a different assembly - I need this because the housead control I use is generic across my phone projects. If you're using reflection to instantiate the control - here's a blog post that might help with that:

http://inquisitorjax.blogspot.com/2009/10/gettype-from-referenced-assembly-in.html

Coordinator
Dec 24, 2012 at 11:38 PM

The new version is using reflection, so as long as the dll ships with the solution, you can use what ever reference you like :D

Let me know if you have issues

Dec 25, 2012 at 5:15 AM

The control won't load if it's in another assembly - hence why I linked special code needed to be able to do so.

Coordinator
Dec 27, 2012 at 3:37 PM

Right, managed to implement your suggestion and tested in the AdRotator project using a separate class library.

It wasn't quite as straight forward as the article suggests as Windows Phone and Windows 8 don't support some of the features mentioned, in the end I've managed to use the example plus the code I use in Windows 8 to make it work.

Will update the project soon

Jan 1, 2013 at 7:20 PM

Loaded the latest library from nuget. Now getting MethodAccessException using the posted example.

Coordinator
Jan 9, 2013 at 11:22 PM

Can you replicate the issue with your type of sample house ad and drop it on Dropbox so we can investigate further?

Feb 1, 2013 at 5:56 PM
Edited Feb 1, 2013 at 5:57 PM
InquisitorJax wrote:
Loaded the latest library from nuget. Now getting MethodAccessException using the posted example.
Same here...

Darkside, do you have any example using the string methods? I could not find them anywhere!

BTW Thx for the awesome library!

EDIT: Mine just get the AccessException on device, on Emulator is running fine!
Coordinator
Feb 1, 2013 at 7:45 PM
AccessException on device most likely means you have not enabled the Location Capability for your App.

Make sure you test your app with the Store / Marketplace test kit in visual studio first.

Apologies for not updating all the samples to use the updated house ad configuration, will get on that as soon as I can.
Feb 1, 2013 at 8:29 PM
In fact the ID_CAP_LOCATION is set.

I have tested and I have shipped the app before, but without the DefaultHouseAd (http://bit.ly/seriesNotifier).

In my tests I could make the House ad work through the Internet.... This will be my workaround for now...
Feb 12, 2013 at 4:34 AM
I get MethodAccessException even if the housead is on the same lib.
Maybe I'm doing something wrong?
Here's a sample project:
https://skydrive.live.com/redir?resid=5FADC16984914668!576&authkey=!ADNiddOVvX9EbUY
Coordinator
Feb 13, 2013 at 12:29 PM
Thanks for the example project. Been examining it over the last few days and the root of the problem seems to be with Just WP7 / 7.5 and does not occur in WP8 and Win8 (typical)

The original reflection code we used on WP7 worked just fine but since we updated it to also support WP8 it seems to have backwardly broken the WP7 version (probably a test fail)

Will look to see if we can holistically support it by bringing back the old reflection method for WP7 or failing that go back to using the object instantiated way of providing house Ads.

Very frustrating.
Feb 13, 2013 at 12:52 PM
Thanks.

You may consider having different libs for WP7 / 8 - reuse the same code with compiler directives.
That way if there is capabilities specific to WP8 - you can extend the WP8 lib to take advantage of that.
I think there are also advertising providers that provide platform specific libs as well - which the different projects would reference.

... just a thought.

Thanks for the control - muchly appreciated!
Coordinator
Feb 13, 2013 at 1:23 PM
Thanks, it's something we are usually very keen to avoid but in this case we may have to resort to that, thanks for the input.

Just managed to complete successful tests still using reflection in 7.5, so I can still get it to work with the new method in WP7.
Just need to tweak it to be more performant :D

So light at the end of the tunnel, should hope to get an updated version out soon (after a full test cycle :D)
And then to update all the sample apps, a thankless and long task, but hay ho.

More news soon
Feb 13, 2013 at 2:22 PM
Must thanks the Inquisitor! I did not have the time to make a sample project to verify the problem :/ Thank you man!

Darkside! I will be glad to test the changes, indeed this is a very useful control, you did a great job, have you ever considered to port it to android ? It would be nice to have a great tool like that in many platforms!

BTW I realize another thing, if you leave the options to fall into the last Ad, and that is the AdDuplex the app sometimes freezes for a small amount of time. Have just added the Nax and my slowdowns have gone down considerably.

Thank you all!
Coordinator
Feb 13, 2013 at 3:46 PM
There was a known issue potentially with the AdDuplex control for which a point release has just been made available by AdDuplex.
This shouldn't cause an issue for AdRotator, as always we only host other providers deliverables or support a specific version of their web api, we don't officially support those providers directly (unless they grab us by email :D)

Just finishing wrapping up changes now and will release an alpha build here for you guys and gals to test before we update the NuGet packages

Thanks for your support and consideration :D
Coordinator
Feb 13, 2013 at 4:50 PM
Latest Alpha builds available on http://wp7adrotator.codeplex.com/releases