Crashing out of app

Sep 5, 2012 at 10:10 PM
Edited Sep 5, 2012 at 10:24 PM

Okay, so... I'm not 100% sure I've got Adrotator implemented into my app right, but I'm seeking some guidance here.

First, I'm working on a hybrid SLXNA(Silverlight+XNA) WP7.5 app. Which is largely working great on the whole. The problem I'm running into is this: the app experiences some pretty nasty slowdown every so often (on a new ad loading in, it seems). Sometimes, this result in a mysterious app termination, though no exceptions are being thrown that I can see.

It *looks* like there's about a half-dozen threads closing when the slowdown happens, and my guess is in some cases the phone OS is detecting it going un-responsive and closing the app down entirely.

I was figuring that AdRotatorXNA might fix this, but unfortunately I can't use the XNA component due to it... well... being a component (and of course the underlying ad APIs are all XNA component-based as well).

So I guess the question is if there's anything I can do to make use of the Silverlight control without getting the slowdown/shutdown issue I'm seeing.

It this just a case of AdRotator being entirely unsuitable for hybrid apps?

EDIT: I neglected to mention that I'm compiling from the source associated with the 1.1 release.

Sep 6, 2012 at 9:52 AM

So long as you follow the instructions in the article you should have no issues

Note the codeplex links in the article which include the full source to the SIlverXNA sample projects as well as the XNA versions (Silverlight example already in this repository)

Sep 6, 2012 at 8:07 PM

Hmm. I'll spend some time today looking at it in more detail, running some profiling, and going through the SilverXNA sample. Hopefully I've just done something wrong integrating AdRotator in some small non-obvious way.

Sep 10, 2012 at 10:40 PM

Okay, I got this figured out.

It appears that certain providers' Silverlight controls (AdMob is the worst, MobFox does too, though it's less noticable) chug a little bit when AdRotator cycles to them. Additionally, it seems that whatever is going on with those provider controls get far, far worse when you set the SlidingAdDisplaySeconds and SlidingAdHiddenSeconds to values other than the defaults (mostly when you set them lower). It seems there's a minimum time for each provider control in order to keep them stable, otherwise something causes them to drive the app unresponsive long enough that the OS kills it. Sometimes it can take a while running for the app to die, though if you set the properties pretty low (like 5sec each), it'll happen pretty fast. Could be snowballing GCs or something in the network layer, it's hard to say.

Point is, it seems important to make sure the settings for display/hide time are high enough to give the rotator breathing room.

Sep 11, 2012 at 12:18 AM

Thanks for the assist Zizi

Sounds like we need to up the values for the sliding ad functionality and ensure it's not set below the default in order to prevent this occurrence.

What would you suggest as the sweet spot fro the timeout?

Sep 11, 2012 at 4:03 AM

No problem-- anything that helps a good piece of software get better.

As to the question, I think maybe it warrants me spending a little more time experimenting. It clear that the minimum seems to depend on which ad providers you're currently using, but I didn't fiddle around with my XML file to get a feel for them in detail. I'll spend a bit of my dev time tomorrow seeing if I can work out good values.

While on the topic, would it be possible to add the settings for the sliding ad timing into the descriptor XML? It occurs to me that time on-screen might be as important as the probabilities for maximizing revenues. It might be good to be able to change them as easily.

Sep 11, 2012 at 9:03 AM

Sounds like a fantastic idea, we'll add it to the plans for V2 where most of the XML changes are going.