Silverlight Tutorial

Accessing Data Using Silverlight

Storing Data in Code

When working with data programmatically, data is typically stored in memory for later reference, while other operations are carried out, or while the data stored in memory is manipulated. Data may be entered by a user, retrieved from a data source, or created programmatically.

Variables

The most basic means of storing data in memory is through the use of variables. All programming languages support some form of variables. A variable is a named location in memory used to store data. The specifics of how data is stored and managed in memory is particular to a programming language. Strongly-typed programming languages are very strict about what type of data can be stored in a variable. Weakly-typed programming languages are not strict about what type of data can be stored in a variable. Strongly-typed programming languages are generally more efficient than weakly-typed programming languages.

Silverlight may be coded using several languages. Some of the languages used in Silverlight, such as JavaScript, are weakly-typed, while others, such as C#, are strongly-typed. A developer must thoroughly understand how to work with variables in the language that they choose for working with Silverlight. The code snippet below illustrates declaration and initialization of a simple integer type variable in C# named x.

// simple variable. int x = 1;

Collections

Most programming languages support not only storing a single piece of data in a named location in memory but also support storing multiple pieces of data in a named location in memory. A collection is a named location in memory, similar to a variable, that is structured for storing multiple pieces of data. Depending upon the programming language used, multiple types of collections may be supported. For example, C# supports simple arrays, ArrayLists, Stacks, Queues, and HashTables. Each type of collection supported is structured for storing and retrieving data in a different fashion.

Collections are located in the System.Collections namespace. The code snippet below illustrates declaration and initialization of a standard string array named customerNames.

// store customer information in an ArrayList. string[] 
        customerNames = new string[3]; customerNames[0] = "Shannon Horn"; 
        customerNames[1] = "Benny Madrid"; customerNames[2] = "Edwin Dewees";

Generics

Collections are versatile and simplify data storage in code by making it easier to store and transport multiple data items and objects. However, standard collections have some drawbacks as well. A standard collection, including an ArrayList, Stack, Queue, and HashTable, stores data internally as a simple object. By storing data as a simple object, a standard collection can be used to store any type of data. In a nutshell, in C#, a standard collection is a weakly-typed construct that exists in a strongly-typed language. The internal storage design of a standard collection affects performance and type safety negatively.

When a data item is stored in a standard collection, it must be converted to a simple object type. When a data item stored in a standard collection is removed from the collection, it must be converted from a simple object type to the destination type. The process of converting data to and from a simple object degrades performance. Additionally, a simple object can be converted to any more complex type. However, there is no guarantee that the data stored as a simple object will be correctly represented when removed from the standard collection and converted to a more complex type. For example, a complex object that represents data about a customer may be stored in a collection and then removed from the collection and converted to a string. The code written to perform the operation should compile but will, more than likely, cause errors to occur at runtime. hence, type safety is lost.

In the .NET Framework, generic collections are located in the System.Collections.Generic namespace. A generic collection is a strongly-typed collection and requires that the data type to be used for storage be specified at the time the collection is instantiated.

// a generic collection for storing customer names as 
        strings. List<string> customerNames = new List<string>(3); 
        customerNames.Add("Shannon Horn"); customerNames.Add("Benny Madrid"); 
        customerNames.Add("Edwin Dewees");

In the code snippet above, the customerNames generic collection will only store string values however the collection could be configured to store and manage any valid .NET type.

Working with XML

