Tech Valley .Net User Group Presentation Materials

I have uploaded the content from my Introduction to Windows Phone 7 Development with Silverlight talk at the Tech Valley .Net User Group meeting last night in Albany. The content can be found here, and includes:

  • Presentation slides, which include the reference links I mentioned during the talk.
  • The sample code, broken into 2 projects. Because the Notification Services portion of the talk adds extra projects to the solution ad is a little more complex to build and launch, that portion has been broken out into its own separate zip file.

For the Notification Services portion of the demo, the web project should be launched first, followed by the phone project (since the phone app calls the web site to register its URL for receiving notifications.) If the solution is run with the web project set as the default start project, the application bits do get deployed to the phone, but the debugger is not hooked up (unless multiple startup projects are used.) If debugging of the phone app is desired, it can be achieved by right clicking on the phone project and selecting Debug / Start New Instance. Also, this time the Notification Services demo includes the Push Notification Server-Side Helper recipe.

As usual, I have “sanitized” the uploaded code content by removing my personal Bing Maps application key. For information on how to obtain your own map key, please check out the Bing Maps Developer Portal.

Silverlight for Windows Phone Programming Tip – Be Sure to Scope Your SIP

Scope Your SIP – sounds painful, doesn’t it? Adding on to Jeff‘s series concerning WP7 Silverlight development tips, I figured it worthwhile to add another one. The SIP is the Software Input Panel – AKA the Phone’s onscreen keyboard. One of the handy features of the SIP is the ability to customize it to fit the needs of the textbox it is being displayed for – eg if you need to enter a phone number, why wrestle with a bunch of letter keys?
Figure 1- SIP default appearance (USA)
To do so, it is necessary to provide set the TextBox’s InputScope property to one of the values in the InputScopeNameValue enumeration, as pictured below:
<TextBox>
    <TextBox.InputScope>
        <InputScope>
            <InputScopeName NameValue="TelephoneNumber"/>
        </InputScope>
    </TextBox.InputScope>
</TextBox>
																			
Figure 2- SIP with TelephoneNumber Selected for the InputScope
Note that this is a little convoluted than the original description, which perhaps should have stated “it is necessary to provide the TextBox’s InputScope property with an InputScope object which contains the desired input scope name.” InputScope actually accepts a list of Names, of which only the first currently has any effect on the SIP display.
public sealed class InputScope : DependencyObject
{
    public InputScope();    
    public IList Names { get; }
}
If you want suggested word completions to appear as the user types letters, the only InputScope values that currently support completion are “Text” and “Chat.”
<TextBox>
    <TextBox.InputScope>
        <InputScope>
            <InputScopeName NameValue="Text"/>
        </InputScope>
    </TextBox.InputScope>
</TextBox>
																			
Figure 3- Showing Word Completion Suggestions with “Text” InputScope Selected

The New Phone Tools [are] Here! The New Phone Tools [are] Here!

With all due respect to Steve Martin’s hilarious portrayal of Navin R. Johnson and his quest for “his special purpose” in 1979’s The Jerk. Tonight Microsoft released the Windows Phone Developer Tools January 2011 Update, which can be downloaded here. In addition to the content in the new tools, there’s also some interesting other news concerning the availability of unsubsidized phones for purchase at Zones.com.

The New Tools

The big update item is the addition of Copy & Paste functionality. All TextBox and PasswordBox controls now get Copy and Paste functionality. This apparently applies to applications already in the Marketplace – once the update has been applied to the phone, Copy & Paste is available. The new behavior is bi-directionally compatible…controls within apps already on phones will automatically get Copy & Paste when the phone is upgraded, and apps compiled against the new Developer Tools will not misbehave on phones that have not yet received the update.

Note – the update is only for the developer tools – it is not yet available to be applied to devices – unlocked developer devices or otherwise. It only works in the Emulator.

Looking at the Copy & Paste behavior, when a TextBox has focus and a word is tapped, it gets a special highlight and the Copy Button appears. This works both with the mouse clicking in the emulator, as well as using touch when testing on a touch-enabled PC. There is no option for selecting portions of a word (eg to just select the “op” in the word “Copy”.) That last caveat is probably not that big of a deal, as selecting portions of a word on a touch device the size of a phone probably requires too much finesse. Multiple words can be selected – which is discussed below.

