AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=1824&pId=-1
Introduction to XAML Browser Applications (XBAP)
page
by Nihar Ranjan Nayak
Feedback
Average Rating: 
Views (Total / Last 10 Days): 152185/ 241

Introduction

XBAP (XAML Browser Application) is a new Windows technology used for creating Rich Internet Applications.  There is always a confusion between WPF, XBAP and Silverlight. Developers get confused which one to go for while designing a project. Here I will explain all the 3 technologies with the differences and a sample XBAP application.

WPF applications are divided into two categories.

  • Standalone WPF Application
  • XAML browser applications (XBAPs)

 

XAML browser applications (XBAPs) combines features of both Web applications and rich-client applications. Like Web applications, XBAPs can be published to a Web server and launched from Internet Explorer. Like rich-client applications, XBAPs can take advantage of the capabilities of WPF. Developing XBAPs is also similar to rich-client development.

It is used for creating heavyweight .Net applications that take advantage of the full capabilities of .Net 3 Framework.

Basic differences between XBAP, WPF Standalone and Silverlight

Standalone WPF Application

WPF applications are installed on end user's machine.

Appear in Start Menu and Add/Remove Programs.

Applications can be installed via MSI or ClickOnce.

User can be offline and use the application. There is no need for Internet connection.

Newer versions of the application may not be automatically installed in user's machine.

WPF standalone applications can use WCF for communication.

Applications run in its own window as other windows applications.

XAML Browser Application(XBAP)

These type of applications are not installed in user's machine.

They do not appear in the in Start Menu or Add/Remove Programs.

Applications can be automatically deployed via ClickOnce.

Applications are hosted in the browser process.

Can be run only in IE and Firefox.

Newer versions are always installed automatically into the user's machine.

User must be online to use the application.

XBAP is Windows only. We can run the application in Windows operating system only.

XBAPs cannot use WCF.

The user machine should have .NET framework 3.0 components.

Silverlight

XBAP is IE and Firefox only. But Silverlight can run in any browser and platform.

Silverlight is used for creating rich UI web application.

User's machine don't need .NET framework.

Can be embedded in HTML markup and rendered in any browser using the silverlight plug in.

XABP has 99% features of WPF. But Silverlight is just a subset of WPF.

How to choose

WPF applications are basically for windows client applications. Silverlight and XBAP are designed for web applications. So if you are targeting for only IE and Firefox then choose XBAP. Otherwise Silverlight is the best option as it can be run in any browser. XBAPs also require .NET framework 3.0 in user's machine. So if you are creating an application for your company or intranet where each machine has the .NET framework, then go for XABP.

Architecture

WPF architecture contains all the class hierarchy and the methods of interacting with each other.

System.Object

WPF applications are exposed through managed code. So the CLR has many productive and robust development features like memory management, error handling, common type system etc. The major components are Presentation framework, Presentation Core, Common Language Runtime, Milcore, DirectX, User32, Kernel. Out of these only PresentationFramework, PresentationCore, and Milcore are the major code portions of the WPF applications. Milcore is written in unmanaged code in order to enable tight integration with DirectX. All display in WPF is done through the DirectX engine, allowing for efficient hardware and software rendering. WPF also required fine control over memory and execution. The composition engine in milcore is extremely performance sensitive, and required giving up many advantages of the CLR to gain performance.

System.Threading.DispatcherObject

Most of the WPF objects are derived from DispatcherObject, which provides basic methods dealing with concurrency and threading. WPF is based on messaging system implemented by the dispatcher.

System.Windows.DependencyObject

One of the primary architectural philosophies used in building WPF was a preference for properties over methods or events. Properties are declarative and allow you to more easily specify intent instead of action. This also supported a model driven, or data driven, system for displaying user interface content. This philosophy had the intended effect of creating more properties that you could bind to, in order to better control the behavior of an application.

