As can be expected, I removed my custom/personal ACS information from the sample code. This includes the acsnamespace and realm resources in the AccessControlResources.xaml file within the Phone project, and the SwtSigningKey, realm, and namespace values from the MVC project’s web.config file. These values can be obtained from a new or existing ACS namespace as follows:

ACS Configuration Values

These values are available in the following locations (Note – this is based on the current Silverlight-based management portal. Precise locations may shift slightly when this content moves to the newer HTML5-based portal.)

The namespace value is the namespace you indicated when creating the ACS instance.

The Realm is specific to the relying party application that has been configured, and can be found on the Relying Party Application page:

The symmetric key can be obtained from the Access Control Service management portal, selecting Certificates and Keys, selecting (and/or creating) a Symmetric Key specific to the namespace:

Async CTP

Also, please remember that the code made use of the Async CTP assembly. This was not strictly required, but was instead put in place to help improve the code flow instead of using Lambdas or complete methods for the various callback functions used when interacting with Azure Storage. Information about the Async CTP is available here.

You may have noticed that in many places of the Windows 8 Metro UI, as well as many Metro applications where list content can be selected, that making a selection automatically/magically (“automagically”) brings up one or more app bars. This is consistent with the “Guidelines and checklist for app bars” published in the Metro Style Apps Dev Center:

Do place contextual commands on an app bar and show that bar programmatically.

If you have commands that are specific to the mode of the app, such as the Crop command appearing only when a photo is selected, place those commands on an app bar and show it programmatically while in that context.

If you have commands that can be performed whether content is selected or not, keep those commands on the bar if you have enough room.

Do set the app bar’s dismissal mode to sticky when displaying contextual commands.

If you have contextual commands on an app bar, set the mode to sticky while that context exists and turn off the sticky mode when the context is no longer present (such as when a photo is deselected). In sticky mode, the bar doesn’t automatically hide when the user interacts with the app. This is useful for multi-select scenarios or when the context involves interaction such as manipulating crop handles. The bar stays visible while the user performs their actions. The user can still hide the bar by swiping the top or bottom edge of the screen and they can show it again with an edge swipe.

One place where this behavior can be seen occurs when selecting and deselecting tiles in the Metro Start Screen.

Of course, this is nice and all, but sitting down to implement this (it isn’t out-of-the-box behavior) for the Metro XAML list controls (ListBox, ListView, GridView), I figured I had several options. First, I could just handle the SelectionChanged event and in the codebehind I could programmatically bring up and/or collapse the page’s app bar(s). That would do for one-off code, but its hardly the approach I would want to take for a more robust application. A second option is to bind the list’s SelectedItem(s) property to property on the page’s ViewModel, and either use a related property or a ValueConverter to bind to the AppBar’s properties. This felt a little bit much for wanting to simply alter the behavior of one control to react to the behavior another control. There are other solutions that fell into this category as well (ViewState etc.) What I ended up coming up with is a quasi-Behavior using Attached Properties that makes this (ahem) behavior reusable and quite easy to wire up.

Note: Another similar approach would be to actually use Behavior<T>. Although this component of the Blend SDK is not included with the WinRT tools, some folks have published the equivalent WinRtBehaviors project on CodePlex at http://winrtbehaviors.codeplex.com/.

As I mentioned, at the heart of this implementation are an attached property and a set of Flags indicating which app bar(s) should react to the selection change.

Nothing really fancy there…just a simple attached property – I opted to indicate the owner as the Selector class instead of the containing class simply for convenience. The important part is that the attached property is defined with a callback to be used when the value of the attached property is changed – OnAppBarDisplayOnListSelectionChanged.

In the property changed handler, a check is performed to see if the code is running in the designer – if so, everything bails out. Otherwise, the selector to whom the property is being applied is obtained (if not found, bail out). The selector and the value of the flags are then passed to a helper method to handle hooking up to the pertinent events.

In HookEvents, as long as one of the app bars is of interest, listeners are registered for the selector’s Unloaded and SelectionChanged events. Some preemptive housekeeping is also performed to first unhook the same events in order to prevent leaks. The Unloaded event merely unhooks these same events to once again prevent leaks.

The big workhorse is the HandleSelectionChanged event handler. First, the Visual Tree is traversed until an ancestor of the Selector is found that happens to be a Page – which is presumed to be the site of the app bar(s) being affected. Then the current state of the setting to show the top and/or bottom app bars is determined, and finally, if an item is selected, the appropriate app bars are shown. If no item is selected, the appropriate app bars are collapsed.

Obviously, this seems like a long way to travel – the value is realized when there are multiple Selector’s scattered throughout an application where this behavior is to be applied, and/or when this code is shared across multiple applications. The entire code for the class containing the attached property follows:

As anyone who has implemented the INotifyPropertyChanged interface knows, the fact that the PropertyChangedEventArgs takes a property name as a string means that you are one fat-fingered mistake away from a bug that can sometimes be difficult to track down. If the property name supplied in the string doesn’t match the actual property name, the data binding (or other operations) that relies on this interface doesn’t work properly.

Now there’s a new feature in .Net 4.5 that provides yet another opportunity to ensure that INotifyPropertyChanged is implemented correctly – possibly in a simpler fashion than ever before, and with better performance than the Expression Tree/Lambda expression approach.

.Net 4.5 includes 3 new “Caller Information” attributes – CallerFilePathAttribute, CallerLineNumberAttribute, and CallerMemberNameAttribute. These three attributes are scoped to individual method parameters, and when used, they apply the indicated value from the CALLING METHOD to the called method’s attributed parameter at run time. In our case, we’re interested in the CallerMemberName attribute, which we can use to automatically retrieve the property that is trying to raise the property change notification:

