Monday, 4 November 2013

What I think is the #1 preventable cause of WP App Cert Failure

The Disease - Certification Failure.

I am an experienced developer.  I have been writing code for more than a quarter of a century.  Let me pause for a moment... HOLY CRAP!!!  Now back to our regular programming.  As I said, I've been writing code a long time.  Mostly the final arbiter on whether I wrote good code or bad was if a customer called me up to complain or give me their visa card #.  Things are a bit different now.  Now I write awesome, fabulous code and instead of getting a customer to check it, Microsoft kindly does it for the customer in their store certification process (well, at least as a first pass).  That's really nice of them.  Well, it is until they decide my app is NOT wonderful and awesome.  I have published over 25 apps to the Windows Phone store and I STILL fail certification occasionally and there usually is no excuse except plain and simple laziness.  At least in my case, the certification failure is almost always because I forgot one of the steps in my checklist because I was in a stupid hurry to get the App in the store.  For me, at least, the #1 cause of certification failure is that stupid "light theme" on the Windows Phone.  I don't know anybody who uses the light theme but they can and sometimes I forget to check my App.

The Symptoms

Microsoft's Store certification report is quite useful.  It shows what went wrong and specifically what rule it breaks.  They then give you good steps to reproduce the problem.  If you, as the developer, have set up proper unit and functional testing before submission, you rarely should find surprises.  Out of the 26 apps I have submitted to Windows Phone I have probably had about 5 or 6 failures.  Of those 5 or 6, 90% are light theme.  You'd think I would learn my lesson.  But I don't.  Things that they note are buttons that disappear with a light theme, missing text, and entire chunks of UI that simply become essentially invisible.  Quite honestly it's embarrassing when it happens.  I should know better.  It's really easy to catch these things if you bother to check.  However to assist, I'm going to cover some stuff you can do to reduce the possibilities of it happening to you.  If you don't mind the ten to fourteen day turn around to fix that stuff and resubmit, but by all means use Microsoft as your QA department.  No need to read further.  I prefer to pass the first time in so I can start racking up those downloads.

The Medicine

First, the obvious.  Test your application.  Run through every function in BOTH themes, light and dark.  If you, like I, re-use components, build them to handle the different situations you might run into.  Most controls when dropped into your XAML designer don't need the "Foreground" and "Background" property assigned as they just default to the standard theme.  But what if your app has a background image that is pretty dark?  When a light theme is applied all the standard textblock or button will automatically switch to using "Black" for their colors.  Well, that won't be too visible on your fancy background you, no doubt, spent hours designing and creating.  So you set the foreground and background to White ensure it visible.  This code you wrote is pretty slick so you use it on another app, but that app has no background.  So when the phone user switches to "light" your text disappear.

One way to deal with this is assign "StaticResource" names using standard values.  MSDN provides a menu of theme resources from colors to fonts on this page: http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769552(v=vs.105).aspx.  You can set resources at the top of your XAML page that you can then use globally throughout your page.  In this example I'm setting the Foreground to the standard PhoneForegroundBrush which will automatically flip between black and white based on the theme.  You could just as easily put in "White" for the value of foreground.
<phone:PhoneApplicationPage.Resources>
   <Style x:Key="LabelStyle" TargetType="TextBlock">
     <Setter Property="HorizontalAlignment" Value="Right"/>
     <Setter Property="Margin" Value="15,5" />
     <Setter Property="FontSize" Value="{StaticResource PhoneFontSizeExtraLarge}" />
     <Setter Property="Foreground" Value="{StaticResource PhoneForegroundBrush}" />
   </Style>
</phone:PhoneApplicationPage.Resources>
<Grid x:Name="LayoutRoot" Background="Transparent">
    <TextBlock Style="{StaticResource LabelStyle}"
       Grid.Row="0"
       VerticalAlignment="Center"
       HorizontalAlignment="Center"
       Text="Hello World"/>
</Grid>
 
 For me, anyway, I like to make sure I have assigned values that I can then fix in just one place.

A fellow by the name of Jeff Wilcox came up with something called the Windows Phone Theme Manager which lets you globally set the theme in your app.  It's available through Nuget and lets you force your app into a particular theme.  This is for you to decide but it can let you control the effects of a user changing the theme.  Much like the Mail App is always "light" them (although this is changing) you can do the same thing to your app for either light or dark.  Read his warnings about battery consumption and overriding a users wishes.  I know that I always select dark on my phone and get annoyed with I get blasted by a bright white interface so change at your own risk.

http://www.jeff.wilcox.name/2012/01/phonethememanager/

It always comes down to testing, testing, testing...  Try all your apps functions in all the themes. If you use the Accent Brush, test against the colors available.  If you use a blue background with the accent brush used for text because you use a red accent color and think it looks cool (hey... it could happen) but somebody else prefers a blue accent color, the text is going to disappear.  But that is for another conversation!