Subscribe to the RSS feed then follow me on twitter at @mrlacey

Thursday, July 30, 2015

Unexpected Windows Phone errors

I've been updating an app that targets WP8.0.
With a couple of hours spare I've been looking through the dev center health reports to see if there are any exceptions occurring that I can do anything about.
It seems that I'm not be defensive enough in my coding and previously didn't allow for things that should never happen from happening. :S

Yes, really.

Even if it's not displayed an app should always have one tile, the "primary tile" that can be accessed in code so it can be updated.
Like this:

var primaryTile = ShellTile.ActiveTiles.First();

Except when it can't.

According to the stack traces, the above has failed.
The lesson? Always use `FirstOrDefault()` even when there should always be at least one and you want the first.


A page has a State dictionary that can be used for storing details while the app is deactivated/tombstoned.

You should always be able to access it and it should always exist:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
 
    if (this.State.Count > 0) 
    {

But then, apparently (according to the exception details) there may be an exception when accessing the `State` property.



For an app with over a million installs the number of times the above have happened is incredibly small but may be worth noting if you want to be super robust in your code. Of course, if you not busy with Windows 10 related things ;)



If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Wednesday, July 15, 2015

My CTR has gone down - but I'm not concerned

Here's my CTR for the two weeks before and after I switched to real-time bidding for one of my AdDuplex campaigns.



I've dropped from an average of 1.8% to 1.2%. That's down by a third!


Is this a bad thing?

If CTR was what i was most interested in then I'd be concerned.
Many people would be very worried about this change.

However, here's the important thing.
Over the time period I spent the same budget every day and the clicks did this:


For the same budget, the number of clicks went from an average of 184 to 290. That's an increase of 57%. This is a very good thing.

On its own, CTR is a potentially misleading statistic as it doesn't show the whole picture. Without knowledge of the number of impressions CTR is meaningless. A high CTR from a low number of impressions could be a lot less than a low CTR from a very high number of impressions.

My ultimate aim from buying the advertising is to increase the number of downloads I get. Clicks are a proxy for this figure as the store won't yet tell me where referrals come from. Without the store listing changing over this entire period I can assume that the conversion of people clicking on the ad to eventually installing the app has remained constant.

CTR is indicative of a means to an end. Don't be deceived into thinking this is what ultimately matters. It's the return on investment that's should be monitored and in this case that means clicks.



If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Tuesday, June 30, 2015

AdDuplex has introduced real-time bidding - what this means for you

Last week, AdDuplex have announced the introduction of a bidding based sub-system. If you're an AdDuplex user then you may have some questions about this and what it means for you.

Here, in hopefully simple terms, is what it means to you and what has changed.

Cross-Promotion
If you're cross promoting your app with the AdDuplex control then nothing has changed. This is true whether you've got a Windows or Windows Phone app and if you're using the control directly or through AdRotator or AdMediator.
If you show ads for other apps and in exchange ads for your app are shown in the other apps then nothing changes.

Direct Campaigns
If you've bought direct advertising in an app nothing changes. Any campaigns you're bought will continue in the same way. You can also continue to buy advertising in the same way.

Network Campaigns
This is where things have changed.
Previously, all ad impressions that you purchased cost the same amount.
This made things were nice and simple and you knew what you'd get for your money.

In reality though, some ad inventory is more desirable than others. This could be ads in some types of apps and people in some locations.
When something is more desirable it is reasonable that some people will be prepared to pay more for it. Similarly it's reasonable to want to pay less for something that other people aren't as interested in.

The way that advertising platforms account for the varying relative value of different impressions is via real-time bidding or RTB. (RTB article on Wikipedia)
This is what AdDUplex has changed to using for paid network advertising.

What this means for you is that:
  • Some ad impressions will cost more.
  • Some ad impressions will cost less
  • You can expect to get more impressions for your money
  • If you want specific targeting for your ads you may end up getting fewer impressions for your money but they should be more valuable to you and therefore something which will convert better. (If you're targeting correctly.)


Practically, what does this mean for you?
If you are currently running paid network campaigns you can switch them to be RTB based.
If you do this before July 7th 2015 you'll get your current balance doubled!
If you don't do this manually, all accounts will be automatically updated on January 1st 2016.

As per the instructions on the blog post, to make the switch, log in to your account and go to "Buy ads –> Billing –> Add credits" then follow the instructions to convert your credit.
The day after you do this you'll be able to adjust your campaign(s). Just go to the bottom of each campaign and adjust as appropriate.


I'd suggest keeping the old daily budget and starting with a low bid (e.g. $0.99) and then adjusting based on performance once you see what you get with those settings.






If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Tuesday, June 23, 2015

Are bugs on one device more serious than bugs on another?


Overheard (somewhere I'd expect people to know better):

"Bugs in mobile apps aren't as serious as bugs in desktop apps."

Really?
What are the implications of believing this?
What happens when this is the prevailing attitude in the developer culture? In a company or in a wider community? Especially when "building once to run everywhere"?


The background to the above quote was that they believed that lots of mobile apps are buggy but desktop apps are generally of a higher quality.

I think the opposite is true (at least of good apps). The connection to mobile devices and the competition between apps mean that bugs are more obvious and developers work harder to avoid and address bugs as part of a greater focus on UI & UX.
On the desktop there hasn't, traditionally, been a great focus on UI & UX and quality hasn't been as great as users are more tolerant of bugs and a substandard experience as their expectations are lower.

Of course, in a brave new world of universal apps that run on multiple devices a bug can easily exist on both mobile and desktop. The good news in such situations is that you can fix it in both locations at once. But sometimes that might not be the case and you could have a bug that only manifests on one platform. This means you have to test everywhere.




If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Thursday, June 18, 2015

Using a keyboard shortcut for the back button on your Windows [10] desktop app? Set IsTabStop on the page to True

*Disclaimer - This is based on my experience with the current preview tools/SDK. Things may change in the future.*

So, you've got a Windows 8[.1] desktop app and want to port it to Windows 10 (or just want to build a Windows 10 app that will run on the desktop), read on.

If your app has more than one page you'll almost certainly have some way of navigating backwards through the page stack. The default way of doing this will be with some form of button on screen that the user can tap with their finger or click with their mouse.

But what about the keyboard?
Yes, it's possible to `Tab` to the back button and invoke it that way, but if you have a page with a lot of controls on it it may require a frustratingly large number of key presses to "tab" to the back button.
A common (defacto/unofficial) alternative is to use the keyboard `Escape` and/or `BackSpace` buttons as a shortcut.
If doing this you'll probably do so by adding a `KeyUp` (or `KeyDown`) event handler to the page.

Here's where it get's fun.

To have the page listen to keyboard events it needs to have focus (or contain controls that have focus and let event bubble up to it).
In Windows 8.1 a page code get focus and listen to events even if `IsTabStop` was false (the default).
In Windows 10 a page must have `IsTabStop` set to True to be able to get focus and be able to listen to key press events.


Discovering this cost me far more time than I would have liked. I document it here in the hope that it saves someone else some time in the future.




If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.