Figure 1- Selecting a Word and Displaying the Copy Button

To select multiple words, once the first word has been selected, it pressing and dragging on either edge allows the amount of text to be copied (in full word increments) to be adjusted

Figure 2- Extending the Selection to Multiple Words

Once text has been copied, a special Paste Button appears over the top of the onscreen keyboard (AKA Software Input Panel or SIP.) This is the same area where type-ahead suggestions appear.

Figure 3- The Paste Button on the Standard (US) SIP

Figure 4- The Paste Button on the SIP with InputScope Set to “TelephoneNumber”

In addition to TextBox and PasswordBox controls, the Copy & Paste functionality extends to controls that internally make use of TextBox controls, such as the Silverlight for Windows Phone Toolkit implementation of the AutoComplete Box. It also works for Text Input controls in web pages displayed in the WebBrowser control or in the phone’s Web Browser. However, in the WebBrowser control, the Copy Button can tend to “wander” a little bit…

Figure 5- Copy & Paste Controls in the Web Browser Control. Note the Odd Copy Button Placement

Paste is fairly straightforward. Select any control where the SIP appears and select the Paste Button. Paste is “single-shot” – there does not appear to be multiple Paste. Once the Paste Button has been pressed, the “clipboard” content is pasted into the target location, and the Paste Button is removed.

Two more quick notes about Copy & Paste:

  1. The “clipboard” persists outside of the application, so copied text can be used in other phone applications (for example, copying a Url from an application and pasting it into the browser’s address bar.) This also includes Tombstoning.
  2. The update also includes updates to the Pivot and Panorama controls. The update is for when TextBox controls have been added to panels within these controls, and aims to suppress inadvertent swipes when trying to copy text. Apps that have TextBoxes in Pivot or Panorama controls will need to be recompiled to get this change (they will still have Copy & Paste, though there may be some usability issues…)
    1. (Yes, the issue Jeff saw with Tombstoning is still there…)

Other Stuff in the New Tools

Other than the Copy & Paste feature, there are a couple of other things included with the update:

  • The Bing Maps Control has been updated for better gesture responsiveness
  • The update includes the Windows Phone Connect Tool, which is installed at <x86_ProgramFilesDir>\Microsoft SDKs\Windows Phone\v7.0\Tools\WPConnect. This tool can be used to connect a device for debugging when Zune is not running, which is necessary when debugging apps that use the media APIs.
  • The update includes the Windows Phone Capability Detection Tool, which is installed at <x86_ProgramFilesDir>\Microsoft SDKs\Windows Phone\v7.0\Tools\CapDetect. This tool is equivalent to the one used when applications are submitted to the Marketplace to inspect the app’s code so as to determine which capabilities are required by the app. These values are then used to replace the list in the app manifest. This tool can be used to preview what capabilities will be being detected before the app is submitted, in order to prevent issues like one (of admittedly several) issues seen by Shawn Wildermuth (see “Problem Part 4″) when an assembly that was inadvertently left in the application caused the app to report capabilities it actually didn’t need.

In addition to the tools, there is also a separate bug fix (VS10-KB2486994-x86.exe) that addresses a bug that existed whereby XAP files over 64MB could not be deployed by developers to physical devices for testing.

Issues with the Update

There is one known (at this time) defect with the update. Installing the update sets the default target for debugging Windows Phone Applications to be the “Windows Phone 7 Device”, even when a device is not installed. It is easy enough to change the value when Visual Studio barks at you, but it doesn’t “remember” the change, so it gets really old really fast.

Figure 6- The Default Debug Target for Phone Apps Changed to Windows Phone 7 Device

According to the Release Notes, the following steps are necessary in order to change this behavior (they work!)

  1. Close all Visual Studio and Windows Phone Emulator instances.
  2. Delete the contents of %LocalAppData%\Microsoft\Phone Tools\CoreCon.
  3. Restart Visual Studio.

Purchasing Unsubsidized Phones

