NullReferenceException in AdDuplex

We recently switched over to AdDuplex in our trial apps to get some extra promotion, as using the Microsoft PubCenter.

Last night, while waiting around, I started playing with one of them, and found that the app would crash, with the following call stack when connected to BTOpenZone, but not logged in.

System.NullReferenceException
Object reference not set to an instance of an object.
   at AdDuplex.AdControl.OnNetworkManagerAdLoaded(Object sender, AdLoadedEventArgs e)
   at AdDuplex.Models.NetworkManager.OnAdLoaded(TextAdInfo newAd)
   at AdDuplex.Models.NetworkManager.<>c__DisplayClass2.<LoadNewAdCallback>b__0()

I vaguely remembered seeing an update to the AdDuplexW8 nuget package midway through my updates that said that it fixed a null reference problem.

Obviously, this was it.

So, if you’re not using AdDuplex.WindowsPhone version 2.8.0.4 or later, you’ll need to rebuild your apps and resubmit, or else your app too will crash.

AdDuplex requires ID_CAP_PHONEDIALER

We’ve recently started using AdDuplex in our trial apps to get some extra promotion, as using the Microsoft PubCenter. 

We previously had the Microsoft Ad Control in the app, and it required a lot of capabilities that frankly I think scares off users.

So, I was very happy to learn that AdDuplex required only ID_CAP_NETWORKING

One of the apps we updated was a WP7 app, and as part of the submission Capabilities are automatically detected (this is no longer the case on WP8), and I was surprised that it flagged up ID_CAP_PHONEDIALER.  I suspected that I had done something wrong with remove of the old ad control.  ID_CAP_PHONEDIALER is added when you use the PhoneCallTask API

So I fired up JustDecomple from Telerik and did a search for that in my xap project.

Eventually, that led me to the AdDuplex.Models.NetworkManager class and it’s DisplayPhone method, which is called by AdDuplex.HandleAdClick

It turns out that if a phone number is supplied by the ad, that is the preferred mechanism for serving the ad!  I contacted AdDuplex about this, and I was told that the server currently will not serve these ads.

What DOES this mean for users of the control?

In the case that it does in the future, you will be pleased to know that your app will crash if you haven’t added the capability to your app if the user clicks on one of these links.  This also means that a man in the middle attack on AdDuplex’s servers could also cause your app to crash.

I contacted AdDuplex to ask about this and was told:

“We will consider removing the capability from the SDK. It’s only there for some future feature which is unlikely to materialize any time soon and we don’t actually want to serve ads like that. Thank you for bringing this to our attention.”

In the meantime, it’s still there in the latest November 14th update, 2.8.0.4

Slider and IsDirectionReversed–Why doesn’t my app work on WP8 (part 6 of N)

Just when you thought all the bugs must have been ironed out by now, you stumble across a new one.

I’ve recently been updating all of my apps to Visual Studio 2013 so support will be simpler in future, and as a result started porting to WP8 from our old WP7 codebase.

Of course, everything is supposed to just work.  Today we’ll focus on the IsDirectionReversedProperty, which as will see should really be called IsDirectionReversedProperly!

Try sticking this in your WP app:

<Slider Orientation="Horizontal" Maximum="10" IsDirectionReversed="True" />

Can you see where this is going?

Now add Minimum="5" and be amazed that this slipped through testing.

It’s broken on the 720p emulator.  It’s broken on my Lumia 920 with GDR3.  It’s not broken in a WP7 app though.

So, I wonder how Microsoft can fix this out in the wild, (though it only seems to work in any kind of reasonable way if Minimum is set to 0).  Someone may be depending on this behavior.

RateMyApp challenge on DVLUP code defects and gotchas

If you’re trying to run the RateMyApp challenge over at DVLUP (if you haven’t signed up, you should.  Click the link), you may be interested in a few problems I’ve stumbled across.

First, your app bar will still be active, even if the rating window is open. 

To fix that, you’ll need to wire up to the feedback controls VisibilityChanged event, and then in the handler, set

ApplicationBar.IsVisible = FeedbackOverlay.GetIsNotVisible(feedbackctrl);

Secondly, you’ll find that if you have any touch events, they may be handled as well.  This includes ListBox manipulation and scrolling, so you’ll need to turn that off in the handler too.

And finally, the bug.

If your app has multiple pages you’ll find that on the 5th and 10th run, your user will continue to be pestered every time you navigate back to the main page of your app.

To fix this, I suggest you do the following:

In FeedbackOverlay.xaml.cs add the following to the SetVisibility(bool visible) function inside the bottom of the else statement:

FeedbackHelper.Default.State = FeedbackState.Inactive;

If you don’t, the state will remain the same, even though the FeedbackOverlay was dismissed, so it will continue to be shown.

