MSDN Magazine - February 2009 - (Page 31)

DINO ESPOSITO Cutting EdgE Managing Dynamic Content Delivery In Silverlight, Part 2 Last month I discussed how to serve a Silverlight application some dynamically generated content at startup and even in an on-demand scenario. Many examples exist out there to show you how to use the WebClient class and its asynchronous call model to download a URL-based resource. In particular, I focused on what it takes to download a XAP package that includes XAML and managed code (see the January 2009 installment of Cutting Edge at msdn.microsoft.com/magazine/dd315412). The basic idea is that you download a zipped stream and then extract any assembly you need. Next, you instantiate any class you need that is contained in the assembly. The class is a XAML user control—an entire piece of a XAML visual tree— that you can then append to any placeholders in the current XAML document object model (DOM). To the browser, any downloaded XAP resources are totally indistinguishable from any other type of resource. Hence, the browser caches a XAP package just as any other downloaded resource. This built-in mechanism offers a first level of optimization that saves you repeated round-trips to get the same package over and over again. The WebClient class—the core of the downloader component discussed in last month’s column—is based on the browser’s connectivity engine and doesn’t download resources available locally and not expired yet. At the end of the day, you have a downloader component to defer the loading of any external packages you may need. In addition, you also have free caching capabilities for any dynamically downloaded resources. Among other things, you might like to add a permanent local cache of packages that is also able to deal with dynamic changes to the visual tree. Let’s see how to achieve this. The ASP .NET Cache allows you to cache data and give each cached item its own expiration policy. The ASP.NET Cache, in fact, allows you to cache data and give each cached item its own expiration policy—based on file changes, date/time, or even changes to other cached items. A similar engine doesn’t exist in Silverlight 2, but large, dynamic, and highly customizable applications would gain significant benefits from it. The second aspect of standard Silverlight resource caching that you might want to change regards the exposure of your packages to the user’s activity. In other words, any XAP package saved in the browser’s cache is at the mercy of the user. If the user clears the cache acting on the browser’s interface, all of your XAP packages will be inevitably lost. An application-managed permanent cache addresses both issues. XAP packages stored in this permanent cache would not be affected by the user clearing the browser’s cache. To permanently store Silverlight XAP packages, you need to gain access to the local file system. For security reasons, Silverlight doesn’t let applications access the entire local file system. However, the Isolated Storage API is here to help. For more on Silverlight security, see “CLR Inside Out: Security in Silverlight 2” (msdn.microsoft.com/magazine/cc765416). Foundations of Isolated Storage Motivation for a Permanent Cache When it comes to dynamic Silverlight content, there are two main aspects over which you might want to gain some more control. The first is the expiration policy of the downloaded content. You might want to control exactly when a given package expires and needs to be downloaded again. Furthermore, you might want to tie the expiration to some external event such as a particular user action or changes to other cached resources. If you know how the ASP.NET Cache works, you know what I mean. Isolated storage was not specifically created for Silverlight. Isolated storage has been part of the Microsoft .NET Framework since version 1.0. Aimed at partially trusted applications, isolated storage enables such apps to store data on the local computer in full respect of any ongoing security policy. A classic fully trusted .NET application probably has no need to ever go through the isolated storage layer to save its own data, but for a partially trusted application, isolated storage is the only option for saving data on the client. From a Silverlight perspective, isolated storage is a powerful tool and the only possible way to persist relatively large chunks of data in a cross-browser manner and without any of the restrictions that affect, for example, HTTP cookies. It is important to understand this point: in Silverlight, isolated storage is the only possibility you Send your questions and comments for Dino to cutting@microsoft.com. Code download at code.msdn.microsoft.com/mag200902Cutting. February 2009 31 http://msdn.microsoft.com/magazine/dd315412 http://msdn.microsoft.com/magazine/cc765416 http://code.msdn.microsoft.com/mag200902Cutting

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.