Unlocking your WP7 Device for App Development

So you’ve finally got some shiny new Windows Phone 7 hardware and you want to plug it in and start testing the fart app you’ve been working on for the last 5 months.  So how do you do it?

When it comes to unlocking your device Microsoft don’t exactly make it that obvious .  Firstly if you try and deploy to a locked your phone you will get a deploy error message saying “Application launch failed. Ensure that the device screen is unlocked and device is developer unlocked. For details on developer unlock, visit http://go.microsoft.com/fwlink/?LinkId=195284.  Unfortunately the  link they provide isn’t at all helpful – it just points to the AppHub home page.

What if you look at the “My Registered Devices” in the AppHub, may be that will tell you how to register a device?  What you see there a message saying “The following devices have been registered and may be used to test your unpublished Windows Phone 7 applications. Adding additional devices must be accomplished through Visual Studio…

Ok, so how do you register your phone in Visual Studio? … Turns out you can’t! You need to use a separate tool which is part of the Windows Phone Developer Tools and is nothing to do with Visual Studio.  Great!

So here is what you need to do to unlock your phone for development:

1) Make sure you have registered as a developer on the AppHub and have paid your subscription.

2) Install the latest version of the Zune software.

2) Plug in your phone via USB and let Windows setup the drivers.

3) Lunch the Zune software and make sure that it picks up your device.  The Zune software is the gateway to the device it will always need to be running for any software on your PC to be able to talk to the phone – including Visual Studio when you are debugging.

4) Next you need to unlock your device using the Windows Phone Developer Registration Tool which can be found in the Windows Phone Developer Tools folder of your Start Menu.

image

Enter the Live ID details for your AppHub account and click Register.  After it has connected to AppHub and verified your details it should say “Your phone has successfully been registered.”.

NOTE: This process doesn’t unlock your phone immediately.  It takes a little while for your phone to get the message that it is now unlocked – but usually less than a minute.

Now the phone is unlocked you should see it in the “My Registered Devices” of AppHub

image

Once that is all done you should be able to happily deploy your apps to your phone – but remember the Zune software always must be running in order to deploy to your device.

Come back for my next blog post on deploying your first app to a device.

Advertisements

How to check if you have an network connection on WP7?

UPDATE:  Actually checking the network connection in this way is very bad.  As it turns out accessing NetworkInterface.NetworkInterfaceType is a blocking call which can hang the UI for long periods (over 20 seconds in some cases).  See my later post on this topic for more details and a better solution

With all this talk of the cloud it can be easy to assume that you will always be able to make a connection to the internet from a Windows Phone 7.

Unfortunately as we know this is not always the case – even in built up areas.  I live smack bang in the centre of London and yet for at least 50% of my commute to work I cannot get a workable mobile data connection.

So how can you detect what type of connection you have on a Windows Phone 7 device?

Thankfully the answer is easy enough.  Turns out there is an App for that…err… I mean there is an API for that.

NetworkInterface.NetworkInterfaceType

This is one of the mysterious non-Silverlight API’s that are available on the phone.

Typically you will just be interested in whether or not you have a data connection.  In which case the following will do the trick:

bool hasNetworkConnection =
              NetworkInterface.NetworkInterfaceType != NetworkInterfaceType.None;

You may also be interested in which type of connection you have, is it via WiFi or 3G?  If you are about to download a huge file you might want to make sure you are not about to burn through your users 3G data allowance without them realising it.

The NetworkInterfaceType enumeration holds the key working out which connection you have. Oddly enough the enumeration includes a large number of connection types and most of them aren’t even possible on the phone. Nevertheless the useful ones are:

None The phone is not connected to any data network
Wireless80211 The phone is connected to a WiFi hotspot
MobileBroadbandGsm The phone is connected to a GSM network
MobileBroadbandCdma The phone is connected to a CDMA network (US and parts of Asia only)
Ethernet The phone has an ethernet connection (typically this is when the phone is connected to a PC via USB)

There are three things to remember here:

  1. If you are checking for a mobile data connection always check for both MobileBroadbandGsm and MobileBroadbandCdma. Even you are only targeting a market which only has GSM devices can you be 100% sure no one will need to run your app on a CDMA phone?  Don’t forget app purchases are tied to Live ID’s not phones.
  2. When you are debugging the phone via USB you have always have an ethernet connection with the device so the check above might not return the correct result.  You might choose to exclude ethernet connections from the test as follows:
    bool hasNetworkConnection =
                  (NetworkInterface.NetworkInterfaceType != NetworkInterfaceType.None)
    #if DEBUG
                  && (NetworkInterface.NetworkInterfaceType != NetworkInterfaceType.Ethernet);
    #endif
    
  3. Checking  the NetworkInterfaceType doesn’t guarantee you will be able to connect to the remote server.  Remote calls will often fail even if the phone thinks it has a connection – especially if you are moving.  Similarly just because you are connected to a WiFi hotspot it doesn’t mean you can access the internet through it.  So you still need to program defensively and expect and handle exceptions that are likely to result from a poor connection.