In addition, you must also change the yesButton_Click handler to SetVisibility(false) at the end of the function, rather than the beginning.

Wow, that’s a tall image–Why doesn’t my app work on WP8 (part 5 of N)

I’m getting ready to port our app Where's my Tent to WP8, and as a start, I thought I’d rebuild it with the latest libraries, and incorporate some changes from our other apps.

After hooking in the new code, I ran it on my WP8 device, and had a big surprise.

On WP7, it appears that photos returned from the CameraCaptureTask are always in Landscape mode, though you can figure out what orientation they really are in using a technique described by Tim Heuer.

Unfortunately for me, my app was coded to assume Landscape, so when an image is actually delivered in portrait mode, my assumptions break due to this breaking change.

If you’ve made the same assumption, you’ll have the same problem.

I suspect Tim’s code might not work either

Because now his code that rotates the image may now fail because it returns portait, and then he rotates the pixels.

Update 17 June 2013

It turns out that on WP8, the Exif data doesn’t exist at all in the stream returned by the Photo Chooser, so Tim’s code will crash, as it doesn’t check for an exception or null.

Storage Full on Windows Phone 7.8

I’ve been lucky enough to have received a fair few phones from Microsoft and Nokia for developing on the platform, and have passed them around my extended family.

I gave one of my Lumia 710 devices to my 86 year old father-in-law, who I’ve been slowly dragging into the modern age of computing over the past 25 years.  Don’t get me wrong: He worked at Ferranti working some of the earliest commercial computers, but things have changed a bit since the days of 1024x40 bits of core memory.

But you still run out of memory even today.  We found that something on the phone was using up all of the storage on the phone.  It got to the stage, where nothing was working, because no-one was able to update their isolated storage files. Worse, uninstalling apps one by one didn’t enlighten us.  There was still about 3gb unaccounted for.

In the end, we did a total reset of the phone, and then re-downloaded everything.  After that we had a reasonable amount of memory free, but I don’t have any confidence that we won’t be doing all of this again in the future.

It’s a shame that there isn’t more transparent access to the storage on being used on Windows Phone 7.x, so that users can find out which app is being a bad citizen and spoiling the Windows Phone party for everyone.

If a WP8 Lock Screen image changes…

and there’s no-one there to see it, did it really happen?

Our app, Terminator has been updated for Windows Phone 8, and now supports wide tiles, and can also be the lock screen provider.

However, we’ve noticed that if you don’t look at the lock screen every half an hour, occasionally, the image displayed is out of date, but if you download the images stored in isolated storage has been updated.

We believe this is caused by the A/B switching algorithm suggested on MSDN.

Let’s say it’s 9:00, and the first image runs, so we update image A
At 9:30, the run again, and generate image B.

This continues every half an hour, so when I go to bed at 23:00, when I get up and look at my screen at 6:00 I see the image generated at 23:00.

Looks like we need to find another algorithm, probably creating a new file based on clock ticks, and then deleting all of the old files, so we generate a new file each time.

Of course, we now have the problem that we may fill up the users phone with abandoned files if anything goes wrong, which is a subject I’ll discuss soon.

What an obscure bug - Why doesn’t my app work on wp8 (part 2 of n)

We’ve just submitted a new update for Skied Demon, our GPS logger for Windows Phone, and while testing by cycling, we noticed that the top speeds weren’t updating.

But we also noticed that this only happened on Windows Phone 8.  The exact same program running on WP7 works fine.

Originally, we thought there was some problem with our data notifications, and then we noticed that the updates failed only after running behind the lock screen.

It turns out, that on WP8, calls to Obscured and Unobscured events are not balanced as they were on WP7.  Why exactly my app would care that it’s been obscured even though it’s already had the message is a bit beyond me, but that’s the way the new API rolls, I guess.

We’ve now submitted an update to the store.

Why doesn’t my app work on wp8 (part 1 of n)

We recently switched over to a Lumia 920 for testing our apps, and have found that some of our apps just don’t work correctly.

For instance, our popular Skied Demon ski logging app exhibits problems on Windows 8 on a Lumia 920.

It turns out that the problem is caused by setting up BitmapCache as the CacheMode on some of the controls to improve performance.  The ironic thing is that this fails on Windows Phone 8 and not on Windows Phone 7.

This may also be caused by the increased screen resolution on this particular phone though I haven’t yet been able to verify that.  I suspect that what’s happening is that a bitmap is being constructed for the size of the zoomed area.  As that size grows, eventually the entire thing falls apart.

However, I would have expected WP8 to behave at least as well as WP7.

So, that’s one (of presumably many to follow pitfalls, as we know at least one more of our apps is currently not working, probably caused by a store issue)