It’s been a while, and there’s been a lot of confusion surrounding this topic of “5 free apps”, so here’s the final low down:

• Unlimited number of paid applications
  • This includes updates to said applications
  • A paid application cannot be made free
• 5 submissions of free applications
  • Unlimited updates to accepted free apps
  • WARNING: failed submission of free applications will count against the 5 submissions

So let’s walk through a scenario

A (for “awesome” which seems to be my word of the last couple of months) signs up for the marketplace, pays his $99 (or equivalent in local currency) and gets approved. He then submits “A’s AwesomePaid App” which fails submission. He fixes the problems, resubmits and the app is published. Based on feedback he submits 4 subsequent updates. Up to this point A has paid no extra fees.

A then decides to become philanthropic and submits a free application. The application fails submission – and now A is only left with 4 free submissions. A resubmits and the submission goes through, at which point he starts submitting updates, and has 3 submissions left. No matter how many updates A pushes, they will still have 3 submissions remaining.

If you happen to be down at TechEd Europe this week, don’t forget to come by the Windows Phone 7 and Silverlight booths (they’re opposite each other in the Technical Learning Centre) and say hello. You’ll get to play with some phones from HTC and interact directly with both teams – don’t miss out!

Something else you shouldn’t be missing out on are all of the Windows Phone 7 oriented talks (both XNA and Silverlight) and especially, shameless plug, my session on performance. You can find me tomorrow (Thursday, November 11) from 12:00 PM – 1:00 PM  in  Hall 7.3b Europa 1.

See you there!

Updated Policy!

Sure, the App Hub site says:

Submit up to five free apps to Windows Phone Marketplace, additional submissions are $19.99 USD

But here’s what it really means:

Submit up to five free apps (including updates) to the Windows Phone Marketplace, additional submissions (of apps or updates) are $19.99USD

FTFY

Seriously

The policy is simple, just not stated that simply. The first five submissions of any free Windows Phone 7 application – be it a new application or an app update is going to be free, anything further is going to be $19.99USD.

In reality I don’t see this affecting the average casual free app developer out there (since they’re not making any revenue off this apps and, (very) generally, not submitting that many updates). It will affect those with free apps that have an alternate revenue source (think advertising or subscription) – but since they’re actually making money anyway, the $US19.99 shouldn’t be a big deal.

Stay tuned for an official blog post from the App Hub team at some point in the near future, and a revision to the wording on the website to clear this up…

It’s that time of year again – PDC 2010 kicks of tomorrow! Join the Silverlight Performance Team as we take you through the high level analysis of common performance issues that apps commonly run into. I’ll be giving a live session titled “Optimizing Performance for Silverlight WP7 Apps” at 3:15pm (PDT) on day 1 (28 October 2010).

Even if you couldn’t make it here to heckle me in person, the rest of the team will be online and answering your questions (or heckling on your behalf) as you watch the live stream via the online player, which you’ll be able to find at http://player.microsoftpdc.com.

Make sure to check out the session before mine (“Things I Wish I Knew about Building WP7 Apps” by Jaime Rodriguez) and all of the rest of the Windows Phone 7track. There’s other great content at PDC that’s worth checking out, but we all know that that’s secondary!

See you there!

I’m working on a WP7 library which helps analyze your VisualTree and to provide a visual aid, I take WriteableBitmap snaps of the elements. Unfortunately I (seemingly) randomly encounter the following exception:

A first chance exception of type ‘System.Exception’ occurred in System.Windows.dll

When digging into the exception you may find that the error is actually a HRESULT which is being bubbled up from the lower native layer:

E_UNEXPECTED (0x8000ffff)

What’s going on?

You guessed it – this isn’t random! In fact, this only happens on completely obscured (or off screen) elements which have never had a chance to render. In this case when you try to take a WriteableBitmap snap, instead of it forcing the control to render, it simply fails. This will hit you in the case of any element that has always been obscured. As soon as the element is unobscured it will be good to go (so you could do some VisualTree manipulation if you *really* needed to grab that shot).

… as opposed to multiple apps, each with a different locale.

Why?

1. If these are free apps, then each language will count towards your free app quota (you get 5 free apps that you don’t need to pay certification costs for)
2. Regardless of price, each app will need to go through independent certification (which will then take longer for all apps to be released), instead of one app being certified and published with all languages

Happy App Hubbing!

YES! Visit: http://create.msdn.com/en-us/home/getting_started and click “Install Now” to download the tools, directly, for free, without the need to sign up first.

Ever since the release of the new developer portal (http://create.msdn.com) I’ve been hearing that you need to signup to get the tools, hence they must no longer be free. In reality, what happened is that the old developer website url redirects directly to a login screen, instead of to the new site, leading people to believe that the tools are no longer free. Let me assure you – they are

Happy App Hubbing!

Take Away’s:

1. Wherever possible (i.e. no transparency) use JPEG images since these decode faster than PNG
2. Make sure your images are correctly sized (you don’t want to waste cycles with resizing on the fly)
3. Always compile your images with a “Build Action” of “Content” instead of the default “Resource”

Some Background:

1. JPEG (JPG) decodes faster, simple as that. The difference will continue to shrink over time, but every cycle is important on the phone, especially on image intensive applications.Don’t take this to mean “never use PNG”, rather, PNG is slower so only use it when you need it (transparency) as opposed to for everything as a generic default.
2. Although resizing is quick (even if it looks ugly) there is no point wasting those cycles resizing images on the fly (Silverlight will do this for you) if you can already size the images correctly from the start.
3. The default when adding new images is to set “Build Action” to “Resource” (under the Properties window). Make sure to always change this to “Content” in order to reduce the size of your DLL, speeding up both app load and image load.
   

   The properties window, with the correct "Build Action" set

   
   

File this one under “Sad, but True”…

Take Away’s:

Always prefix your source paths with a “/” (full-qualified path) instead of simply using relative paths.

Correct:

 <Image Source="/Resources/Images/Background.jpg"> 

Incorrect:

 <Image Source="Resources/Images/Background.jpg"> 

But they both work!?!

True, both of these will work, equally well (visually), but performance wise the relative path will do extra lookups which waste time, and can hit the SD card more than you want it to (causing further slow downs). This is something that we will fix on our side in the future – since all storage is isolated and we can assume that there is always a “/” (if there is no “..”). For now, it doesn’t hurt to get the extra performance boost by simply prefixing your paths with a “/”.

Note:

As Luke Kim, a friend from Microsoft, pointed out “/” paths are not really full qualified paths. To make things clear though, I use the term “full qualified” since we are within the confines of the .NET IsolatedStorage framework and there is no access to the rest of the system, “/” paths are as fully qualified as you get (without actual URI specifiers). Thanks for pointing this out!