Windows Phone 7 Launches in Australia

Windows Phone 7 Launches in Australia

Microsoft Australia held it’s press events this morning in a rather obscure venue to officially launch Windows Phone 7 into the Australian market with devices to be available on the 21st of October. Whilst there were the usual presentations from Microsoft and the launch carrier Telstra, it was the feature demos that really took the show. Having worked with the platform for over 6 months now there wasn’t much new material but it was great to see the range of slick looking devices being rolled out later in the month.

What frustrates me is how useless the Australian telcos are. All three of the majors, Optus, Vodafone and Telstra are carrying Windows Phone 7 devices but not one of them has bothered to update their consumer website with information about the phones. To make matters worse, the main page of all three sites are still going on about the fact iphone 4 “changes everthing again” (no it doesn’t, Apple haven’t innovated in 4 generations of the phone….)

If you go to the Telstra site you get an iphone4 ad on the consumer pages. You do however get a Windows Phone 7 ad on the business page. Did I miss something? Isn’t this launch about the consumer, not the business user?

image image

Windows Phone 7: Jumping through the Back Stack

Windows Phone 7: Jumping through the Back Stack

Having a Back Stack within your application is a mixed blessing. Whilst the navigation service will allow you to easily step the user from one page to the next, allowing the user to return to the previous page via the back key, it can often end up with applications that are 10 or more pages in length. If the user wants to exit the application, or to go back to the previous application they have to step through all the pages (Internet Explorer, one of Microsoft’s own applications, is probably the worst case I’ve seen of this and imho is a complete design failure).

The guidance for building applications for Windows Phone 7 essentially suggests caution in opening up a new page for every activity the user does. Rather than a new page for everything, you can simply adjust the content rendering in the current page. This leads to another discussion on what’s appropriate use of the Back Button.

This morning I had a conversation with Shane ( regarding an application where the user had to step through a wizard. At the end of the wizard they effectively want to remove the wizard pages (ie the steps in the wizard) from the Back Stack, returning them to the page that they were on before the wizard. My thoughts are that the Wizard should be a single page where each step is essentially just a different visual state. The Back Button could still be used within the page, allowing the user to still step through the steps in the wizard. When they have completed the wizard it would then close the page, returning them to the previous page.

If my suggestion isn’t an option, then there are two ways (that I can think of) to return to the initial page:

– Throw an exception (eg GoHomeException) which is trapped by the Application_UnhandledException method. This could then navigate back to the initial page

– Set a global flag (eg GoingHome) and then use GoBack to return to the previous page. Essentially each page in the wizard would look for the global flag, and if it is set to true then it would automatically call GoBack until the initial page is found.

Both of these strategies can be seen in the following example

Windows Phone 7: Beating the Boot-time Blues

Windows Phone 7: Beating the Boot-time Blues

One of the things that you may have noticed when doing Windows Phone development is that it’s very easy to cause the startup or boot time of your application to blow out to a couple of seconds. This of course is the reason why there is built in support for a splash screen (add a 480×800 image called SplashScreenImage.jpg set as Content in order to have a splash screen appear for your Windows Phone 7 application). However a good application shouldn’t require a splash screen as it should start up almost instantly. This unfortunately is very hard to achieve – if you have an even moderately complex page as the first page of your application then startup time will be in the order of a second or so.

There are a number of things that affect the time it takes your application to start. One of the most significant things is the size of the initial assembly and any other assembly that is required at startup. The last part of this comment is just as important and often overlooked. If you move pages, classes etc into a secondary assembly, and your initial page references them (even if you have an instance variable of a type that is in the secondary assembly) that assembly will too be loaded into memory before your application starts!

Another thing that can cause a lot of pain (and in actual fact is a derivative of the above situation) relates to setting a background image for your page. There is a lot of guidance out there that states that all images should be added to your application with a build action of “Content”. This will ensure that they don’t blow out the size of your assembly and thus affecting the time your application takes to load. In most cases this guidance should be followed. However, if the image you are including is the background image for your page and you are setting the background image in the xaml of your page then the image should be included with build action of Resource. Why?….

Scenario 1 – Image as Content
– Application Starts
– Main Assembly is loaded (quick because image isn’t included)
– Page XAML loads
– Image is loaded from disk

=> Upshot is that both the assembly and image are in memory but it requires two round trips to disk, one to load the assembly, the other to load the image

Scenario 2 – Image as Resource
– Application Starts
– Main assembly is loaded (slower because image is loaded as it’s a resource)
– Page XAML loads

=> Upshot is that both assembly and image are in memory but now only one trip to disk to load the image, which is going to be quicker than two trips to load the same data into memory.

This is ok for applications where the main page is a simple page and the background graphics is relatively small. The impact on load time will be quite low (although will probably warrant the use of a splash screen). But what about applications that use the panorama on the initial page. If you include a large background image (say 800×800) so that is looks great when the user is scrolling left and right, all of a sudden you might have not one but perhaps 2 images that are almost 1Mb is size (2 images so that you can dynamically switch them between dark and light themes).

What to do?

Well, you should start thinking about delay loading them. The issue here is that you have to dynamically load the background on the Panorama control, which it doesn’t, out of the box, support. Dave has a great post on using XAML to set your background. Use this as a starting point and change the background layer to include an Image control. This will mean that you can data bind the Source property  to your view model. On startup set the Image source property to null (ie don’t load an image), then once the application has started set the source property to the uri of the background image (at this point you can decide whether to serve up a dark or light image depending on the theme set on the device). Don’t forget to set the build action of the images to Content, other wise you won’t see the savings.

If you simply set the new image Uri after startup the user is going to see the background image just appear – clearly not a great experience, so you can get creative and play around with animations to fade the background image in (change the Opacity from 0-100 over 2-3 seconds). Warning – Make sure you keep an eye on when the background image is loaded from disk. It’s very easy when playing with this stuff to accidentally force the image to load from disk at startup, rather than when you are transitioning in the background.

Happy boot time optimising….