In addition to publishing these new tools, apparently Microsoft has entered into a partnership with zones.com to allow the purchase of WP7 phones without going through one of the wireless carriers and the associated contract. The phones are locked to a specific carrier (it is not possible to take the Samsung Focus to T-Mobile in the US, for example), but they do allow developers to obtain devices for testing. As of the time of this writing, there is mention on the site of a “coupon code” which can be applied for some kind of discount, but I have no other information about any such offers. There are currently 3 phones available for purchase – the AT&T-offered HTC Surround ($500) and Samsung Focus ($525), and the T-Mobile HTC HD7 ($500). The zones.com developer purchase portal can be found at http://www.zones.com/windowsphonedeveloperpurchase.

A Matter of State, Part 2

The previous post discussed using the Page State Dictionary to restore a page’s state when navigating back to that page following the application being tombstoned. This post will discuss the use of the Application State Dictionary, and the final post in the series will discuss using Isolated Storage.

The Application State Dictionary

The Application State Dictionary has a broader scope for availability than the Page State Dictionary, but still has some similar limitations. It is also implemented as an IDictionary<String, Object>, and is exposed through the PhoneApplicationService instance’s State property. The current instance of the PhoneApplicationService is usually accessed through the class’s Current static property – eg PhoneApplicationService.Current. Any objects stored in the Application State Dictionary need to be serializable. It is important to note that if an item is added to the dictionary when debugging, an ArgumentOutOfRangeException will be raised, but at runtime this exception is silently ignored.

Although the documentation does not call out any specific size limitations, empirical testing has shown there is one of about 1.5MB (it actually varies between the emulator and an actual device.) Storing data larger than that will result in an unhandled COM Exception with the message “The client who called IAccessControl::IsAccessPermitted was the trustee provided to the method” [sic]. This error does not happen immediately, but instead happens when the application is tombstoned, after the Application’s Deactivated event.

The contents of the Application State Dictionary can only be accessed within or after the application’s Activated event has been raised and within or before the application’s Deactivated event has been raised. Any attempt to access the contents outside of these times will result in an InvalidOperationException being thrown. Just like the Page State Dictionary, once these limitations are understood, the use of the Application State Dictionary is straightforward.

private void Application_Deactivated(Object sender, DeactivatedEventArgs e)
{
PhoneApplicationService.Current.State["MyStuffToSave"] = value;
}

private void Application_Activated(Object sender, ActivatedEventArgs e)
{
if (PhoneApplicationService.Current.State.ContainsKey(“MyStuffToSave”))
{
value PhoneApplicationService.Current.State["MyStuffToSave"];
    }
}

 

Because the PhoneApplicationService is available throughout the application via the PhoneApplicationService.Current static property, the Application State Dictionary is available throughout most of the application (though it usually wise to respect proper architectural boundaries and hence be aware of what layer it is being called from.) In that light, the Application State Dictionary can be seen as a kind of globally-scoped collection of name-value pairs.

Both of the State Dictionaries keep their data in memory as opposed to Isolated Storage, which uses the phone’s file system. As a result, access to data is significantly faster. Some quick testing showed this to be ~30% faster on the emulator, and ~55% faster on an actual device, though individual devices are likely to report other results due to hardware differences.

There are some interesting scenarios that this state repository offers, including:

  • Remembering page control values for returning forward to a page
  • Passing data between pages that is too complex to pass via a simple QueryString parameter (though the key to the value in the dictionary may certainly be passed in the QueryString), without declaring a global variable to hold the data.
  • Remembering application-wide settings for restoration after a tombstoned application is reactivated

To use the Application State Dictionary to set page values following navigation, instead of using the Page State Dictionary to store a control’s state when leaving a page and to restore the state when returning to the page, the Application State Dictionary can be used, as illustrated in Figure 1, below.

Figure 1

  • The “Go to Page 2″ button is used from Page 1 to navigate to Page 2.
  • In Page 2, the user enters “User State 1″ in the first textbox and “User State 2″ in the second textbox.
  • When the user presses the Back Button from Page 2, the value of textbox 1 is put into the Application State Dictionary during the OnNavigatedFrom method
  • The user presses the “Go to Page 2″ button again. In the page’s OnNavigatedTo method, the Application State Dictionary is interrogated to see if it has a value, and if so, the value is applied to the first textbox
  • Note – if there is the possibility that the page whose state is being saved can be used in different contexts (for example, a page that shows details for a selected item on the first page), the key value for the setting should likely include the context, in order to properly resolve which value is to be displayed.