Note that the Caller Information attributes require a default value be supplied.

This reduces the overhead of a property in the class that provides this method to the following:

1:public Int32 MyProperty

2: {

3: get { return _myProperty; }

4: set

5: {

6:if (_myProperty != value)

7: {

8: _myProperty = value;

9: OnPropertyChanged();

10: }

11: }

12: }

Of course, one important question is how does this method perform in comparison to either just providing a string, or using the Lambda/Expression Tree approach? In my tests with iterations of between 1,000-500,000 property changes I saw between ~10-30% performance improvement over the Lambda/Expression Tree approach, and performance between ~20-30% lower than using a directly supplied string.

A recent network “hiccup” posed a bit of a challenge to a demo that was built around showing how the Windows Azure Toolkit for Windows Phone (WATWP) NuGet packages make it easy to add Windows Azure cloud features to a Windows Phone 7 application. So how do you access NuGet content when a network connection isn’t available? What if you want to exert some management over the updates that are exposed to the developers in your enterprise, including exposing often-used or internal-use assets?

It turns out that NuGet offers some functionality that addresses these scenarios. In addition to supporting the ability to set up your own package server (also known as Creating Remote Feeds in the NuGet documentation), there is the ability to consume packages collected in a directory – either a network share or a local file-system folder. This is illustrated in the NuGet documentation under the subtopic “Creating Local Feeds” within the “Hosting Your Own NuGet Feeds” topic.

Populating a File-System Based Package Store

Any folder that contains NuGet .nupkg files can be set to be as a file-system based package server. From my own use, folders that contain subfolders with .nupkg files will also work, allowing for organization and hierarchy. If you already have a Visual Studio solution that has references to NuGet packages, moving these packages into such a local package store can be quite simple (especially for demos!) Just locate the “packages” folder that is created when the NuGet packages are added

The entire package folder is not required, since the nupkg files are really Zip files that contain all of the necessary contents. Search for files that end with the .nupkg extension.

Simply copy all of these files into the folder you are using for your file-system based package store. Note that a wider set of packages is available in your local package cache, which is normally maintained in <UserFolder>\AppData\Local\NuGet\Cache, and can be accessed from Visual Studio via Tools-Library Package Manager-Package Manager Settings, and click the “Browse” button in the General section of the Package Manager settings node.

Using File-Based Package Stores

To tell Visual Studio to consume file-based package stores, bring up the settings dialog (via Tools-Library Package Manager-Package Manager Settings or through the other accessors in Visual Studio) and select the Package Sources section of the Package Manager settings node. Provide a name and type in the path or browse to the package location and click the Add button. Note that the elements in the Available Package Sources list are shown in a check-list-box – they can be enabled or disabled. Elements in the list can also be reordered in order to determine the precedence in which the sources are searched for matching packages.

When adding NuGet package references to your project in Visual Studio via the Manage NuGet Packages dialog, note that the newly named source now appears within the “Online” package listing section.

The new source is also available as a pulldown option in the Package Manager Console window.

As I’ve been digging into NuGet more lately, I’ve been quite impressed by the functionality it exposes. There’s much more to it than just a right-click menu item and a dialog box that adds and updates project assembly references. Some of my current favorites include managing package references at the solution level and visualizing NuGet package chains. Be sure to check out the NuGet docs in case you have yet to discover your favorite.

Many thanks to the attendees of my presentation tonight covering Developing Cloud Enabled Windows Phone Applications with Windows Azure. I apologize once again for the technical network-related gremlins that decided to attack us tonight…hopefully the workaround covered the necessary ground and everyone was able to see the concepts I was trying to show.

As promised, I have posted the content for the presentation here. This includes the slide deck with the various resource links, as well as the final project. As I mentioned, I have “sanitized” the configuration of the project to omit my specific Access Control (ACS) settings. This involved changing the AccessControlResources.xaml file in the phone project and the Web.config file in the web role project. Look for the text [your-xxx-here] for where to substitute your own ACS information.

Because the network issues prevented us from accessing the NuGet site or repository, I wanted to be sure to list the packages that were used in these projects:

I would like to thank the organizers and attendees of the recent 16th (wow!) Boston Code Camp where I did a talk on Developing Cloud-Enabled Windows Phone Applications with Windows Azure – and special thanks to everyone who stuck it out once the snow started falling in order to catch my talk. Obviously, it took longer than expected to get this content posted – Nashua got hit especially hard by the storm, including a 75% city-wide power outage the day following the Code Camp event, along with accompanying telecom and even cellular outages. I am happy to say that I finally got my power turned back on mid-week, and am slowly but surely digging out of the mountain of backlog that piled up during the multi-day outage.

The content can be found here. Because I demoed ACS, some of the items that are placed in the project would normally reference my “real” Azure account…they have been removed and replaced with the phrase “YOUR CONTENT HERE.” You will need to replace these values with your own from the Azure ACS management portal in order to be able to run the provided code. Also, in order to use the Azure Emulator, be sure to run Visual Studio in Admin mode when working with this project.

I had a great time talking about the Windows Azure Toolkit for Windows Phone at the Windows Phone Camp event in Cambridge, MA earlier today. I have posted the slide deck here for those who are interested in getting at the web links it contains.

If you missed the event and/or are interested in other Windows Phone Camp events, more information is available here.