Silverlight Hosting News (SuperBlogAds Network)

WCF RIA Hosting :: Using Attribute Validation in Silverlight with WCF RIA Services Example

Landon Ferguson — Wed, 16 May 2012 04:00:36 +0000

In this example I’ll use WCF RIA services because it can wire the example up quickly, it automatically projects the data annotations, and because I get a lot of people who ask me for examples using WCF RIA. The example here will work just as well if you use your own POCO classes with annotations in a shared library and send them across the wire with a REST service using JSON.

First, a simple class to encapsulate some data that is decorated with the annotations:

public class Contact
{
    [Key]
    public int Id { get; set; }

    [Required]
    public string FirstName { get; set; }

    public string LastName { get; set; }

    [Required]
    [RegularExpression(@"^[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$",
        ErrorMessage = "Email is invalid.")]
    public string Email { get; set; }
}

Next, a simple domain service that exposes what WCF RIA wants to think it is talking to a database layer. Note I am stubbing the CRUD to allow for edits on the client but don’t really care about processing them for this example. The one query always returns an example with my information in it.

[EnableClientAccess()]
public class ContactDomainService : DomainService
{
    public Contact GetContact(int contactId)
    {
        return new Contact
                    {
                        Id = contactId,
                        FirstName = "Jeremy",
                        LastName = "Likness",
                        Email = "jeremy@jeremylikness.com"
                    };
    }

    [Insert]
    public void InsertContact(Contact contact)
    {

    }

    [Delete]
    public void DeleteContact(Contact contact)
    {

    }

    [Update]
    public void UpdateContact(Contact contact)
    {

    }
}

This is where the beauty of WCF RIA services comes into play, and I won’t deny it: build the application, and you’re ready to go with grabbing and manipulating the data on the client. Before you build the view model you can create a helper class that uses the data annotations validation to process the attributes on the entity. While I wouldn’t normally overload the same class to also take on the work of a command, the helper will also implement ICommand to demonstrate how it can be used to also control whether or not the user is able to save the form based on validations (this keeps the example simple – normally I would have a second command class that interacts with the validation helper).

The bulk of the class is straightforward. It is typed to a class that implements property change notification, and registers for this (it also exposes a method to release the registration to avoid issues with memory leaks). Whenever a property changes, it uses reflection to grab the value and then passes all of the information over to the data annotations validation class. That class will throw an exception if the validation fails, and the helper traps this and uses it to keep track of properties that have validation errors before re-throwing it for the Silverlight validation system to use. I’m keeping it simple here and using strings but you can tweak it based on this post.

public class ValidationHelper : ICommand where T : class, INotifyPropertyChanged
{
    private readonly T _instance;

    private readonly Dictionary  _hasErrors
        = new Dictionary();

    public ValidationHelper(T instance)
    {
        _instance = instance;
        _instance.PropertyChanged += _InstancePropertyChanged;
    }

    public void Release()
    {
        if (_instance != null)
        {
            _instance.PropertyChanged -= _InstancePropertyChanged;
        }
    }

    private void _InstancePropertyChanged(object sender, PropertyChangedEventArgs e)
    {

        _hasErrors[e.PropertyName] = false;            

        var value =
            typeof (T)
                .GetProperty(e.PropertyName)
                .GetGetMethod()
                .Invoke(_instance, null);

        try
        {
            Validator.ValidateProperty(
                value,
                new ValidationContext(_instance, null, null)
                    {
                        MemberName = e.PropertyName
                    });
        }
        catch
        {
            _hasErrors[e.PropertyName] = true;
            throw;
        }
        finally
        {
            RaiseCanExecuteChange();
        }
    }
}

The implementation of the command interface takes one more step. Because a user might change some text and then click submit before validation fires, the command implementation will validate the entire object before determining whether or not it is safe to submit. The command is conditioned by the existence of any errors in the error dictionary. Note that the execute methods uses a different approach that doesn’t throw exceptions and simply flags the individual errors generated by the call.

public bool CanExecute(object parameter)
{
    return _hasErrors.Keys.All(key => !_hasErrors[key]);
}

public void Execute(object parameter)
{
    var errors = new List();

    if (Validator.TryValidateObject(
        _instance,
        new ValidationContext(_instance, null, null),
        errors))
    {
        MessageBox.Show("Success!");
    }
    else
    {
        foreach (var member in errors.SelectMany(error => error.MemberNames))
        {
            _hasErrors[member] = true;
        }
        RaiseCanExecuteChange();
    }
}

The view model keeps an instance of the validation helper and tracks changes to the current contact, spinning up a new helper as needed. It also exposes an edit flag to disable editing while it is loading the data.