Another scenario where the Page State Dictionary can be used is for passing complex objects between pages. Remembering that navigation between pages on the phone does not involve actually creating an instance in code of the page to navigate to – the call to the Navigate method of the NavigationService with the Uri of the page to navigate to takes care of creating the new page instance. Although data can be communicated between pages via a QueryString parameter, complex data may not translate well to QueryString values. Using the Application State Dictionary to supplement the exchange of data between pages via QueryString information is illustrated in Figure 2.

Figure 2

  • The “Go to Page 2″ button is used from Page 1 to navigate to Page 2
  • A value is added to the Application State Dictionary. Remember that the item must be serializable to be placed in the Application State Dictionary.
  • The key for the value added to the Application State Dictionary in the previous step is added as a ValueKey parameter to the Uri provided for the Navigate command
  • In the Page 2 OnNavigatedTo method, the NavigationContext is interrogated for the QueryString ValueKey parameter. If the key is found, its value is used to retrieve the serialized object from the Application State Dictionary
  • Page 2 is then able to interact with the object that was passed to it from Page 1

Finally, the most common use of the Application State Dictionary is to preserve and restore application-scoped state when an application is tombstoned and reactivated. This process is shown in Figure 3.

Figure 3

  • At some point the application is tombstoned as a response to some user action (pressing the Start or Search button, etc.)
  • In the Application’s Deactivated event handler, the application’s state is stored in the Application State Dictionary.
  • The user presses the Back button to return to the application.
  • In the Application’s Activated event handler, data is read form the Application State Dictionary and used to restore the application state.

Another important note is that the application’s Deactivated event handler must complete in 10 seconds or less, or the application might be forcibly terminated and may be unavailable via the back stack.

The Application State Dictionary and Choosers

The term “Chooser” is applied to Windows Phone API elements that allow the user to launch an application that is part of the Windows Phone system in order to make a selection, and upon completion, return that item to the calling program by raising a Completed event. Choosers include:

  • The CameraCaptureTask launches the Camera application and returns a PhotoResult object (which includes a stream that contains the image data.)
  • The EmailAddressChooserTask launches the Contacts application and returns an EmailResult object (which includes the selected email address as a string.)
  • The PhoneNumberChooserTask launches the Contacts application and returns a PhoneNumberResult object (which includes the selected phone number as a string.)
  • The PhotoChooserTask launches the Photo Picker application and returns a PhotoResult object (outlined above.)
  • The SaveEmailAddressTask saves the provided email address to the Contacts list (it does not actually return any data, other than an indication as to whether the address was added.)
  • The SavePhoneNumebrTask saves the provided phone number to the Contacts list (it does not actually return any data, other than an indication as to whether the address was added.)

Choosers are distinguished from Launchers, which allow the application to launch certain Windows Phone system applications in a fire-and-forget model. Some Launchers include the WebBrowserTask, which opens a web browser with the given address, and the EmailComposeTak, which displays a new email message with given values for recipients, message subject, and message body, and there are several additional Launchers.

