In my previous post I announced that we’ve improved the Health & Fitness sample in our newly released HealthVault SDK. here is a bit more detail about what we changed:
· Important cache code fix. There was a bug in the previous caching code that emptied the user-data cache for each page load. This is now fixes, and the user data cache is maintained for the duration of the users session.
· Improved security checks for browser download of user charts. Code has been added to verify that if the application is running in HTTPS (as production applications do) that image download can only happen over HTTP.
· Diagnostic control added to all application pages. A Web.Config setting allows for the showing of a diagnostic control at the bottom of application pages; making it easier to understand the performance characteristics of the data cache and graph cache.
· Better sample code organization. Files are now better arranged into subdirectories for improved comprehension. Functionality is now in the following sub-directories:
Pure code files (no web UI Pages/Controls)
Contains constants, data-types and logic specific to the Health & Fitness application. (Your application will probably want to have similar directory of its own).
Contains types to parse, display, and otherwise work with health related data with heterogeneous units, e.g. Weight is commonly specified in either pounds or kilograms, and Distance for aerobic exercise is commonly a mix of yards, meters, kilometers or miles, depending on the type of exercise and local conventions. (e.g. 10k runs, 26 mile marathons, 1600 meter swims)
Contains *Manager.cs and *Item.cs classes for managing sets of health data cached locally in the web-application. Each data type has both a *Manager.cs and *Item.cs class. E.g. sets of Weight data are managed by the WeightDataManager.cs class, with each individual Weight measurement stored in an instance of a WeightDataManager.WeightDataItem.cs class.
Contains classes to manage the single most current instance of a type of health data we cache locally in our web-application. These are similar to the DataCache classes described above, but rather than mange a set of data inside a specific time-window, the classes here specifically only hold 0 or 1 data items, thus they are “singleton” rather then set managers. E.g. The CardiacProfileData_InstanceManager.cs class manages access to a single CardiacProfileData_InstanceManager.CardiacProfileItem.cs object which contains the user’s cardiac profile.
These are the core classes upon which both the DataCache and DataCache_Singletons classes are built.
Specifically of interest:
LocalCacheForHealthRecord.cs – Manages access to all of the user’s health data. It encapsulates access to all of the *Manager and *InstanceManager objects that cache a logged-in user’s health data.
LocalThingTypeDataItem.cs – The base class that every *Item class derives from. It is the abstract base class from which all cached data items derive.
LocalThingTypeDataManager.cs – The abstract base class that all *Manager classes derive from. Any class that manages sets of user health data derives from this class.
LocalThingTypeSingleInstanceManager.cs – The abstract base class that all singleton *InstanceManager classes derive from.
Contains classes that track diagnostic information useful in monitoring, debugging and improving performance. These classes allow you to track what data is being held in the cache, when a cache object was last updated, and other useful diagnostic information.
Contains classes that manage the creation, storage and serving of user specific image data (e.g. charts of the user’s heath data). Specifically of interest:
GraphManager*.cs: Manages the generation of health information graphs. E.g. GraphManagerWeight.cs manages the set of weight specific charts, GraphManagerBloodPressure.cs manages the set of blood pressure charts.
ImageManager.cs: Manages storage of, and access to, cached image files. When a GraphManager*.cs class has a graph generated for a user it calls into this class to store the image locally on the web server so that it is available when the user’s browser requests it. When the user’s web-browser requests a health graph image, this class gets called to find and serve that image.
RequestHandlerImageAccess.cs – This is the HTTP hander (specified in the web.config file) that handles the user’s browser’s requests for health graph images. These requests get matched to the user’s logged in identity and then passed into the ImageManager to serve the image.
This set of classes forms the graphing engine that produces most of the health data charts shown by the application. The main class here is GraphGenLineBarChart.cs; all the other classes are used in support of this class.
A second graphing engine; specifically this is used to draw the charts showing exercise heart-rate data (such as that collected by a sports-watch).
Contains classes that handle specific graph generation requests. Typically a GraphManager*.cs class (see DynamicImageManagement directory, above) calls into one of the GraphGen*.cs classes here. Most of these classes use the GraphEngine1 classes (above) to draw the graph.
e.g. Functions in DynamicImageManagement\GraphManagerBloodPressure.cs call into GraphGenBPSplitView.cs, which in turn uses GraphManager1\GraphGenLineBarChart.cs to generate blood-pressure graph images.
Most of the classes that interact with the HealthVault server are encapsulated in this directory. Additionally, some classes with useful support functions are also in this directory.
Of specific interest:
MSHealthAddOrModify.cs – All calls to modify existing or create new health data in HealthVault get routed through this class.
WCPageHelper.cs – All ASP.NET web pages that require the user to be logged into HealthVault derive from this class. It handles setting things up when a user logs in, or switches a record. This class also abstracts access to application-level cached vocabularies from HealthVault (e.g. lists of exercises, lists of ethnicities)
WCQueries.cs – All HealthVault queries for sets of data, or individual data items get processed by this class. When new data is needed from the HealthVault server, the DataCache classes (see above) call into data-type specific WCQueies*.cs classes (e.g. WCQueriesWeight.cs), which in turn call into WCQueries.cs to perform the server request.
Contains various helper machines that aid in working with data and generating HTML content. These classes work with local data (as opposed to the classes in HealthServerHelpers\ which interact with the HealthVault server). For example, there are classes here with helper functions for:
– Generating HTML content that targets health-articles towards specific users (ArticleSelectionHelper.cs)
– Generating HTML that displays the source name or image-logo associated with a piece of health data (BrandLogoHelperMachine.cs)
– Generating lists and parsing selected ListBox text for various editor controls (e.g. GenderHelper.cs, MedicationUsageHelper.cs)
HealthVault allows its schematized data types to have application defined extensions.
This directory contains helper classes that are called to parse or write extension data for specific HealthVault data-types.
HealthVault allows your application to define its own application specific data-types for cases where no appropriate HealthVault data-type presently exists.
This directory holds the set of application specific data-types.
Of specific interest:
HealthRecordItemCustomBase.cs – All application specific data-types derive from this class.
There are cases where a data-type has been added to the HealthVault server, but does not yet exist in the Microsoft.Health.DLL’s used by ASP.NET applications.
This directory contains the set of HealthVault types which have not yet been added to the Health Vault SDK, and for which we needed to write custom persist and parsing code.
Note: Over time as the Microsoft.Health DLL gets updated to explicitly support these new health data types, it will be possible to remove these classes and use the SDK defined classes.
Contains miscellaneous classes and interface definitions that did not fit in any of the categories above.
Of specific note:
CompositeUserProfile.cs – A high level abstraction that allows quick access to common user data (e.g. a user’s birth year or gender). This class in turn calls into the various *DataManager.cs and *InstanceManger.cs classes to get the data.
SessionInfo.cs – Encapsulates access to data the application stores in ASP.NET session state.
WebAppNavigation.cs – Contains common code used for cross page navigation. URL parameters are used throughout the application to pass information and state from one page to another. The code for generating and parsing parameters appended to browser navigation URLs is located here.
ASP.NET Web Pages/Controls
ASP.NET Pages – All the web pages in the application are located in this directory.
Of specific note:
AppMasterPage.master – This is the master-page which provides the top level look and feel for the application.
The 2 Microsoft Health DLLs are into this directory.
ASP.NET Controls – All the charts that appear on the web application’s pages are generated by these controls. (e.g. blood pressure, exercise, weight charts)
Static images – Used in some charts
The CSS style sheets used in the application.
ASP.NET Controls – The “Recommended Articles” & “Data Analysis” shown on the application’s web pages are rendered by the controls in this directory.
ASP.NET Controls – Controls that deal with date/time input and date ranges. These are typically used as parts of larger controls, e.g. tabular display controls that need date-range input.
ASP.NET Controls – Controls that provide development and testing diagnostic information, e.g. metrics on the # of items being held in the data cache.
ASP.NET Controls – Low level edit controls (e.g. TextBoxes, ListBoxes) with some value added features specific to the application’s needs. These controls are typically used as parts of larger health-data type editing controls (see next item).
ASP.NET Controls – Each health data type used in the application (e.g. Weight data, Exercise data) that can be edited by the end user has an edit control in this directory. Implementing these as controls (rather than ASP.NET pages) makes it easy to reuse them in different applications, or different parts of the same application.
ASP.NET Controls – These are used to display various different kind of error conditions to the user. They are implemented as controls so that they can be reused and supply a common look/feel throughout the application for error information.
ASP.NET Controls – Simple controls that provide a common UI for common navigation tasks.
Static images – When the application shows the branded source of the user’s health data (e.g. such as the ‘source’ of Blood Pressure data shown in a table) it looks in this directory to see if there is a partner-logo available to display. If one is found, it is displayed. If none is found, the text name of the source is displayed.
Static images – All kinds of static images used throughout the application (e.g. such as blood pressure icons that show whether a reading is in the Red, Orange, Yellow, or Green zone, or various icons and widgets shown in the application)
Static images – A few static images specific to the look and feel of this application.
ASP.NET Controls – All the application’s tabular displays are generated by controls in this directory, e.g. tables of weight, blood pressure, exercise and medication data.
ASP.NET Controls – Controls for displaying and editing various parts of the user’s health profile are here. E.g. a control for editing age/gender/ethnicity, a control for editing the user’s cardiac-profile, a control for editing Asthma profile information.