In order to have more of the system driven by properties, a richer property system is needed than what the CLR provides. A simple example of this richness is change notifications. In order to enable two-way binding, you need both sides of the bind to support change notification. In order to have behavior tied to property values, you need to be notified when the property value changes. The Microsoft .NET Framework has an interface, INotifyPropertyChange, which allows an object to publish change notifications, however it is optional.

WPF provides a richer property system, derived from the DependencyObject type. The property system is truly a "dependency" property system in that it tracks dependencies between property expressions and automatically revalidates property values when dependencies change. For example, if you have a property that inherits (like FontSize), the system is automatically updated if the property changes on a parent of an element that inherits the value.

The foundation of the WPF property system is the concept of a property expression. In this first release of WPF, the property expression system is closed, and the expressions are all provided as part of the framework. Expressions are why the property system doesn’t have data binding, styling, or inheritance hard coded, but rather provided by later layers within the framework.

The property system also provides for sparse storage of property values. Because objects can have dozens (if not hundreds) of properties, and most of the values are in their default state (inherited, set by styles, etc.), not every instance of an object needs to have the full weight of every property defined on it.

The final new feature of the property system is the notion of attached properties. WPF elements are built on the principle of composition and component reuse. It is often the case that some containing element (like a Grid layout element) needs additional data on child elements to control its behavior (like the Row/Column information). Instead of associating all of these properties with every element, any object is allowed to provide property definitions for any other object. This is similar to the "expando" features of Javascript.

System.Windows.Media.Visual

The Visual class provides for building a tree of visual objects, each optionally containing drawing instructions and metadata about how to render those instructions (clipping, transformation, etc.). Visual is designed to be extremely lightweight and flexible, so most of the features have no public API exposure and rely heavily on protected callback functions.

Visual class is really the entry point to the WPF composition system. Visual class is the point of connection between these two subsystems, the managed API and the unmanaged milcore.

WPF displays data by traversing the unmanaged data structures managed by the milcore. These structures, called composition nodes, represent a hierarchical display tree with rendering instructions at each node. This tree, illustrated on the right hand side of the figure below, is only accessible through a messaging protocol.

When programming WPF, you create Visual elements, and derived types, which internally communicate to the composition tree through this messaging protocol. Each Visual in WPF may create one, none, or several composition nodes.

System.Windows.UIElement

UIElement defines the core subsystems including Layout, Input, and Events. Layout is a core concept in WPF. In many systems there is either a fixed set of layout models (HTML supports three models for layout; flow, absolute, and tables) or no model for layout (User32 really only supports absolute positioning). WPF started with the assumption that developers and designers wanted a flexible, extensible layout model, which could be driven by property values rather than imperative logic. At the UIElement level, the basic contract for layout is introduced – a two phase model with Measure and Arrange passes.

System.Windows.FrameworkElement

FrameworkElement can be looked at in two different ways. It introduces a set of policies and customizations on the subsystems introduced in lower layers of WPF. It also introduces a set of new subsystems.

The primary policy introduced by FrameworkElement is around application layout. FrameworkElement builds on the basic layout contract introduced by UIElement and adds the notion of a layout "slot" that makes it easier for layout authors to have a consistent set of property driven layout semantics.

 

 

System.Windows.Controls.Control

Control class provides a set of stock properties, Foreground, Background, Padding to name a few, which template authors can then use to customize the display of a control. The implementation of a control provides a data model and interaction model. The interaction model defines a set of commands (like Close for a window) and bindings to input gestures (like clicking the red X in the upper corner of the window). The data model provides a set of properties to either customize the interaction model or customize the display (determined by the template).

 

Creating a sample XBAP Application

Step 1

Start Visual Studio 2008. Click File -> New -> Project. Select the Windows item inside Visual C#. Then choose the WPF Browser Application template and create a project. This template is basically used to create XBAP applications.


Step 2

Inside solution explorer double click the Page1.xaml. Paste this line between the <Grid></Grid>.

<TextBlock Text="This is my first XBAP application." Background="LightGray" 
    Foreground="DarkOrchid"></TextBlock>

