Posts Tagged 'Silverlight'

Dynamically Accessing Large Resource Files in XAML at Runtime

WPF provides ResourceDictionaries as a convenient way of adding resources like Styles to your application to be accessed when needed. However, if a non-executable resource gets very large and/or is used infrequently, resource files are a better choice than ResourceDictionairies.

With WPF applications you can incorporate any non-executable resources (including data files, images, audio, and video) into your application using a variety of schemes. You can even put XAML in a resource file so that you can download parts of your UI at runtime. However, if you’d like to avoid downloading/distributing the file until the user actually needs it, a site of origin resource file is your best choice. Site of origin files aren’t compiled into your application’s EXE or distributed with it (they’re not even copied to the location specified when you publish your application). Instead, they’re picked up at run time when your code accesses them.

Site of origin files are also a good choice in two other scenarios. First, if you have some content that is going to change frequently you can store the file on your website where you can update them as needed and let your applications pick them when they want them. Secondly, if your application is going to load different files depending on settings in the local configuration file, the identity of the local user, or any other basis for customization, you can put multiple versions of the file on your site and download them as needed.

Using site of origin files also avoids requiring your application to be granted full trust. In WPF you can often set properties (usually the Source property) on an element to a URI that points to a resource. For instance, you might use an Image element like this:

<ImageSource=http://www.phvis.com/DataFile.bmp />

However, this option requires that your application be granted full trust. Site of origin files require only partial trust.

Implementing Site of Origin Files

The first step in using a site of origin file is to add it, or smaller stand-in for it, to your project in Visual Studio. After adding the file (or its stand-in) to your application, select the file and set its Build Action to None (this prevents the file from being compiled into your application).

At run time, you can download your file with code when the file is actually needed. The first step is to create an Uri object passing the location of the file with the pack and siteoforigin prefix:

Dim sooUri As New Uri(
"pack://siteoforigin:,,,/MyGrid.xml", UriKind.Absolute)

Once you have created the Uri, you may be able to just set the Source property of the control you want to use your file to the URI. This sets the Source property on a Frame, for instance (and assumes that the xml file downloaded in the previous example contained valid XAML):

Me.Frame1.Source = sooUri

However, this approach forces the framework to do any type casting or conversions for you. If you’re willing to write a little more code, you can take control of the process and ensure that the conversion is done the way you want. The first step is to create a StremResourceInfo object by calling the Application object’s GetRemoteStream method, passing your Uri:

Dim info As StreamResourceInfo = Application.GetRemoteStream(soouri)

Your next step is create a read object object to process the file. You call the reader’s LoadAsync method, passing the stream property of your StreamResourceInfo object. You’ll need to cast the output of this method to the right type. Assuming that that I’m downloading a XAML file containing a Grid, I’d need to create a XamlReader and cast the output as Page, like this:

Dim xrdr AsNewSystem.Windows.Markup.XamlReader() 
Dim grd As Grid = CType(reader.LoadAsync(info.Stream), Page)
Me.Frame1.Content = grd 

After publishing your application, it’s just a matter of dropping the file into the folder with the setup.exe file and your application will download it when your code executes.

Peter Vogel

HTML5, .NET, and Silverlight: Why So Serious?

Why all the anxiety about Microsoft’s support for JavaScript+HTML5?

In a perfect world, there shouldn’t be any fuss. HTML5 is the latest iteration of the HTML specification and builds into HTML a ton of goodies that developers have had to either shoehorn in with other tools (e.g. Flash), implement by misusing other tools (using CSS classes to tag similar items), or just give up on doing (everything else). Obviously, Microsoft is obliged to implement the standard in Internet Explorer just to stay competitive with the other browsers. And, as the HTML5 spec gets implemented in various browsers, it seems reasonable that ASP.NET/MVC developers are going to want to use those features that turn out to be genuinely useful. So Microsoft is also obliged to support those features in Visual Studio and ASP.NET/MVC.

The issue is Windows 8. Windows 8 gives HTML+JavaScript developers the ability to create applications that have equal standing in Windows 8 with applications built using other development tools (e.g. with Silverlight and XAML based technologies). To provide further integration with .NET, Microsoft also offers the ability to compile .NET libraries into a new file format that allows the objects in those libraries to be called from JavaScript code. On the face of it, this doesn’t seem like major a step (and was probably easier to do  than getting C++ and Visual Basic applications to interoperate in Windows 3.x and COM).

Of course, this support may be a waste of Microsoft’s time—nobody may want to build Windows 8 applications with HTML5+JavaScript (remember Active Desktop? How about Microsoft Bob?). But the company has money in the bank and, who knows?  This initiative could be as important as Microsoft Binder Windows Media Player.

It’s Silverlight developers that are really concerned. In Silverlight, you can do much more, in much less time than you ever could in any version of HTML+ JavaScript—and do it more reliably, to boot. And, like an HTML app, you can deliver Silverlight applications over the Internet to (almost) anyone who has a browser. Unfortunately, Microsoft has announced that Silverlight won’t run on every platform in the known universe (and, we assume, HTML5+JavaScript applications will). That wouldn’t be an astounding announcement…except that the platforms that Microsoft won’t try to get Silverlight to run on are both the hot thing right now and the presumptive future of computing: Smartphones and tablets.