Also remember this only tells you if the phone is connected to a network. You have no way of knowing whether that network is connected to the internet until you actually try to connect to a server.

Tips for ProgressBar Performance in WP7

It turns out that there are some performance gotcha’s surrounding the use of a ProgressBar control in “indeterminate” mode in the WP7 SDK.   Indeterminate mode is the infinite mode where the progress bar is animated with 5 dots flying across the screen indicating that the app will be busy for an indeterminate amound of time. 

Here are two tips (from the mouth of Jeff Wilcox) which you should be aware of if you use this control in the “indeterminate” mode:

1.  Don’t Use the Default PerformanceBar Style

There is an unfortunate performance issue with the default way the PerformanceBar is constructed in the WP7 SDK.   To achieve the effect of the dots flying across the screen the standard control actually uses 5 slider controls (where the thumb of the slider is actually styled to be the dots).  Not too surprisingly this turns out not to be a very efficient means of achieving the animation, since the sliders designed to be slider controls not animation mechanisms.  The net result is that using slider control for the animation generates a lot of work for the UI thread, when in actual fact we want to off load tasks such as animation to the Compositor thread where ever possible and leave the UI thread for things like layout passes and our application logic.

The good news is that Jeff Wilcox has posted a new alternative way to animate the indeterminate progress bar using another, more Compositor thread friendly method – the RelativeAnimatingContentControl.  He also provides a style which can be applied to any existing ProgressBar to make it use the RelativeAnimatingContentControl rather than the sliders.

Using Jeff’s new PerformanceProgressBar is fairly simple:

  1. Download and add the RelativeAnimatingContentControl.cs to your project.
  2. Define a new ProgressBar style (in your app.xaml or generic.xaml) called PerformanceProgressBarStyle you can download the XAML for this style from: PerformanceProgressBarStyle.txt.  Don’t forget to add the xml unsupported namespace to which ever XAML file you add the style to:
    xmlns:unsupported="clr-namespace:Microsoft.Phone.Controls.Unsupported"
  3. Apply the PerformanceProgressBarStyle style to all your ProgressBars (unfortunately you have to remember to do this on all ProgressBars – there is no way to do this globally, like there is in WPF)
    <ProgressBar IsIndeterminate="True" Style="{StaticResource PerformanceProgressBar}"/>

2. Make Sure You Turn Off the Perpetual Animation when the ProgressBar is Not Visible

If you are using an indeterminate progress bar you will likely be tempted to do this

<ProgressBar IsIndeterminate="True" Visibility="{Binding IsBusy}"/>
 
That is: hard code IsIndeterminate to true and then just control whether or not the ProgressBar is visible or not. 
 
Unfortunately this will impact performance of the phone (and more importantly battery  life).  The reason is that as long as the IsIndeterminate property is true the application will continue animating the dots – even if the ProgressBar is not visible!  So never hard code the ProgressBar’s IsIndeterminate property always bind to it to the visibility of the ProgressBar so that if the ProgressBar is not visible the animation stops. 

 

The easiest way to do this is to bind the IsIndeterminate and Visibility properties to the same underlying value.

 

<ProgressBar IsIndeterminate="{Binding IsBusy}"Visibility = "{Binding IsBusy, Converter={StaticResource VisibilityConverter}}"/>

 

In this case we are binding both to a boolean IsBusy property on the View Model. We use a VisibilityConverter class to convert the boolean value to a valid visibility option.

WP7 Design Templates

Do yourself a favour.  Don’t write another line of WP7 XAML without the WP7 Design Templates.

Wp7 Design Template ScreenWe WP7 devs have been complaining since the CTP that although there is documentation for the Phone’s UI, it is almost impossible for most developers to create apps that are consistent.  Sure we can make things that look much like what you see in native phone apps but there are always subtle (and not so subtle) differences.

The SDK has a few built-in resources for colors and fonts, and some basic control themes that rather crudely approximate native look and feel, but there is little help when it comes to margins, padding phone sizes and layout styles.  Developing apps that adhere to the guidance and maintain the look and feel of the native OS has been a pain in the ass. 

The problem has been make slightly easier by the release of the Windows Phone 7 UX Guide application by the Expression Blend team.  This is a project (which is itself a WP7 app) which includes some default layouts for common scenarios.

It includes default layouts and templates for:

  • Buttons
  • Check Boxes
  • List Views
  • Toggle Switch (Silverlight WP7 Toolkit)
  • Dialog Boxes
  • Context Menu (Silverlight WP7 Toolkit)
  • Slider

It doesn’t really help for any of those projects you already have UI for.  But if you are starting a new piece of UI it is simply a matter of copy and pasting the XAML of the layout you want to replicate into your project.  Then you can start customizing it as required.

This code is super helpful.  If you are going for the native look and feel then these examples are definitely your best starting place.  But bear in mind you do not have to make your app follow the default UI.  It’s okay to be different but the thing is it is an all or nothing game.  Either your app follows the UI guidelines or it should look completely different.