The Extensible Markup Language (XML) was released by the World Wide Web Consortium (W3C - http://www.w3.org) in 1999 as a standardized means of storing and transporting data over the Web. XML has proliferated Web development technologies and virtually all software development platforms support some form of XML interaction. The .NET Framework contains a gamut of classes for working with XML data in the System.Xml namespace.

Silverlight contains a subset of XML functionality in the System.Xml namespace. XML data can be read using the XmlReader class and XML data can be written using the XmlWriter class. Additionally, Silverlight includes a class used to specify configuration settings to be used when writing XML data, the XmlWriterSettings class. If configuration settings are not specified using the XmlWriterSettings class, default configuration settings are used. In the code listing below, the XmlReader class, the XmlWriter class, and the XmlWriterSettings class are used to read in a well-formed XML string, parse it, and write the contents of it to a TextBlock.

using System; using System.Collections.Generic; using 
        System.Linq; using System.Net; using System.Windows; using 
        System.Windows.Controls; using System.Windows.Documents; using 
        System.Windows.Input; using System.Windows.Media; using 
        System.Windows.Media.Animation; using System.Windows.Shapes; using System.Xml; 
        using System.Text; using System.IO; namespace ADXmlReader { public partial class 
        Page : UserControl { public Page() { InitializeComponent(); } private void 
        UserControl_Loaded(object sender, RoutedEventArgs e) { // store names as XML. 
        string names = "<?xml version='1.0' encoding='utf-8' ?><Names><Name>Shannon 
        Horn</Name><Name>Benny Madrid</Name><Name>Edwin Dewees</Name></Names>"; // 
        create a reader. XmlReader reader = XmlReader.Create(new StringReader(names)); 
        XmlWriterSettings settings = new XmlWriterSettings(); settings.Indent = true; 
        settings.ConformanceLevel = ConformanceLevel.Auto; StringBuilder output = new 
        StringBuilder(); XmlWriter writer = XmlWriter.Create(output, settings); // 
        display the names. while (reader.Read()) { if (reader.NodeType == 
        XmlNodeType.Text) { writer.WriteString(reader.Value + Environment.NewLine); } } 
        reader.Close(); writer.Close(); tbNames.Text = output.ToString(); } } }

The results of the code listing above are shown in the figure below.

Language Integrated Query (LINQ)

A major addition to the .NET Framework in version 3.5 is Language Integrated Query (LINQ). Most seasoned developers have mastered or are adequately familiar with the Structured Query Language (SQL). SQL is used to query relational database data. However, in many cases, SQL queries that pull data from a relational database schema are abstracted away from business logic and middle-tier code.

Data may also be stored in formats other than a relational database such as an XML file or a consumed Web service. In each data storage scenario, typically, a specialized language is used to retrieve and query the contained data. Furthermore, data is generally represented at the business logic and code level through objects, arrays, and collections. Developers regularly have to search these constructs by using tailor-made loops.

Many programmers have long requested a language for querying data stored in programming constructs and object oriented mechanisms. SQL is a stable and well-entrenched industry standard. It would be an insurmountable task to attempt to extend SQL so that it could be used to query programming constructs and other data sources. However, Microsoft was determined to make things easier for programmers by creating a standard for querying data stored in multiple data storage mechanisms and coding constructs. The result of their efforts was a new query language that targets data stored in objects and collections, Language Integrated Query (LINQ). LINQ was also extended to be able to query relational data stored in databases, XML data, and other data sources. However, data queried by using LINQ must be stored as objects. If data is queried from a relational data source using LINQ, it must first be represented using an object model. (see footnote)

LINQ is capable of querying any object programmatically that implements the IEnumerable interface. LINQ will present an entirely new programming paradigm to experienced .NET developers but the new functionality and benefits thereof should be quickly enjoyed and adapted by most. To summarize, the primary benefits of using LINQ are a single, consistent language for querying data across any type of data source and a means of doing so that is type safe and supported by the most popular .NET Framework programming languages.

LINQ has grown into an extensive query language. Additionally, in order to make LINQ relevant and a valid solution into the future, Microsoft designed LINQ to be extensible so that it can be extended by Microsoft or third party vendors to support additional data sources. Comprehensive coverage of LINQ is beyond the scope of this course. However, as an example, we will create a simple LINQ query example here using Silverlight. Silverlight supports LINQ using classes in the System.Linq namespace.

The first step in working with LINQ is to identify a data source. In the example created here, we store a list of names in a simple string array. The second step in working with LINQ is to create the LINQ query. A LINQ query uses very similar concepts and vocabulary as an SQL query, however the clauses are presented in a different order. Finally, the third step in working with LINQ is to execute the query. A LINQ query is executed using a foreach loop in C#. The code snippet below illustrates a simple LINQ query against a list of names in a string array. The LINQ query below uses the where clause to filter out all names except those that begin with the letter "E".

// obtain the data source. // list of names. string[] 
        namesList = new string[3] { "Shannon Horn","Benny Madrid","Edwin Dewees"}; // 
        create the query. var names = from name in namesList where name.Substring(0, 1) 
        == "E" select name; // execute the query. foreach (string name in names) { 
        tbOutput.Text = name; }

The results of the code snippet above are shown in the figure below.

For more information about Language Integrated Query (LINQ), visit the MSDN article entitled Language Integrated Query (LINQ) located at http://msdn.microsoft.com/en-us/library/bb397926.aspx.

Isolated Storage

Due to the security constraints placed upon a Silverlight application (the "sandbox" that it operates in), a Silverlight application cannot write directly to or read directly from the file system on the client's machine. In an effort to allow developers to store some data local to the client, Microsoft designed Silverlight to read data from and write data to a virtual file system called Isolated Storage. Isolated storage is stored inside a User's Application Data directory:

Location of Isolated Storage in Vista

C:\Users\AppData\LocalLow\Microsoft\Silverlight\is

Location of Isolated Storage in Windows XP

C:\Documents and Settings\Local Settings\Application Data\Microsoft\Silverlight\is