The guidance given for using Choosers advises that the Chooser’s completed event should be subscribed in the Page’s constructor. This is because when the Chooser is invoked, the running application *might* be tombstoned, losing the event subscription as part of that process. (There is documentation indicating that Choosers have been optimized to not always tombstone an application. Ssee the bottom of the article at http://msdn.microsoft.com/en-us/library/ff817008%28v=VS.92%29.aspx for a description of the optimization that may bypass this…still, since there is a grain of unpredictability, the action needs to be handled as if tombstoning is a certainty.)

The problem with Choosers is that the Completed event is actually raised before the page’s OnNavigatedTo method is called. This means that the Page State Dictionary is not available when responding to a Chooser’s completed event, and attempting to access it will result in an InvalidOperationException. Imagine the following scenario:

  • A page displays a list of items
  • The user can select an item in the list and press a Send button
  • The Send button invokes a Chooser to allow the user to select an email address
  • On completion of the Chooser, the page will use the EmailComposeTask Launcher to compose an email to the selected address with the text from selected item in the email’s body.

Using the Application State Dictionary, the selected item in the list can be saved off while the Email Address Chooser (potentially) tombstones the application and restored when the application returns with the chosen address, as the following code illustrates:

private readonly EmailAddressChooserTask _chooser = new EmailAddressChooserTask();

public Page1()
{
InitializeComponent();
    _chooser.Completed += HandleEmailAddressChooserCompleted;
}

private void SendButton_Click(Object sender, RoutedEventArgs e)
{
if (SelectionListBox.SelectedItem == nullreturn;
    PhoneApplicationService.Current.State["InterestingItemToSend"] = SelectionListBox.SelectedItem.ToString();
    _chooser.Show();
}

private void HandleEmailAddressChooserCompleted(Object sender, EmailResult e)
{
if (e.TaskResult == TaskResult.OK)
    {
     var emailComposeLauncher = new EmailComposeTask
         {
             To = e.Email,
                Subject = “This is Interesting”,
                Body =
                 “Check out this interesting thing” +
                    PhoneApplicationService.Current.State["InterestingItemToSend"]
            };
        emailComposeLauncher.Show();
    }
}

 

So now we’ve seen how the Application State Dictionary adds to the functionality offered by the Page State Dictionary, including exchanging information through several parts of an application, saving application state information across tombstoning events, and how it can be used to allow Choosers to get access to page state information when they return control to the calling application. The next installment will explore support for Isolated Storage in the Windows Phone system.

A Matter of State, Part 1

The Windows Phone platform offers several mechanisms for preserving your application’s state…the key is knowing which one to use when, and why. I’m going to try to provide some guidance to help answer those questions.
First things first – there are 3 key mechanisms provided for saving application state on the phone (4 if you count writing to some kind of cloud storage, but that’s beyond the scope of this discussion.) There are two state dictionaries, which under the right circumstances are saved and restored automatically, and then there is IsolatedStorage. This discussion will explore the uses of each one, with this post focusing on the Page State Dictionary.
The Page State Dictionary
This is by far the narrowest in scope of the 3 state-saving mechanisms. It is implemented as an IDictionary<String, Object>, and is accessible through a PhoneApplicationPage’s State property. To be stored in this collection, the objects that are placed must be serializable. There is also a limitation of how much data can be stored using this mechanism, with up to 2MB available per page and up to 4MB available for the entire application.
The contents of the Page State Dictionary can only be accessed within or after the page’s OnNavigatedTo method has been called and within or before the page’s OnNavigatedFrom method has been called. Any attempt to access the contents outside of these times (for example in the page’s constructor) will result in an InvalidOperationException being thrown.
Outside of these limitations, use of the Page State Dictionary is quite straightforward. When leaving the page (or any time prior), the data to be retained is written to the Page State Dictionary:
protected override void OnNavigatedFrom(NavigationEventArgs e)
{
base.OnNavigatedFrom(e);
State["UserStateData"] = UserStateTextBox.Text;
}
When returning to the page, the Page State Dictionary is interrogated for the value and, if present, the value is applied to the control.
protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (State.ContainsKey("UserStateData"))
{
UserStateTextBox.Text = (String)State["UserStateData"];
}
}
To understand when the Page State Dictionary is useful (necessary?), it is important to understand the Page navigation model in Windows Phone applications. To that end, a simple application is used, consisting of 3 pages. Page 1 and Page 2 each include a button that navigates to the next page. The second page (pictured below) includes 2 textboxes and the overrides for the OnNavigatedFrom and OnNavigatedTo methods listed above, which persist and retrieve the value of only the first textbox into/from the Page State Dictionary.
Figure 1
When switching between pages using the Navigate method from the NavigationService class, a new instance is created of the page defined by the Xaml file referenced in the method’s “source” parameter. This happens every time. When doing explicit navigation (eg – a Url is provided to the Navigate method), a new page instance is created. Figure 2 illustrates this concept of new page instance creation.
Figure 2
  • The “Go to Page 2″ button is used from Page 1 to Navigate to Page 2 with the code NavigationService.Navigate(new Uri(“/Page2.xaml”UriKind.Relative));
  • This first instance of Page 2 is created with its own Page State Dictionary. The user enters the phrase “User State 1″ into the first textbox and “User State 2″ into the second textbox, and following the OnNavigatedFrom code above, the value of the first textbox is put into the Page State Dictionary when the user uses the Back Button to navigate back to Page 1.
  • Now the user presses the “Go to Page 2″ button again. This causes a completely new instance of Page 2 to be created, with its own Page State Dictionary. The value placed in the previous Page 2 instance’s Page State Dictionary is not preserved, resulting in both textboxes being empty.
Conversely, using either the Back Button or the NavigationService.GoBack method to navigate back to a page in the phone’s Back-Stack will not create a new instance of the page, but will instead use the original instance (there is an important exception to this, which will be discussed momentarily.) This is illustrated in Figure 3.
Figure 3
  • The “Go to Page 3″ button is used from Page 2 to navigate to Page 3. In the OnNavigatedFrom method, the value of the first textbox is put into the Page State Dictionary.
  • The first instance of Page 3 is created. The user uses the Back Button to navigate back to Page 2.
  • The original instance of Page 2 is displayed, with the text in both textboxes still being displayed (even though only one textbox’s value was put into and retrieved from the Page State Dictionary.)
It is worth noting that there is no Forward button to complement the Back button on Windows Phone devices, and calls to the NavigationService.GoForward method will result in an exception.. This is because the current version of the Windows Phone does not maintain any “Forward Stack.”
So, if the Page State Dictionary is specific to an instance of a PhoneApplicationPage object and cannot be used for repeated explicit navigations to a specific page (as seen in Figure 1), and during navigation using GoBack or the BackButton, it has no effect on whether or not state is preserved (as seen in Figure 2), what good is it? The answer revolves around Tombstoning.
Tombstoning is the process in the Phone Application lifecycle where one application is terminated anytime another application is launched. A full treatment of Tombstoning is beyond the scoped of this discussion, but further information is available at http://msdn.microsoft.com/en-us/library/ff817008%28v=VS.92%29.aspx. The key concept to be aware of is that when an application is tombstoned, it is terminated and any in-memory state information is lost except for what was written to the State Dictionaries and any information written to disk via Isolated Storage. Likewise, an application that has been tombstoned can be reactivated when its entry in the Back Stack is reached using the phone’s Back Button (or via a Chooser action, as will be seen is a subsequent post.) The Page State Dictionary provides a mechanism for restoring a page’s state when it is re-invoked after the application has been tombstoned. This process is illustrated in Figure 4.
Figure 4
  • The “Go to Page 3″ button is used from Page 2 to Navigate to Page 3. In the OnNavigatedFrom method, the value of the first textbox is put into the Page State Dictionary (same as the previous example.)
  • The first instance of Page 3 is created. The user launches another application (via pressing the Start or Search Buttons on the Phone, etc.) This tombstones the current application.
  • The user finishes using the other application and presses the Back Button, re-activating the tombstoned application and creating a new instance of Page 3
  • The user presses the Back button to go back to Page 2. A new instance of Page 2 is created, but it does have access to the original Page State Dictionary.
  • The value of the first textbox (“User State 1″) is rehydrated from the entry in the Page State Dictionary during the OnNavigatedTo method. The data entered into the second text box is lost.
So in the end, the main reason to use the Page State Dictionary is to restore the state of the page when navigating Back to that page either immediately or at some point after the application has been tombstoned. However, if the application is tombstoned as a result of invoking a Chooser, things may be quite different, as will be seen in the follow-up to this post, which will go over the Application State Dictionary.

New Hampshire .Net (Concord) User Group Presentation Materials

I have uploaded the content from my Introduction to Windows Phone 7 Development with Silverlight talk at the New Hampshire (Concord) .Net User Group meeting last night in Concord. The content can be found here, and includes:

  • Presentation slides, which include the reference links I mentioned during the talk.
  • The sample code, broken into 2 projects. Because the Notification Services portion of the talk adds extra projects to the solution ad is a little more complex to build and launch, that portion has been broken out into its own separate zip file.

For the Notification Services portion of the demo, the web project should be launched first, followed by the phone project (since the phone app calls the web site to register its URL for receiving notifications.) If the solution is run with the web project set as the default start project, the application bits do get deployed to the phone, but the debugger is not hooked up (unless multiple startup projects are used.) If debugging of the phone app is desired, it can be achieved by right clicking on the phone project and selecting Debug / Start New Instance. Also, this time the Notification Services demo includes the Push Notification Server-Side Helper recipe.

As usual, I have “sanitized” the uploaded code content by removing my personal Bing Maps application key. For information on how to obtain your own map key, please check out the Bing Maps Developer Portal.

Many thanks to Patty Tomkins for organizing the user group and the event, the folks at NHTI for providing a great venue, Jim O’Neil from Microsoft for providing the Windows Phone swag, as well as to all of the attendees. We had some “minor technical issues” to overcome with getting the projectors set up (I need to remember to add a 10′ VGA cable to my standard presentation traveling kit), but once we hijacked another cable and got past that problem, everything went great.

New England Visual Basic Professionals Presentation Materials

I have uploaded the content from my Introduction to Windows Phone 7 Development with Silverlight talk at the New England Visual Basic Professionals meeting in Waltham on December 2. There content can be found here, and includes:

  • Presentation slides, which include the reference and event links I mentioned during the talk.
  • The sample code, broken into 2 projects. Because the Notification Services portion of the talk adds extra projects to the solution and is a little more complex to build and launch, that portion has been broken out into its own separate zip file.

For the Notification Services portion of the demo, the web project should be launched first, followed by the phone project (since the phone app calls the web site to register its URL for receiving notifications.) If the solution is run with the web project set as the default start project, the application bits do get deployed to the phone, but the debugger is not hooked up (unless multiple startup projects are used.) If debugging of the phone app is desired, it can be achieved by right-clicking on the phone project and selecting Debug / Start New Instance.

As usual, I have “sanitized” the uploaded code content by removing my personal Bing Maps application key. For information on how to obtain your own map key, please check out the Bing Maps Developer Portal

New England Silverlight Guild Presentation Materials

I have uploaded the content from my Introduction to Windows Phone 7 Development with Silverlight talk at the New England Silverlight Guild meeting in Connecticut on November 16. There content can be found here, and includes:

  • Presentation slides, which include the reference and event links I mentioned during the talk.
  • The sample code, broken into 2 projects. Because the Notification Services portion of the talk adds extra projects to the solution and is a little more complex to build and launch, that portion has been broken out into its own separate zip file.

For the Notification Services portion of the demo, the web project should be launched first, followed by the phone project (since the phone app calls the web site to register its URL for receiving notifications.) If the solution is run with the web project set as the default start project, the application bits do get deployed to the phone, but the debugger is not hooked up (unless multiple startup projects are used.) If debugging of the phone app is desired, it can be achieved by right-clicking on the phone project and selecting Debug / Start New Instance.

As usual, I have “sanitized” the uploaded code content by removing my personal Bing Maps application key. For information on how to obtain your own map key, please check out the Bing Maps Developer Portal

 

Maine Bytes User Group Presentation Materials

I have uploaded the content from my Introduction to Windows Phone 7 Development with Silverlight talk at the Maine Bytes User Group meeting on November 11. The content can be found here, and includes:

  • Presentation slides, which include the reference and event links I mentioned during the talk
  • The sample code. Because the demos were completely cumulative, only the final project is included.

There was one stumbling block during the demo, and I was able to determine what happened. When I switched to use the “pre-canned” version of the code for the State Preservation demo (Isolated Storage, PhoneApplicationService State dictionary), as that project had been previously built and shared the same project information as the previous project that had been deployed to the phone, when I built and deployed to the phone, no new bits were copied over (the project and solution didn’t think any code had been changed.) Nothing worked because there were old assemblies on the phone… had I run the code by forcing a rebuild or restarted the emulator, everything would have worked as expected.

I have “sanitized” the uploaded code content by removing my personal Bing Maps application key. For information on how to obtain your own map key, please check out the Bing Maps Developer Portal

Remote Debugging Silver Bullet

I have previously been stymied several times while trying to use Remote Debugging to troubleshoot a problem when the machines in question are not on the same domain (or when my development machine is not on any domain at all.) While this worked (apparently it still does) several years ago when I worked mostly on unmanaged code, I never could get past the issues when trying to do this with Managed Code.

Once again, John Robbins has ridden in to the rescue with an article providing guidance how to get past this very issue. His writeup can be found here. I almost can’t wait to have some server code I wrote go out to lunch so I can try this out (OK…I can wait…but now I have a new trick to try when it does…)

This solution will also probably benefit from being paired with the SysInternals ShellRunAs utility.