This CodePlex project is a good start by Microsoft to make it easier to create apps that follow the native UI (exactly, not just kind of the same), but it’s not complete and not really a long-term solution.  Using “copy and paste” inheritance is not usually a good idea.  When the next version of these templates get posted to CodePlex there is not going to be any way of updating existing projects. 

There are still plenty of things that need to just be a part of the framework (either as Blend assets, libraries or part of the API), like animations.  It is impossible to mimic some of the native animations currently in Silverlight.  Something as simple as the page flip animations are extremely hard to replicate – and before you say it, yes I know how to do a page flip animation.  It is making it feel exactly the native one that is hard. 

Even though the Design Templates haven’t shipped with Blend (and they really should have) they are still a good starting point, so go download them now.

Silverlight Toolkit to the rescue

The WP7 dev tools RTM’ed last night so we finally have a bona-fide pivot and panorama controls.

Unfortunately, as much of an advance as this is it still doesn’t completely make up for the fact that the default WP7 control set is still incomplete.  We’re still missing a a lot of cool gadgets and effects that make the native apps “sing”.

Thankfully the Silverlight Toolkit team have come to the rescue and are filling some (but not all) of the gaps in the official SDK.  The team has released the Silverlight for Windows Phone Toolkit.  Anyone who has done any level of Silverlight development will already be familiar with the Silverlight Toolkit.  Indeed many (including myself) have already used some parts of the main Silverlight Toolkit in Windows Phone 7 apps already. 

With the release of Silverlight for Windows Phone Toolkit the team are adding, features that are specific to the Phone, which includes:

  • GestureService/GestureListener
  • ContextMenu
  • DatePicker Control
  • TimePicker Control
  • ToggleSwitch Control
  • WrapPanel
  • The DatePicker, TimePicker and ToggleSwitch are all essential controls. 

    Unfortunately there are still one or two native controls for which there are no Silverlight equivalent, but these go a long way in rounding out some of the missing features in the main SDK.

    Download the Silverlight for Windows Phone Toolkit.

    Things to check before Mobile Marketplace registration

    A large number of people have reported issues when trying to register with the Windows Mobile Marketplace.  The registration system seems to be flaky as hell.   People, particularly outside of the US, are having no end of problems paying for their Developer Subscriptions.  To make matters worse they don’t seem to be getting an awful lot of help from Microsoft Support on what to do about it.

    This problem with Microsoft and credit cards is not unique to the Marketplace.  I’ve had problems with Microsoft and certain credit cards when trying to do things like buy e-learning courses for my team, paying for conferences and even buying XBOX live points.

    Things to Check

    So before registering with the Windows Phone Marketplace there are a few things you should check:

    • If you are registering outside of the US you may need to notify your bank in advance.  As a fraud prevention measure some banks automatically decline foreign transactions unless you notify them in advance.   Particularly if you’ve had fraudulent activity on your account in the past.  You may need to contact your bank and let them know you will be making foreign purchases.
    • Log on to https://billing.microsoft.com with the Live ID you are intending to register with.  Here you can see what billing information MS has tied against your Live ID.   This will list anything that Microsoft repeatedly bills you for.  So your  XBOX Live or XNA Creators Club subscriptions might show up here.
      • Make sure ALL the information they have here is correct.
      • The credit card information you enter into Mobile Marketplace should match exactly what you see here.
      • If you are going to use a different credit card to the one(s) listed still make sure the “personal information” section is correct and that you use this same information when entering the new credit card information when you register.
    • I would also suggest logging on to http://accounts.live.com and checking all your information there is also correct, and that your email address has been verified. I’m not sure that this has any affect on the process but mine wasn’t, so it is worth checking.
    • If you have more than one Live ID make sure that when you log on to register with Mobile Marketplace you log on with the one that is associated with credit card you are trying to register with.

    And if that didn’t work…

    Bad news is that even if all of this information is correct could still have problems.  The fact is that there are some credit/debit cards that it seems like Microsoft just will not accept.  It seems to be something to do with the company they use for credit card processing rejecting the cards at the pre-authorization stage.  It’s really poor on Microsoft’s part, credit cards that are perfectly valid and work perfectly well on other online vendors sites simply don’t work with Microsoft.

    If you are still having problems your only options are really to try different credit card.   Other than that you should contact your local Microsoft office and ask them what you can do.

    Windows Phone 7 Developer Links

    Here are is a bunch of stuff that I am finding useful for WP7 development. I’m tracking them here for my own use as much as anything so it is by no means a definitive resource, they’re just some stuff that I don’t want to forget about.
    Patterns/Tips

    Controls

    Expression Blend

    • Expression Blend Behaviors for WP7 – including EventToCommand behaviour – a way to add ICommand support to Silverlight 3 – and behaviors to change visual states based based on a view model property)
      http://expressionblend.codeplex.com/

    Accelerometer

    Gestures

    GeoLocation

    Advertising

    Obfuscation

    Push Notifications