Even before I do my HIMSS post I felt compelled to talk about the shiny things from Mix 2010.
Windows Phone 7 Series Developer Studio – I love the free tools provided to develop for Windows Phone. Love the fact that Silverlight and XNA studio are very thoughtfully and seamlessly working with-in Visual Studio Express. The developer studio is lean and performant, its great to see the tool tips for Pixel widths right in the design surface. I was able to write a simple Health app in about 10 mins, the Phones are not out yet but the
Open Data Protocol : Very interesting competition to GData :). OData – http://www.odata.org/ is a combination of AtomPub with data-typing and querying conventions. OData is supported out of the box by Windows Azure services, and Netflix launch an API powered by OData – http://odata.netflix.com/Catalog/. It will be great to learn more about batching and syncing aspects of this protocol (Interestingly Microsoft Sync Platform also launched an asymmetric syncing capability).
A very interesting presentation of building your own MVVM framework – I love the use of Continuations and a programming model where the framework takes care of concurrency and events! The presenter is author of Caliburn – http://www.codeplex.com/caliburn.
HealthVault SDK 1.0 introduces an interesting capability by which an HealthVault application can read their application certificate from a file. Eric has some details about this on his blog.
I’m going to describe how this capability of reading an application’s certificates from the file store could be used to run HealthVault application on Windows Azure. Here are the steps to get a simple HealthVault application (which I call HelloHV) running on Windows Azure:
Configure and create an HealthVault application using the application manager utility in HealthVault SDK. Make sure you set the Action-Url to http://<yourapp>.cloudapp.net/Redirect.aspx using the Application Configuration Center.
Copy the Redirect.aspx & Redirect.cs from HealthVault samples (HelloWorld in HealthVault SDK) in to your application and add reference to HealthVault assemblies (you can find them in C:Program FilesMicrosoft HealthVaultSDKDotNetAssemblies)
Add the HealthVault related config settings to your WebRole’s Web.Config, the easiest way to do this would be copy the relevant key(s) from a sample in HealthVault SDK. Here is an illustration :
<add key="ApplicationId" value="01e21bd1-cb13-40d6-8f01-596286827d6d"/>
<add key="ShellUrl" value="https://account.healthvault-ppe.com/"/>
<add key="HealthServiceUrl" value="https://platform.healthvault-ppe.com/platform/"/>
<!-- when we call the SignOut() method on HealthServicePage,
it redirects us to the page below -->
<!--<add key="NonProductionActionUrlRedirectOverride" value="Redirect.aspx" />-->
<!-- The redirect page (specified above) uses these keys below to redirect to different
pages based on the response from the shell -->
<add key="WCPage_ActionHome" value="default.aspx"/>
<add key="WCPage_ActionAppAuthSuccess" value="HelloHV.aspx"/>
While testing on your local machine uncomment the following line in the Web.Config, this will allow HealthVault to communicate with your local machine. However make sure that this is commented when you publish the application. Alternatively the following key can also be stored in UserApplicationConfigs.xml, if you maintain one for your development.
Gotacha1: Windows Azure changes the port numbers for your application so its hard to make it work without using the action-url configured for your application in Application Configuration Center.
In your Default HealthVault Page Make sure you read the certificate for your application from a local file (you can also use Azure Storage).
Gotacha2: HealthVault SDK expects the ApplicationCertificateFileName to be absolute filename, this is impossible to determine for a cloud system like Azure. However we can get the absolute path by changing the value of the key at run-time.
Hit Run and see your Hello HealthVault application in action!!
Now the show time:
Check out a simple (HelloHV application) running on Windows Azure here.
The associated code for this application is shared here.
Remember to switch to SSL and secure your application certificate (using password or Azure Storage) before you consider taking an application running on Windows Azure live as a production HealthVault application.
The HealthServiceActionPage gives you a very nice mechanism by which you can declaratively define pages handling various HealthVault shell targets. However, folks frequently run in to situation where they need more dynamic way of redirecting and handling shell targets. A simple scenario is if you want to users to come back to the same URL they clicked after being authorized by healthvault shell, e.g. User clicks and returns to https://www.healthapp.com/username/stats instead of going to the default home https://www.healthapp.com/username/.
Here is a code snippet which illustrates how to extend the HealthServiceActionPage:
public partial class Redirect : Microsoft.Health.Web.HealthServiceActionPage
//We don't want this page to require log on because when we sign out,
//we still want this page to read the WCPage_ActionSignOut key in the
protected override bool LogOnRequired
public const String ActionQueryStringValue = "actionqs";
public const String DefaultURL = "http://www.healthapp.com/username";
protected override void OnActionApplicationAuthorizationSuccessful(string action,
string url = Request.QueryString[ActionQueryStringValue];
// TODO: Validate that the URL is from home domain
if (url != null)
targetLocation = url;
targetLocation = DefaultURL;
// we assume that the query string startswith '?'
fullTargetLocation = targetLocation + actionQueryString;
Recently I ran in a bug in our AHA application on IE 6. Coming to the terms with testing across multiple browsers is a painful realization of the evils of web development. I tried several ways by which i can install IE 6 on my Vista machine, including tricky thing like DLL redirection. But this is way too painful – however I stumbled on a sweet way of doing application compatibility tests – virtual pc!!
Here is the cook-book way to get different version of IE for compatibility tests – 1. Deploy your application on a staging server 2. Install Virtual PC 2007 (it works on Vista) 3. Get the IE testing images from here.
One downside of this approach is that you cannot step into and debug you application because virtual pc is a painful to configure for running on your corporate LAN :(.