Essential XAML : Design, Thoughts and Ideas

UI Virtualization vs. Data Virtualization (Part 1)

Tomer Shamam — Mon, 07 Sep 2009 04:42:00 GMT

Being an LOB, composite applications infrastructure junky lately, I’ve been working around with several data-binding models and mechanisms to bind the data with the view, in a very efficient way of course. Sometime it was easy, and sometime it was not! I have had to find several workarounds to overcome both architectural and performance issues.

In this post I would like to concentrate on Data Virtualization, and to compare it with UI Virtualization, which are very similar, yet different aspects of the same problem.

After reading this post you'll have an idea of what is Data Virtualization compared to UI Virtualization, and what it is good for.

UI Virtualization

To understand what UI Virtualization is, lets say that you want to display a HUGE amount of data entries in a WPF DataGrid, all at once. In such case, trying to bind a simple WPF DataGrid with, lets say, 100,000 or more items, you’ll have to wait one or two seconds for the initial binding.

public partial class Window1 : Window

{

public Window1()

{

var hugeCollection = new HugeCollection();

DataContext = hugeCollection;

InitializeComponent();

}

<Window ...>
    <Grid>
        <tk:DataGrid ItemsSource="{Binding}" />
    </Grid>
</Window>

Well its really nothing!

Now lets change a little flag on the data grid.

<tk:DataGrid ItemsSource="{Binding}" VirtualizingStackPanel.IsVirtualizing="False" />

Now, before you run this app, if you use a lap-top (like me… ;), connect it to an AC power adapter first. Trust me, your laptop will need that.

As you can see, the CPU stuck on 100% and it takes eternity to see the data (I just had to kill the process).

What’s wrong? It’s only a little flag: VirtualizingStackPanel.IsVirtualizing="False".

Well, it’s indeed a little flag that makes a big difference. If this flag is true (which is the default) it instructs the VirtualizingStackPanel (which is the default layout panel in a DataGrid, ListView, ListBox and other controls) to use UI virtualization. Means: don’t create data grid rows that are not visible to the user (in other words, are not in view). So this gives you a clue for what happened when we turned off this flag. We told VisrtualizingStackPanel not to use UI Virtualization, hence the DataGrid control tried to create and layout 100,000 rows! And this is a CPU killer as you saw.

Data Virtualization

WPF internally implements UI Virtualization and it’s great. In the previous case, UI Virtualization is just fine. We’ve got 100,000 items loaded in memory, and all we’ve had to do is to bound them with the DataGrid.

But what if each entry takes more than 1MB?

100,000 * 1MB = 97GB – Huston, we have a problem!

Well, the fast answer of course would be: Don’t load all items at once, instead use chunks. And this is exactly what Data Virtualization is!

Data Virtualization implementation raises several problems, and there is no out-of-the-box solution for Data Virtualization in WPF.

Well, first problem is: How do you fake scrollbars, so the user will think that it has all the data, and will be able to scroll?

Second problem: How do you filter, sort, group data that doesn’t exist?

Third problem: How do you search data (like this search) that doesn’t exist?

These are all tough questions.

So what do you think? Do you have an easy way or acceptable solution to solve this problem?

Next post I’ll introduce a unique solution, but till then I’ll be very glad to hear your opinion on that.

10 Reasons to Love XAML

Tomer Shamam — Sat, 22 Dec 2007 05:54:14 GMT

Many of my customers and students ask me:

What is XAML good for? Why do I have to write XAML if I can write WPF with code?

So I decided to write a post about it, sorted by the most important to the less essential.

1. It’s the Designer best friend

WPF is not just about another UI platform, it’s also a methodology. It provides new tools and concepts for creating a modern presentation layer. Programmers write code, but when it comes to drawing…, OMG!

To overcome this problem, a new member is introduced: a Designer. Designers usually are not developers, hence for, if, class, abstract, etc are all buzzwords for them. For a designer to feel at home, she has to work with familiar tools such as Adobe Illustrator, Expression Blend and Expression Design. Also she can read and write HTML and XML. Hence XAML is the ultimate markup for integrating the talents of both the Developer and Designer.

Express every visual aspect with XAML (or at least as much as you can) so the designer will be able to apply makeup on it.

2. It separates design from code

You may agree that it is a good design principle to separate the UI design from the code behind. This way it will be easy to change, share and replace the UI. Separating them further with two different languages provides a higher level of decoupling.

Developer write code with C#/VB.NET where Designer design UI with XAML.

3. It is toolable

Visual Studio is the best development environment ever. It provides so many tools for building projects, edit and compile files. But is it really necessary that Adobe Illustrator or Expression Design will do the same as it comes to WPF? Do they have to compile or generate C# or VB.NET code?

XAML is the best option for an application such as described above for exporting 2D and 3D Vector Graphics and Animation. It is more reasonable to export graphics as XAML, without dealing with C#/VB.NET, assemblies, code generation and other coding stuff.

XAML is XML so you can also write export plug-ins for other applications running on Linux or other operating systems.

4. It’s more securable than IL

XAML usually ends up with BAML, and code usually ends up with IL.

IL imposes a security risk where BAML is not!

5. It's hierarchical

Did you ever tried to initialize a hierarchical data such as Tree or data types based on the Composite Pattern within C#? I did that more than once, and each time I had a migraine.

Neither C# nor VB.NET is hierarchical language. Usually a programming language is flat, hence it is hard to deal with hierarchical data within code.

Because the XML nature of XAML, it is the perfect tool for creating and manipulating hierarchical data. WPF is hierarchical!

6. It can be easily parsed, serialized and desirialized

I love C#, but when it comes to parsing I better leave this painful job to the compiler team.

XAML is XML, it can be easily parsed serialized and desirialized. So in this case tools like XmlReader, XmlDocument, XamlReader and XamlWriter are my favorites.

7. It can be loose

Many talents UI developers use XML to describe dynamic menus, toolbars, commands, etc. The absurd is that the code for reading this XML at runtime and turning it into objects is written again and again.

Use loose XAML so you will never have to write this code again. It is perfect for this situation.

8. It’s more readable than code

When it comes to reading and understanding the structure of a UI, XAML is more readable than code.

Readable is a matter of taste, so I will leave it for Leo from The Matrix to decide.

9. It’s shorter than code

Uri uri = new Uri(@“Images\Photo.png”, UriKind.Relative);

BitmapSource bitmap = new BitmapSource(uri);

Image image = new Image();

Image.Source = bitmap;

Button button = new Button();

button.Content = image;

</Button>

Who’s shorter?

10. It’s common

Try to Google “WPF”…

Hello…, is there anybody out there? C#? VB.NET? Helloooooo!?