Silverlight isolated storage is currently limited to a 100 KB capacity and the classes used to work with isolated storage are located in the System.IO.IsolatedStorage namespace. Isolated Storage is Non-Volatile, and is not cleared by actions such as when the user clears the browser cache or deletes cookies. The code snippet below illustrates saving a user's login credentials to isolated storage in a file named UserCredentials.txt.

// remember the user's credentials for next time. if 
        (chkRememberMe.IsChecked == true) { using (IsolatedStorageFile isoStore = 
        IsolatedStorageFile.GetUserStoreForApplication()) { using 
        (IsolatedStorageFileStream isoStream = new 
        IsolatedStorageFileStream("UserCredentials.txt", FileMode.Create, isoStore)) { 
        using (StreamWriter writer = new StreamWriter(isoStream)) { 
        writer.Write(user.UserName + "|" + user.PasswordHash); } } } }

The code snippet above illustrates using the IsolatedStorageFile class and the IsolatedStorageFileStream class to work with isolated storage. The code snippet below illustrates using the same classes to determine if the UserCredentials.txt file exists in isolated storage and, if it does exist, reads the contents of the file.

// determine if the user's credentials exist in isolated 
        storage. using (IsolatedStorageFile isoStore = 
        IsolatedStorageFile.GetUserStoreForApplication()) { using 
        (IsolatedStorageFileStream isoStream = new 
        IsolatedStorageFileStream("UserCredentials.txt", FileMode.Open, isoStore)) { 
        using (StreamReader reader = new StreamReader(isoStream)) { // read the 
        credentials. string[] sb = reader.ReadLine().Split('|'); // do we have 
        credentials? if (sb.Length > 0) { // if the credentials exist, parse them out 
        and authenticate them. user.UserName = sb[0]; user.Password = sb[1]; // 
        authenticate. svc.AuthenticateUserAsync(user.UserName, user.Password); } } } }

Data Binding

Much of a database oriented application involves reading data from a database and presenting that data to the user. One way to handle filling User Interface elements with data from a database is to simply assign values through code. The code snippet below shows how this might be done...

// assume we have an "Athlete" class as follows: public class 
        AthleteDisplayInfo { public int AthleteId { get; set; } public string FirstName 
        {get; set;} public string LastName { get; set; } } // we then retrieve an 
        athlete from the database AthleteDisplayInfo athlete = e.Result; // we can then 
        fill UI elements, such as textboxes txtFirstName.Text = athlete.FirstName; 
        txtLastName.Text = athlete.LastName; // and also get back the values after the 
        user updates... athlete.FirstName = txtFirstName.Text; athlete.LastName = 
        txtLastName.Text;

The method shown above is quite adequate for filling UI elements with data values, but it does not allow for separation of User Interface from Business Logic Classes. Without separating our user interface from our business logic code, it will be more difficult to test the application, and have teams of designers and developers work cooperatively on the same project.

This is where data binding comes in. Using data binding, we can declaratively assign values to UI elements instead of using code. Furthermore, the data binding will automatically synchronize changes to the data source to the UI elements.To implement data binding, we use a special syntax in XAML, inside any attribute value: "{Binding PropertyName, Mode=OneWay}" - where "PropertyName" is the property of a data source class, and Mode is either OneTime, OneWay, or TwoWay.

Consider this example:

<TextBox x:Name="txtLastName" Text="{Binding LastName, 
        Mode=OneWay}" />

The XAML above will automatically fill the "Text" property of txtLastName when databinding occurs. We can tell UI elements what their binding source is by using the DataContext property. The DataContext property can be assigned to a Container Control, such as a Canvas or Grid, and all child controls within that container will receive their bound data from that DataContext. For example, if txtLastName from the example above exists within a Canvas container named "LayoutRoot", then we can assign a business logic class to LayoutRoot.DataContext:

LayoutRoot.DataContext = athlete;

The assignment to DataContext above would cause txtLastName to show the value of athlete.LastName in its Text property.

Data Binding Modes

When you are specifying the Mode for data binding, you have three choices:

• OneTime: Updates the target property when the binding is created.
• OneWay: Updates the target property when the binding is created. Changes to the source object can also propogate to the target.
• TwoWay: Updates either the target or the source object when either change. When the binding is created, the target property is updated from the source.

If you have a read-only UI element where the source data does not change, you might consider using OneTime mode data binding. If you have a read-only UI element, and the user may be selecting different records at times (causing the source data to change), you might consider using OneWay databinding. TwoWay databinding is handy in Master/Details scenarios, where a DataGrid can be linked to controls in a "Detail" section of the screen.

All material in this Accessing Data Using Silverlight is copyright 2012 Webucator. The purpose of this website is to help you learn Silverlight on your own and use of the website implies your agreement to our Silverlight Tutorial Terms of Service.