Then build your project.

Step 3

Next go to your Debug folder of your Application. Double click on the .XBAP file to run it. It will open in a browser window. If your default browser is not IE or FF then copy the Url from other browser window and paste it in your IE address bar. (because XBAPs run only in IE and FF) You will see the following output. If you get a “Trust Not Granted” error then you will need to disable the PopUp blocker in your browser.


Deploying a XAML Browser Application

When you build a XBAP, the Microsoft build engine (MSBuild) produces the following three files as a minimum:

An executable file. This contains the compiled code and has an .exe extension.

An application manifest. This contains metadata associated with the application and has a .manifest extension.

A deployment manifest. This file contains the information that ClickOnce uses to deploy the application and has an .xbap extension.

          We can publish the XBAPs to a web server like IIS. We do not need to install .NET Framework in the web server. But you do need to register the WPF Multipurpose Internet Mail Extensions (MIME) types and file extensions. These are some MIME types which needs to be registered.

                  

         

 

MIME Type

Extension

application/manifest

.manifest

application/x-ms-xbap

.xbap

application/octet-stream

.deploy

application/x-ms-application

.application

application/vnd.ms-xpsdocument

.xps

application/xaml+xml

.xaml

 

          To prepare your XBAP for deployment, copy the .exe and the associated manifests to your Web server. Create a hyperlink on a Web page to navigate to the deployment manifest. When the user clicks the link and navigates to the .xbap file, ClickOnce automatically handles the mechanics of downloading and launching the application.

Clearing Cached XBAPs

In some situations after rebuilding and launching your XBAP, you may find that a previous version of the XBAP is launched. This may happen, for example, when your XBAP assembly version number is static and you launch the XBAP from the command line. In this case, because the version number between the cached version (the version that was previously launched) and the new version remains the same, the new version of the XBAP is not downloaded; instead, the cached version is loaded.

In these situations, you can remove the cached version by using the Mage command (installed with the Windows SDK) from the command prompt:

Mage.exe -cc

This ensures that the latest version of your XBAP is launched, because a cached version can't be found. If you debug using Visual Studio 2005, by pressing F5, the latest version of your XBAP should be launched.

In general, you should update your assembly version number with each build.

XBAP Security Considerations

XBAPs must execute within a partial-trust security sandbox that is restricted to the Internet zone permission set. Consequently, your implementation must support the subset of WPF elements that are supported in the Internet zone

When you host the Web Browser ActiveX control (WebOC) in the Internet Explorer browser process, the following security limitations apply.

·       Internet Explorer blocks modal dialog boxes from the DHTML alert function and ActiveX controls hosted in HTML. Internet Explorer suppresses dialog boxes that originate from threads other than the active tab’s thread.

·       Hosting the WebOC control raises an exception when an XBAP is loaded cross-domain in an HTML page.

XBAP Start Time Performance

An important aspect of XBAP performance is its start time. If an XBAP is the first WPF application to load, the cold start time can be ten seconds or more. This is because the progress page is rendered by WPF, and both the CLR and WPF must be cold-started to display it.

Starting in .NET Framework 3.5 SP1, XBAP cold-start time is mitigated by displaying an unmanaged progress page early in the deployment cycle. The progress page appears almost immediately after the application is started, because it is displayed by native hosting code and rendered in HTML.

In addition, improved concurrency of the ClickOnce download sequence improves the start time by up to ten percent. After ClickOnce downloads and validates manifests, the application download starts, and the progress bar begins to update.

Conclusion

So XAML Browser Applications or XBAPs are designed for web based applications which will require .NET Framework 3.0 or later in end user's machine. Whereas WPF doesn't require the framework and its totally a windows application. Silverlight is completely for web based applications when you are targeting a number of platforms and browsers. But one common thing in all these three technologies is XAML, which is required to design the markup.

 

 


Product Spotlight
Product Spotlight 

©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-09-15 4:38:56 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search