public class MainViewModel : INotifyPropertyChanged
{
    private ValidationHelper _helper;
    private Contact _contact;

    private readonly string[] _properties =
        new[] {"FirstName", "LastName", "Email"};

    protected Contact CurrentContact
    {
        get { return _contact; }
        set
        {
            if (_helper != null)
            {
                _helper.Release();
                _helper = null;
            }

            _contact = value;

            if (_contact != null)
            {
                CanEdit = true;
                _helper = new ValidationHelper(value);
                RaisePropertyChange("SaveCommand");
            }

            RaisePropertyChange("Contact");
            foreach(var property in _properties)
            {
                RaisePropertyChange(property);
            }
        }
    }

    private bool _canEdit;
    public bool CanEdit
    {
        get { return _canEdit; }
        set
        {
            _canEdit = value;
            RaisePropertyChange("CanEdit");
        }
    }
}

It exposes the validation helper as a command and also projects all of the properties on the underlying contact object:

public ICommand SaveCommand
{
    get { return _helper; }
}        

public string FirstName
{
    get { return CurrentContact == null ? string.Empty : CurrentContact.FirstName; }
    set { CurrentContact.FirstName = value; }
}

public string LastName
{
    get { return CurrentContact == null ? string.Empty : CurrentContact.LastName; }
    set { CurrentContact.LastName = value; }
}

public string Email
{
    get { return CurrentContact == null ? string.Empty : CurrentContact.Email; }
    set { CurrentContact.Email = value; }
}

In the constructor, it either creates a design-time instance or uses WCF RIA services to load an instance of the contact record:

public MainViewModel()
{
    if (DesignerProperties.IsInDesignTool)
    {
        CurrentContact = new Contact
                        {
                            Id = 1,
                            Email = "jeremy@jeremylikness.com",
                            FirstName = "Jeremy",
                            LastName = "Likness"
                        };
        return;
    }

    var ctx = new ContactDomainContext();

    var query = ctx.GetContactQuery(1);
    ctx.Load(
        query,
        contact =>
            {
                CurrentContact = contact.Entities.Single();
            },
        null);
}

The Xaml to wire this up is straightforward – here is an example combination of a label and a text box:

That’s it – run the application and edit the fields. You’ll see all of the attribute validations come across nicely. If you delete the first name, then click the submit button without tabbing out of the field, the validations will still fire and the submit button will disable itself until you fix the error. As you can see, it’s very straightforward to tap into existing attribute-based validations. If you are implementing one of the newer interfaces like INotifyDataErrorInfo, you can use the “try” methods on the validator to avoid throwing exceptions, and parse the results to set errros on the underlying interface instead.

Silverlight 5 Hosting :: Using Custom Markup Extensions in Silverlight 5

Mark Latchey — Mon, 16 Apr 2012 04:27:55 +0000

In this post, I’d like to present a custom markup extension of my own – one that retrieves RESX localization resources and simplifies the task of adding localization support to Silverlight applications.

In the past, RESX-based localization was usually performed in Silverlight XAML with the help of the built-in {Binding} markup extension. To demonstrate, the following example declares an instance of the ResourceManager wrapper class named Resources (which is generated by Visual Studio from Resources.resx), assigns the Resources instance to the DataContext property of a TextBlock, and uses a data-binding expression to set the TextBlock’s Text property equal to the Greeting property of the Resources instance:

It works, but it makes you wonder why you have to resort to data binding to make localization work when localization is such a common task in Silverlight applications.

You can make this work a little more cleanly by writing a custom markup extension. Such an extension might be applied this way:

Text="{local:Resx ResxKey=Greeting, ResxType=Resources, Default=Welcome}" />

In this example, Resx is the custom markup extension, ResxKey identifies the localization resource to be loaded, ResxType identifies the ResourceManager wrapper class that provides access to that resource, and Default is an optional default value that’s used if the specified localization resource doesn’t exist or can’t be retrieved. Better, is it not? And it’s just one of a million different applications for custom markup extensions.

Implementing a custom markup extension is, in most cases, relatively straightforward. You begin by deriving from Silverlight 5’s new System.Windows.Markup.MarkupExtension class. Then you override ProvideValue in the derived class and return the value generated by the markup extension. My ResxExtension class is implemented this way:

public class ResxExtension : MarkupExtension { public string ResxType { get; set; } public string ResxKey { get; set; } public object Default { get; set; }


public override object ProvideValue(IServiceProvider serviceProvider)

{

if (!String.IsNullOrEmpty(ResxType) && !String.IsNullOrEmpty(ResxKey))

{

try

{

// Create a strongly typed resource manager instance

object resman = Activator.CreateInstance(Type.GetType(ResxType));
// Get the value of the specified property

PropertyInfo pi = resman.GetType().GetProperty(ResxKey);

return pi.GetValue(resman, null);

}

catch (Exception)

{

// Purposely do nothing here to allow the call to fall through

}

}

// If we make it to here, return the default value (if specified) or, // as a last resort, the key name if (Default != null) return Default; else return ResxKey; } }

The three public properties – ResxType, ResxKey, and Default – define the named parameters that the markup extension accepts. The XAML parser automatically initializes these properties with the values provided in the markup. My ProvideValue override uses reflection to create an instance of the ResourceManager wrapper class identified by ResxType, and then uses reflection again to retrieve the value of the property whose name is stored in the markup extension’s ResxKey property. If anything goes wrong, ProvideValue returns the default value specified with the Default parameter, or the value of ResxKey if there is no Default parameter.

When you run the app for the first time, you’ll see this:

But if you open App.xaml.cs and uncomment line of code that sets the culture to French, you’ll see this instead:

The welcome text, the URI of the flag image, and the width of the flag image come from RESX files named Resources.resx, Resources.fr.resx, Resources.es.resx, and Resources.de.resx. Open these RESX files in Visual Studio and you’ll see exactly how the individual resources are defined. As for applying the localization resources, that happens in MainPage.xaml:

Foreground="LightYellow" FontSize="72" FontWeight="Bold" HorizontalAlignment="Center" VerticalAlignment="Center"> Width="{local:Resx ResxKey=FlagWidth, ResxType=CustomMarkupExtensionDemo.Localization.Resources}" />

Silverlight 5 Hosting :: DoubleClickInvokeCommandBehavior in Silverlight 5

Landon Ferguson — Wed, 04 Apr 2012 03:44:44 +0000

Today, I was working on PodTower a bit more, and needed a way to add items to the new playlist coming in PodTower 2. While I plan on adding drag and drop at a later date, for now I decided that double-clicking on an item in the podcast list will add it to the current playlist.

So, I decided to break out a behavior for this task. Using the new ClickCount property provided by the MouseButtonEventArgs class (MSDN Documentation here), I was able to count the number of clicks, and if it was equal to 2, invoke a Command. Since Behaviors inherit from DependencyObject, they can participate in the binding system as well. Combine this with the new RelativeSource binding support in Silverlight 5, this opens up a whole new realm of binding possibilities! For PodTower, I have the behavior bound to a property of the DataContext on the main UserControl of the application. This allows me to bind up to the Commands on the viewmodel without having to do horrible back-end hack code.

Without further ado, here’s the code for the behavior. Note that I’ve included a conditional symbol called SILVERLIGHT5, so that if you want to use this behavior in Silverlight 4, you can.

using System;
using System.Windows;
using System.Windows.Input;
using System.Windows.Interactivity;   

namespace PodTower
{
    public class DoubleClickInvokeCommandBehavior : Behavior
    {
        public ICommand Command
        {
            get { return (ICommand)GetValue(CommandProperty); }
            set { SetValue(CommandProperty, value); }
        }   

        public static readonly DependencyProperty CommandProperty =
            DependencyProperty.Register("Command", typeof(ICommand), typeof(DoubleClickInvokeCommandBehavior), new PropertyMetadata(null));   

        public Object CommandParameter
        {
            get { return (Object)GetValue(CommandParameterProperty); }
            set { SetValue(CommandParameterProperty, value); }
        }   

        public static readonly DependencyProperty CommandParameterProperty
=
            DependencyProperty.Register("CommandParameter", typeof(Object), typeof(DoubleClickInvokeCommandBehavior), new PropertyMetadata(null));   

        protected override void OnAttached()
        {
            base.OnAttached();   

            this.AssociatedObject.MouseLeftButtonDown += OnClick;
        }   

        protected override void OnDetaching()
        {
            base.OnDetaching();
            this.AssociatedObject.MouseLeftButtonDown -= OnClick;
        }   

#if !SILVERLIGHT5
        DateTime? _lastClick;
#endif   

        void OnClick(object sender, MouseButtonEventArgs e)
        {
#if SILVERLIGHT5
            if (e.ClickCount != 2)
                return;
#else
            if (_lastClick == null)
            {
                _lastClick = DateTime.Now;
                return;
            }
            else
            {
                var now = DateTime.Now;
                var last = _lastClick.Value;
                _lastClick = now;   

                if (now.Subtract(last).TotalMilliseconds > 250)
                    return;
            }
#endif
            if (this.Command == null || !this.Command.CanExecute(this.CommandParameter))
                return;  �
            this.Command.Execute(this.CommandParameter);
        }
    }
}

…and here’s an example of it used in the PodTower main UI.

WCF Hosting :: How to Fix Error -The underlying connection was closed: An unexpected error occurred on a receive.

Landon Ferguson — Thu, 22 Mar 2012 05:14:08 +0000

This is another installment in the WCF vs. WTF article series. I mentioned before that I am quite a fan of WCF but having said that, feel that there are a few areas for improvement like sending method comments with the service contract discovery and more streamlined debugging, to name a couple.

The truth is that WCF actually provides some decent tools to debug service issues. However, I feel that the tools are a bit cumbersome to use and the bigger issue that the exception that bubbles up to the top is not necessarily informative of what actually caused the issue and requires digging deeper.

So.. Here is a pretty generic client error:

The underlying connection was closed: An unexpected error occurred on a receive. – at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(
TimeSpan timeout)
An error occurred while receiving the HTTP response to http://localhost:8731/Design_Time_Addresses/SomeService/. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

So this basically says that something went wrong on the server-side and the service closed the connection. I should also note, that it is certainly extremely useful to have the following option configured for the service behavior even though it promises a bit more than it delivers:

I am generally pretty good at sticking an UnhandledException handler into my code but was surprised to find out that nothing was logged on the service to correspond to this client error. Hence, I took the next step and attached Visual Studio to the service and once again executed the client service call. Again, to my surprise, the breakpoint in the call got hit, I successfully stepped through the method right past the ‘return’ statement and saw with my own eyes that a valid method response was being generated. Yet, the client crashed again…

When this happens (i.e. you *know* the service call got executed, but the client crashed), it typically means something went wrong in the WCF plumbing. In order to figure out what exactly went wrong, WCF provides us with the plumbing stethoscope that is service diagnostic listeners. As anything in WCF, it seems there are many ways to configure it, but essentially you need to tell the service which things to listen for and where to log them. So a couple of sections need to be added to the config file:

propagateActivity="true"> switchValue="Warning, ActivityTracing"> type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp"> type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">

This snippet creates two listeners (message and service trace) and specified where they should be stored. Then, inside the serviceModel configuration we can also specify what types of messages to log. For example:

After adding the listeners, I ran the client again. Again it crashed, but now I had some logs created in ‘c:\wcfLogs\SomeService”.

Note: The directory where the logs will go has to exist – it will not be automatically created!

Checking out the lgos, (in Microsoft Service Trace Viewer) more information came to light. The Trace Viewer breaks up different service activities (i.e. construction, service open call, service action request, etc) and nicely enough highlights in red where the errors occur.

In my case, in ‘Process action .. ‘ activity I saw that the service was ‘Throwing and exception”, which presumably it was also catching, since my Unhandled Exception handler did not get hit. Click on the exception revealed these details:

Maximum number of items that can be serialized or deserialized in an object graph is ’65536′. Change the object graph or increase the MaxItemsInObjectGraph quota.

Ok, now this seems more informative than ‘underlying connection was closed’.. Wonder why instead of closing the connection, the service could not communicate this exception to the client given the exceptionDetailsInFaults configuration… But anyway, at least now I had something to work with.

This error above just said that the number of objects in the data returned by the service call was too large to be serialized. Wonder why they had to limit it… But I changed the configuration in the service behavior to resemble this:

No need to skimp on the maxItemsInObjectGraph, I say!

I restarted the service, ran the client… tun dun dun! and it crashed again. Well, this time, the exception on the client looked like this:

Maximum number of items that can be serialized or deserialized in an object graph is ’65536′. Change the object graph or increase the MaxItemsInObjectGraph quota. – at System.Runtime.Serialization.XmlObjectSerializerContext.IncrementItemCount(Int32 count) at ReadSisyphusUriRecordFromXml(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )…..

What? It looks the same as the exception above!? Yep, except this time, it is on the client side and occurs around the same place where the “underlying connection was closed..” exception was happening before. So basically this says that the client deserializer also needs to be reconfigured. On the client side, this configuration needs to be specified for the behavior associated with the EndPoint. On the server side, it was a behavior associated with the service (i.e. within ServiceBehaviors). So a little tricky. The new client configuration change looked something like this:

This ‘Behaviors’ defintion was added within the tag, and then for the endpoint itself I added ‘behaviorConfiguration=”SomeServiceClientEndpointBehavior”‘ attribute.

That fixed the problem for me. Probably more than you wanted to know, but I hope this helps.

Cheers!

WCF RIA Hosting :: Use DomainServices as Service References

Mark Latchey — Mon, 19 Mar 2012 06:31:28 +0000

DomainServices was introduces as part of WCF RIA Services. WCF RIA Services offers a solution on how we can build a middle-tier having clients and servers.

Using a DomainService in a Silverlight client is very easy using WCF RIA Services – the WCF RIA Services link between the client and the server will automatically generate the client side code that we need to communicate with the server.

To avoid writing middle-tier functionality more than once we want to be able to reuse the DomainService and the logic inside of it to all of our projects. Most project types beside Silverlight do not understand WCF RIA Services yet. But as a DomainService ultimately just is a WCF Service we can just make a normal Service Reference (or ChannelFactory) to it and reuse the logic.

For that to work you need to make a few adjustments to the project hosting the service. When you add a DomainService to your project a DomainServiceHttpModule http module is added to your web.config and ASP.NET compatibility is turned on.

The DomainServiceHttpModule dynamically generates a WCF Service based on our DomainService. In this sample I have added a DomainService called DomainService1 in the root of my ASP.NET web project called WebApplication1. The web project is using port 6479. Based on this information I can point to my dynamically generated WCF Service from my browser:

http://localhost:6479/Services/WebApplication1-DomainService1.svc

If I try to make a Service Reference to the WCF Service I will get an error:

There was no endpoint listening at http://localhost:6479/Services/WebApplication1-DomainService1.svc that could accept the message.

Before I can make a Service Reference to the service I need to define an endpoint in the web.config. First I need to add a custom configuration section for DomainServices within System.ServiceModel.

Using the RIA Services Toolkit I can now define a SOAP endpoint (I need to add a reference to Microsoft.ServiceModel.DomainServices.Hosting found in the Microsoft SDKs/RIA Services/v1.0/Toolkit/Libraries folder).

Finally I can add a Service Reference to the service and use it as if it was a regular WCF Service.

FREE .NET MVC 4 BETA Hosting Account with ASPHostCentral.com

George Veltreski — Thu, 15 Mar 2012 03:54:56 +0000

ASPHostCentral.com, the leader in ASP.NET and Windows Hosting Provider, proudly announces that we have supported the latest ASP.NET MVC 4.0 BETA Hosting.

To support Microsoft ASP.NET MVC 4.0 BETA Framework, we gladly inform you that we provide this beta account FREE of charge for a limited time (* terms and conditions apply).

New Features in ASP.NET MVC 4

This section describes features that have been introduced in the ASP.NET MVC 4:�
- Enhancements to Default Project Templates
- Better Support for Mobile Project Template
- Enhancement in Display Modes
- Mobile Project Template support for VB.NET
- Dependency Injection Improvements

Terms and Conditions in Using this ASP.NET MVC 4.0 BETA Account

The followings are the features you will get under this FREE ASP.NET MVC 4.0 BETA Account:�
- ASP.NET MVC 4.0 Beta Framework
- 1 Website/Domain
- 100 MB disk space
- 100 MB bandwidth
- 50 MB SQL 2008 space
- 24/7 FTP access
- Windows Server 2008 Platform

If you want to participate in this BETA program, there are several rules you need to understand:

- As this is a beta version, not all the features are available. They may be some issues on this beta framework, which will be fixed upon the full release of ASP.NET MVC 4.0 Framework

- ASPHostCentral.com does not guarantee the uptime of the sandbox solution. Additionally, we do not keep/store any backup of your files/accounts

- ASPHostCentral.com does not guarantee rapid response to any inquiries raised by a user

- This free account is only meant for testing. Users should not use it to store a production, personal, e-commerce or any blog-related site

- This free account is used to host any ASP.NET MVC 4.0 beta website only. Any questions that are not related to ASP.NET MVC 4.0 BETA will not be responded. A user shall not host any non-ASP.NET MVC 4.0 site on this free account either

- ASPHostCentral.com reserves full rights to terminate this beta program at any time. We will provide a notification on our Help Desk System prior to the termination of this program

- ASPHostCentral.com reserves full rights to terminate a user account, in which we suspect that there is an abuse to our system

- Once this beta program is terminated, your account will be completely wiped/remove from our system.

- This offer expires on 31st May 2012

If you wish to participate in this FREE ASP.NET MVC 4.0 BETA Program, you must register via https://secure.asphostcentral.com/BetaOrder.aspx

.NET 4.5 BETA Hosting with ASPHostCentral.com

George Veltreski — Wed, 14 Mar 2012 04:33:46 +0000

ASPHostCentral.com, the leader in ASP.NET and Windows Hosting Provider, proudly announces that we will support ASP.NET 4.5 Hosting.

To support Microsoft ASP.NET 4.5 Beta Framework, we gladly inform you that we provide this beta account FREE of charge for a limited time (* terms and conditions apply).

The followings are the features you will get under this FREE ASP.NET 4.5 BETA Account:

- .NET 4.5 Beta Framework
- 1 Website/Domain
- 100 MB disk space
- 100 MB bandwidth
- 50 MB SQL 2008 space
- 24/7 FTP access
- Windows Server 2008 Platform

If you want to participate in this Beta program, there are several rules you need to understand:

- As this is a beta version, not all the features are available. They may be some issues on this beta framework, which will be fixed upon the full release of ASP.NET 4.5 Framework
- ASPHostCentral.com does not guarantee the uptime of the sandbox solution. Additionally, we do not keep/store any backup of your files/accounts
- ASPHostCentral.com does not guarantee rapid response to any inquiries raised by a user
- This free account is only meant for testing. Users should not use it to store a production, personal, e-commerce or any blog-related site
- This free account is used to host any ASP.NET 4.5 beta website only. Any questions that are not related to ASP.NET 4.5 beta will not be responded. A user shall not host any non-ASP.NET 4.5 site on this free account either
- ASPHostCentral.com reserves full rights to terminate this beta program at any time. We will provide a notification on our Help Desk System prior to the termination of this program
- ASPHostCentral.com reserves full rights to terminate a user account, in which we suspect that there is an abuse to our system
- Once this beta program is terminated, your account will be completely wiped/remove from our system.
- For details, please check http://www.asphostcentral.com/ASPNET-45-Beta-Hosting.aspx
- This offer expires on 31st May 2012

If you want to participate on this FREE ASP.NET 4.5 Beta Program, you must register via https://secure.asphostcentral.com/BetaOrder.aspx

Silverlight 5 Hosting :: Combo Box Type Ahead in Silverlight 5

Mark Latchey — Wed, 14 Mar 2012 03:14:07 +0000

A nice, small feature in the new Silverlight 5 Beta is the ability to type ahead in combo boxes.

This makes choosing from long list far simpler.

You can see this at work by whipping up a very quick Silverlight 5 application.

On the Main page add a combo box,

x:Name="LayoutRoot" Background="White"> x:Name="theComboBox" Height="40" Width="150" Margin="20" />

In the code behind we’ll create some data to act as the ItemsDataSource for the combo box:

public MainPage( ) { InitializeComponent( ); List contents = new List { "apples", "berries", "apple pie", "apple strudel", "blueberries", "strawberries", "cherries", "cherry pie", "bananas"}; theComboBox.ItemsSource = contents; }

That’s enough to see the effect. When you run the program the combo box comes up empty. Start typing apple strudel and you’ll see that the combo box first finds apples, then apple pie (on the space) and then when you type the s, it finds apple strudel.

You can see this most clearly by rerunning the application and opening the combo box before you begin typing. You can then see the selected item move as you type (see image at top). Nice.

Silverlight 4 Hosting :: Customer IApplicationService for Silverlight Applications

Landon Ferguson — Mon, 05 Mar 2012 04:09:34 +0000

In my experience working with Silverlight applications, probably one of the most underused features I’ve witnessed is the ability to abstract application-level functionality using the IApplicationService and IApplicationLifetimeAware interfaces. This, in turn, results in the over-use (and abuse) of the Startup and Exit events in the Application object. Before you get angry with me shaking a finger, I’ll admit I’ve done this quite a bit myself.

IApplicationService

The IApplicationService interface allows you to define a class that is part of the overall application lifecycle. It provides a mechanism to create a service that lasts the duration of a Silverlight application. It is called once when the application starts with an ApplicationServiceContext, and called again when the application ends.

One of the most useful things you can do with this service class is use it to intelligently parse parameters passed to the Silverlight application. How many times have you found yourself hooking into the application startup and then parsing these out? What’s worse, in larger, complex applications, many different portions of the application share responsibility for handling these parameters. It breaks the concept of loose coupling to have a single front-end parsing it out and then stuffing it into an object to dole it out to the consumers that need it.

By implementing IApplicationService, you can create a service for your functionality that handles its own initialization parameters. There is no “central” place that has to understand everything. Silverlight supports using multiple application services, so you can have a logger service that looks at the logging parameter and a file upload service that looks at the file storage location parameter, so on and so forth.

Here’s what a service that handles writing to the debugger might look like:

public class LoggerService : IApplicationService { const string TRACE_LEVEL_KEY = "TraceLevel";


public LoggerService()

{

_traceLevel = TraceLevel.Warning; // default

}
private TraceLevel _traceLevel;
public ILogger Logger { get; private set; }
public static LoggerService Current { get; private set; }
public void StartService(ApplicationServiceContext context)

{

Current = this;

if (context.ApplicationInitParams.ContainsKey(TRACE_LEVEL_KEY))

{

_traceLevel = (TraceLevel)Enum.Parse(typeof (TraceLevel), context.ApplicationInitParams[TRACE_LEVEL_KEY], true);

}
Logger = new CustomLogger(TraceLevel);

Logger.WriteLine(TraceLevel.Information, "Logger service started.");

}

public void StopService() { Logger.WriteLine(TraceLevel.Information, "Logger service stopped."); } }

This service now allows me to configure the logging level in the web page using initParams, like this:

What’s more, if it is in a project by itself, adding the service to a new application is so simple it’s hard to believe more people don’t take advantage of this. After referencing the project, I won’t have to mangle my App.xaml.cs and hook into any events in order to use the new service, parse out parameters, etc. Nope, I just add a simple reference to it in the App.xaml that looks like this:

IApplicationLifetimeAware

Now, if you really want to do some cool things, you can extend the class even further by implementing IApplicationLifetimeAware. This will give you four additional methods: Starting, Started, Exiting, and Exiting.

Use these to perform set up and clean up actions.

For example, in the Sterling Windows Phone 7 Example I wrote (Sterling is an open source object-oriented database for Silverlight 4.0 and Windows Phone 7) I created a database service to make it easy to set up and tear down the database engine. The service looks like this:

public class DatabaseService : IApplicationService, IApplicationLifetimeAware { public static DatabaseService Current { get; private set; }


public ISterlingDatabaseInstance Database { get; private set; }
private SterlingEngine _engine;
public void StartService(ApplicationServiceContext context)

{
Current = this;

_engine = new SterlingEngine();

}
public void StopService()

{

_engine = null;

}
public void Starting()

{

_engine.Activate();

Database = _engine.SterlingDatabase.RegisterDatabase();

}
public void Started()

{

return;

}
public void Exiting()

{

_engine.Dispose();

}

public void Exited() { return; } }

As you can see, I am managing everything that would normally get hooked into the application startup and exit events. Instead of adding to that code-behind, however, I can abstract these hooks in a re-usable component that is easily dropped into or out of the App.xaml as needed. Just like the previous example, the only thing needed to hook into the database in a Windows Phone 7 application is now just this:

The Silverlight framework guarantees my service is called to start only once, so I take advantage of that call to assign a static property. That way, anywhere in the application I need to reference the service, I can use ServiceName.Current (for example, SterlingService.Current).

Don’t limit yourself to just that, however. One common task in composite Silverlight applications is “bootstrapping” objects. If you are using the Managed Extensibility Framework (MEF), you may need to configure some catalogs and then call the CompositionInitializer. You can do this in an application service as well. In fact, many of my applications have nothing in the App.xaml.cs code behind except a call to InitializeComponent. Why? Because I can set the root visual in a service, like this:

[Import] public Shell MainShell { get; set; }


public void StartService(ApplicationServiceContext context)

{

_myCatalog = new AggregateCatalog(new DeploymentCatalog());

var container = new CompositionContainer(_mainCatalog);

CompositionHost.Initialize(container);

CompositionInitializer.SatisfyImports(this);

}

public void Starting() { Application.Current.RootVisual = MainShell; }

When called, the service sets up the catalogs/containers/etc. and satisfies imports to generate the shell. If the shell has any dependencies, these are also handled by MEF. Then, in the starting method, we wire the shell to the root visual because this is called just before the full visual tree is loaded.

I hope to see this powerful feature used more often to add some quality customer service to Silverlight applications.

Silverlight 4 Hosting :: Data Contracts and Behaviors over the Wire Silverlight 4

Landon Ferguson — Thu, 01 Mar 2012 03:21:33 +0000

One feature I employ often in Silverlight projects is the ability to share a model between the client and the server. When you expose a model using a WCF service, you can consume it on the Silverlight side and indicate you want to reuse types in a referenced assembly, rather than having the proxy types generated. At first glance this seems ideal because you can truly project behavior such as validation to the client without maintaining separate copies of the type in question. Upon further inspection, however, there can be some unexpected side effects.

Consider the following class that is defined in a standalone Silverlight assembly but shared on the server by adding it as a linked file:

[DataContract] public class SimpleModel { public SimpleModel() { NonMemberProperty = "This was initialized within the constructor."; }


private string _field = "This is an initialized field.";
public string NonMemberProperty { get; set; }
[DataMember]

public string MemberProperty { get; set; }

public string Field { get { return _field; } } }

I’ve purposefully packed a few different examples to help illustrate what is happening. It should be very clear what will happen when you instantiate the class. The field will be initialized to expose a value, the non-member will be given a value, and the member property (the one tagged as a data member) is initialized to the default value of null.

Now you can expose the model using a web service. Just add a new “Silverlight-enabled Web Service” to your web project, and give it a very simple operation to fetch a new instance of the model:

[ServiceContract(Namespace = "http://jeremylikness.com/examples/")] [SilverlightFaultBehavior] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] public class SimpleService { [OperationContract] public SimpleModel GetSimpleModel() { var simpleModel = new SimpleModel { MemberProperty = "This was initialized by the service." }; return simpleModel; } }

What happens now? On the server, you’ll get a new object that now has three fully populated properties – the field (which returns the value initialized on the internal field), the non-member property, and the member property. So far, so good.

Flip over to the Silverlight client side. Create a grid that has rows and columns for the labels and the values. Embed an instance of the model like this:

And then you can easily data-bind the values like this:

Style="{StaticResource ValueStyle}"/> Style="{StaticResource ValueStyle}"/> Style="{StaticResource ValueStyle}"/>

Add a button for the user to click. We’ll forget MVVM for now (heck, our model didn’t even implement property change notification) and just implement a code behind. Right now the model should create an instance in the designer and show you the two initialized fields — something like this:

If you do nothing in the code-behind you should still be able to run the application and see the initialized values. Now let’s get down to the wire.

Add a service reference, only make sure you specify that it re-uses types. You get to the dialog by clicking on the “advanced” button when adding a new service. It should look something like this:

This ensures that the service will return the actual type represented by the model, rather than generating a proxy type that lives in the namespace of the service itself. You get to have the full type with all of the methods and functions you’ve defined, even if they aren’t being sent over the wire. Now that’s handy, right?

In the code behind for the button click, simply fetch the instance generated on the server and update the data context:

private void Button_Click(object sender, RoutedEventArgs e) { ((Button) sender).IsEnabled = false; var client = new ServiceReference.SimpleServiceClient(); client.GetSimpleModelCompleted += _ClientGetSimpleModelCompleted; client.GetSimpleModelAsync(); }

void _ClientGetSimpleModelCompleted(object sender, ServiceReference.GetSimpleModelCompletedEventArgs e) { btnLoad.IsEnabled = true; LayoutRoot.DataContext = e.Result; }

Not too complicated, right?

If you run the application and click the load button, the code-behind will call the service and fetch a new instance. When the instance is bound to the data context, however, you may notice something strange. The property that was flagged as a data member and was set on the server comes through just fine, but the other properties are empty. How can that be? Even though you didn’t tag them as data members, they should have been set when the type was constructed. The field property doesn’t even have a setter.

This is as expected, but what about the other two properties? The answer is well-documented but often overlooked. If you read the documentation for the data contract serializer, or the XML object serializer that it is based on, you’ll find a small but important sentence that explains: “When instantiating the target object during deserialization, the DataContractSerializer does not call the constructor of the target object.” That explains the non-member property. When the serializers create the type, they by pass the normal type system. This makes sense because you are expecting to reconstruct the type based on the contract, so the properties not passed in the contract aren’t really relevant. The type is built from the ground-up by setting the properties that were serialized, but no other initialization code is called.

If you’re wondering about the field, it’s the same problem. While the C# language allows you to initialize fields as a convenience, the code is actually moved into the constructor for the type. If you decompile the DLL for the model used in this example, this is what the decompiled constructor will look like:

public SimpleModel() { this._field = "This is an initialized field."; base(); this.NonMemberProperty = "This was initialized within the constructor."; }

As you can see, the compiler conveniently moved the field initialization into the constructor. All of the initialized fields will be called from the start of the constructor before calling into the base object constructor and then handling the code you specify.

So what’s the point? It is very important that you understand the implications of sharing types between the server and the client, especially when there are behaviors you are expecting. If you have certain properties that are initialized in the constructor, you can’t expect them to be available when addressing the instances on the client. One way to deal with this is to move initialization logic into a separate method and call it from the constructor but expose it so you can call it elsewhere as well. This may work in some cases but often the reason for putting code into the constructor is to hide the implementation details of how the type is initialized from the consumer. If that’s the case, it’s probably better to make sure all of your exposed properties and methods handle initialization appropriately without a dependency on the constructor. For example, remove the initialization code for the field and replace the property code with this:

get { return _field ?? (_field = "This was initialized in the getter."); }

Now the field will be initialized on first access and never initialized again, but it will work equally well regardless of how it is instantiated. Another way to keep the initialization details private is to track the initialization state with a private field. Booleans default to false so the field will have that value whether the type was created with a call to its constructor or not. Your code can check the value of this field and call the initialization logic the first time it is needed.

Sharing types between the client and the server is a powerful feature that Silverlight provides. It is important that you understand the nuances of how it works so that you can construct your classes to behave consistently and don’t fall victim to unexpected behaviors on the client because the constructors were never called for your types.