It’s hard to imagine that Microsoft could get Silverlight to run on either Android or iOS (heck, iOS won’t even run Flash). What bothers Silverlight developers is that Microsoft isn’t even going to try. The only potential good news is that Windows Phone on Nokia could become a real player and Windows 8 could show up on some tablet. It says something about the faith that Silverlight developers have in those platforms that they don’t find much consolation in that.

But their real worry is that, answering the siren call of HTML5, Microsoft is actually planning to give up on Silverlight altogether in favour of HTML5+JavaScript. That would leave Silverlight developers in the backwaters of the brave new world (i.e. stuck on desktops and laptops) where they’ll gradually drift into the Swamp of Obsolescent Technologies (right next to the Island of Misfit Toys)**. Some Silverlight developers have gone so far as to suggest that Microsoft should abandon all of ASP.NET and make Silverlight the sole .NET tool for delivering applications through a browser.

Personally, I don’t think any of those things are going to happen. I don’t see Silverlight going away. Developers are so much more productive with Silverlight than they are in HTML+JavaScript that Silverlight will remain a popular choice for both desktop and intranet development…or any development not targeted at smartphones and tablets. And HTML+JavaScript will remain the most popular choice for developers who are interested in reaching everyone but don’t want to rebuild the same application in four different proprietary development tools. It’s worthwhile to note that I think almost as many developers attend Learning Tree’s WPF and Silverlight course as come to the ASP.NET WebForms course that I wrote for Learning Tree.

But, on the other hand, I am going to learn HTML5 (and be keenly interested in seeing if Learning Tree’s HTML5 course attracts lots of developers). I’ll also be brush uping my JavaScript skills. I’d like to see one of my apps running on an iOS, Android or BlackBerry phone. That would be cool.

Peter Vogel

**over-extended, gratuitous metaphor

Silverlight or HTML 5?

I was teaching Learning Tree course 975: Windows® Presentation Foundation (WPF) and Silverlight Introduction a couple weeks ago and a student asked which was better, Silverlight or HTML 5. I program with both, so let me give you a few reasons why each is better than the other.

Reasons why HTML 5 is better than Silverlight

It works in iPhones and iPads. So far, Apple has decided the best route to open standards is by being a closed platform. They don’t support applications that require virtual machines. This includes Flash, Java and Silverlight. Obviously, support for these devices is really important. If you want to write an application for iPhone or iPad you have two choices: use their native SDK and Objective-C or HTML 5.

If you currently have a Web application, moving to HTML 5 is straightforward. Essentially, HTML 5 consists of a number of new HTML elements and attributes, new JavaScript libraries and an update to CSS. Over time, you can add new features to your Web applications, and you are not forced to rewrite anything.

Reasons why Silverlight is better than HTML 5

From a practical point of view you can only use the great new features of HTML 5 on a closed system like the iPhone. When you write a Web application for iPhone you only have to support one browser, Mobile Safari. That can’t be said for any other computer. If you’re targeting Windows, Mac and/or Linux users, you can’t depend on a specific browser. Browser support for HTML 5 is inconsistent at best, and non-existent in older browsers. Silverlight by comparison works on every modern platform and in any browser (well, except the iPhone).

Silverlight development is proceeding at a blistering pace. Silverlight 5 is now out in beta. There are an amazing set of controls and features in Silverlight. Take a look at this link, http://www.silverlight.net/content/samples/sl3/toolkitcontrolsamples/run/default.html. Because Microsoft is in charge of everything, they can move really fast, and they are. By comparison, HTML 5 is stuck in a standards committee run by the W3C. At this time, the release date for the standard is 2014 (which means there never will be a standard for HTML 5). By then, Silverlight might be in version 10.

In Silverlight, you program in C# or Visual Basic, rather than JavaScript. Also, Silverlight programming is done using Microsoft Visual Studio or Expression Blend. Both of which are great development tools. HTML 5 support within development tools is not as advanced, although I would expect significant support for HTML 5 in the next release of Visual Studio and ASP.NET.

Silverlight works on Windows Phone 7 (just kidding).

Summary

There are reason to use both HTML 5 and Silverlight. To learn more about HTML 5 come to Learning Tree course 2320: HTML5: Next Generation Web Development. If you want to learn more about Silverlight come to Learning Tree course 975: Windows® Presentation Foundation (WPF) and Silverlight Introduction

Doug Rehnstrom


Learning Tree International

.NET & Visual Studio Courses

Learning Tree offers over 210 IT training and Management courses, including a full curriculum of .NET training courses.

Free White Papers

Questions on current IT or Management topics? Access our Complete Online Resource Library of over 65 White Papers, Articles and Podcasts

Enter your email address to subscribe to this blog and receive notifications of new posts by e-mail.

Join 29 other subscribers
Follow Learning Tree on Twitter

Archives

Do you need a customized .NET training solution delivered at your facility?

Last year Learning Tree held nearly 2,500 on-site training events worldwide. To find out more about hosting one at your location, click here for a free consultation.
Live, online training