Link to my new blog: http://www.oliver-lohmann.me

Happy reading!

It takes the most common first and last names of the US and generates random combinations of them. It also supports genders so you can differentiate between female and male contacts.

Usage/Installation is straight forward, see GitHub for details: https://github.com/olohmann/Lohmann.RndContacts

Here is my at-a-glance-list of hot topics from Øredev 2013:

• JavaScript
• Functional Programming
• Domain-Driven Design
• Micro Services
• Continuous Delivery

JavaScript

JavaScript is everywhere - with NodeJS even on the server side. Some people already talk about JavaScript as the VM or assembly language of the web. I do not want to recite all of these right statements. Instead I would like to share the impressions about JavaScipt I got from the sessions at Øredev. A lot of speakers had something to say about JavaScript. Unsurprisingly all of them agreed that JavaScript is a flawed language - and I concur. The most interesting session on JavaScript was held by Douglas Crockford. He predicted that we might be stuck another 40(!) years with JavaScript and its shortcomings. Looking back in our industry's history of dealing with sub-optimal programming concepts like the the Go To statement, a number like 40 years might be an optimistic guess. It took us around 30 years from Edsger Dijkstra famous letter "Go To Statement Considered Harmful" to the actual demise of the Go To statement in a mainstream programming language (Java, 1995). And this was a rather small issue to fix.

What can you do today if you are not happy with JavaScript but need to work with it? Tools like JSLint or JSHint can help you in identifying the obvious bad parts of JavaScript in your code base (look WAT if you don't know what I mean). In addition, you might benefit from TypeScript or CoffeeScript and their approach of compiling into JavaScript. They are bringing things like classical inheritance to the table. Typescript even introduces type-safety to the language.

As a side note: Douglas Crockford was not really enthusiastic about bringing the classical inheritance concept to JavaScript (nor about the existing prototypical inheritance concept). He argues that statefulness and conditional logic in OO-languages are also flawed and tend to over-complicate stuff. In his regard, the future lies more in functional programming. No surprise that functional programming was also one at the hot topics at the conference.

Functional Programming

Functional programming was present with a lot of sessions. Why is functional programming getting so much traction over the last years?

One of the biggest challenges in nowadays' systems is dealing with their high complexity. Complexity arises from mutating state, piling up conditional logic and producing vast amounts of code. Functional programming is no silver bullet but offers concepts to deal with these challenges. Immutable types, pattern matching and a succinct but readable notation help developers to write better code. There was quite a controversial talk from Bodil Stokke titled "Programming, Only Better". Unfortunately it does no appear on the Øredev video listing. It analyzed the state of our current mainstream programming concepts and demonstrated how functional languages may address some of the issues.

If you are programming on the .NET platform, you are in the lucky spot to have already a lot of functional goodness at your fingertips. In 2007 we introduced C# 3 and added features like lambdas or LINQ to the language. And you can even go further into functional programming on the .NET platform with F#. The great thing is that it is absolutely easy to combine C# and F# together in your code base. They both compile to same CLR bytecode. You should watch Phil Trelford's talk to get an in depth impression. From his talk I took away the idea to model my domain classes in F# from now on. I really loved the terseness (hope to blog about it soon).

Domain-Driven Design

Domain-driven design (DDD) cannot be overlooked these days as a conceptual approach to develop and architect complex software. If you have not heard of it you might want to read a quick summary. Understanding the idea of a bounded context will be one of the "aha" moments in your SW development career (at least it was for me). Although not a silver bullet, it seems to be the best approach we have these days to tackle complexity at an architectural level. A couple of sessions addressed DDD. One of them was Julie Lerman's talk on applying DDD concepts with Entity Framework as the persistence infrastructure. Another one was Tom Scott's talk on CQRS/EventSourcing and DDD.

Micro Services

If you drive the DDD idea of bounded contexts to an absolute extreme you end up with something called Micro Services. Think of masses of tiny REST/web services that are hooked together via a high throughput bus. Mix that with a few radical ideas such as a wild mix of technologies, allowance of copy & paste programming and a deliberate throw-away mentality. Sounds a bit crazy? Yes, that was my reaction, too. Fred George's talk was the most unsettling one at Øredev. Unfortunately, the session recording is not available (yet). As an alternative you can watch the recording from a ruby conference in 2012. Side note: I read about a similar concept on Ralf Westphal's blog. Unfortunately, his article is only available in German.

Continuous Delivery

How often do you deploy your software? Once every two months? Every week? There are people out there deploying their Software more than 100 times - EACH DAY. Yes, deployments to the live system - not only to the alpha or staging area. Sounds crazy? Not when you actually think through it. What is the biggest issue in SW development these days? Yes, you read that already in another paragraph - it is complexity. How many changes are typically rolled out when you deploy to production once every two months? 10 features, a couple of bug fixes summing up to maybe 3000 lines of code that were touched? Is your system always stable after deployment? Is it likely that - although you applied best practices as automatic testing - some issues will still pop up? How would you monitor your production system to detect issues that might have been raised from a deployment?

Wouldn't it be easier if you could deploy each tiny feature/fix immediately and monitor their effectiveness in a very advanced fashion? Just touching a couple of lines of code would also reduce the time you need to resolve potential issues. And while you resolve the issue, the tiny increment is reverted. And that's the main idea of continuous delivery (CD) - a high speed feedback loop that allows you to deliver new value to your software as often as you need it.

But who actually needs several updates a day? Companies want to be more nimble than their competitors when it comes to explore new possibilities for products and offerings! They want to experiment with stuff quickly and easily. There are statistics that only a third of all features that are incorporated into a SW are used to the extend that was originally thought off. Yes, you read right. Two thirds are usually waste that most people don't need nor use. In lean development you want to detect and eliminate waste quickly. With CD you have the tool, to put some initial effort into a new idea and drive some statistics how users respond to it. If they like it, continue the development. If not shut it down quickly. The turn-around times allow you to experiment.

As you can imagine the shift to CD is not something you just do over night. It requires a very sophisticated environment that allows operations and development to work seamlessly together - also known under the headline DevOps. Jez Humble's talk gives a great introduction into adopting continuous delivery. There is also a book by Jez for anyone that wants to deep dive into the topic.

When putting the idea of Micro Services into context with CD it becomes clear that both approaches fit together nicely. The Micro Services architecture is all about quick integration and easy discontinuation of services. Exactly the thing that you want to achieve in CD.

My Takeaway

The conference confirmed my feeling that our industry is evolving at different speed levels. A majority that does not evolve at all or very slow and a minority that picks up change and (r)evoluational ideas pretty quickly. The latter are present at conferences, develop cool new products and drive the community. The others that are the gross of our industry cling longer to old things and do not embrace change progressively. Scott Hanselman recently called them dark matter programmers. They make up the majority of our industry but you do not know that they exist. They program procedural are typically a bit waterfall'y and are not eager to try new things. Their systems get bigger and bigger day by day and they drown in complexity. And instead of investing into things like functional programming, Continuous Delivery, DDD or Micro Services they continue to do the same stuff as 10-40 years ago. Lost opportunities?

Basic Control Architecture

 Let us start with the general control architecture of our AutoCompleteTextBox. I really like WPF's Lego pieces nature in this regard. Instead of doing everything from scratch we can utilize existing controls to implement a new one: We need a TextBox for the input, a Popup for providing a panel for our results and a ListBox to show the actual results. The one thing that we are going to implement is a custom control that orchestrates the existing controls. The following figure should clarify this:

The AutoCompleteTextBox is not really TextBox, that is it does not inherit from TextBox but from control. It declares the parts mentioned above via the TemplatePart attribute:

[TemplatePart(Name = PartTextBox, Type = typeof(TextBox))]
[TemplatePart(Name = PartPopup, Type = typeof(Popup))]
[TemplatePart(Name = PartListBox, Type = typeof(ListBox))]
public class AutoCompleteTextBox : Control
{
    public const string PartTextBox = "PART_TextBox";
    public const string PartPopup = "PART_Popup";
    public const string PartListBox = "PART_ListBox";

    [...]

As always when working with parts you need to get hold on them in the OnApplyTemplate method:

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();
            
    partTextBox = this.GetTemplateChild(PartTextBox) as TextBox;
    if (partTextBox == null)
    {
        throw new InvalidOperationException("Associated ControlTemplate has a bad part configuration. Expected a TextBox part.");
    }

    [...] // grab all other parts 

 I am being a bit careful here since just declaring our Parts as Meta-Information does not guarantee that they are really present. Failing immediately with an exception makes it easier to spot the misconfiguration in the Control Template. Speaking of the Control Template - here is an simplified version of it:

<Style TargetType="{x:Type local:AutoCompleteTextBox}">
    <Setter Property="Focusable" Value="False"></Setter>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type local:AutoCompleteTextBox}">
                <Grid>
                    <TextBox x:Name="PART_TextBox" />
                    <Popup x:Name="PART_Popup">
                         <Grid>
                             <ListBox x:Name="PART_ListBox" 
                                      ItemsSource="{TemplateBinding Results}" />
                        </Grid>
                    </Popup>
                </Grid>
        </Setter.Value>
    </Setter>
</Style>

Very good - all required parts are present in the control template. With the visuals and outlets in place let us investigate the internals of the control.

Control Internals

So far we have a custom control called AutoCompleteTextBox that has access to a TextBox, Popup and ListBox. Now let us apply some Rx (I won't explain the Rx code, see my previous post for background information). What we would like to achieve is that we can combine the TextBox' TextChanged event stream with a query function that returns query results. Hooking up the TextChanged events is simple enough:

public class AutoCompleteTextBox : Control
{
     public override void OnApplyTemplate()    
    { 
               base.OnApplyTemplate();

        // [...]

        var textChangedObsevable = Observable.FromEventPattern<TextChangedEventArgs>(partTextBox, "TextChanged")
                .Select(evt => ((TextBox)evt.Sender).Text);

 var constraintTextChangedObservable = textChangedObsevable
                          .Where(text => text != null && text.Length >= this.MinimumCharacters)
                          .DistinctUntilChanged()
                          .Throttle(TimeSpan.FromMilliseconds(this.Delay));
        // [...]
     }
}

The highlighted properties in the code snippet are simple Dependency Properties declared on the AutoCompleteTextBoxControl. They constraint the text event stream to avoid too frequent query polling. Next thing we need to do is use the stream of text input to call into a query result provider. And here the control follows a rather unusual path. It basically allows you to bind a provider function that looks like this:

Func<AutoCompleteQuery, IObservable<IEnumerable<IAutoCompleteQueryResult>>>

with the AutoCompleteQuery defined as:

public class AutoCompleteQuery
{
    public AutoCompleteQuery(string term)
    {
        this.Term = term;
    }
 
    public string Term { get; private set; }
}

and IAutoCompleteQueryResult defined as:

public interface IAutoCompleteQueryResult
{
    string Title { get; }
}  

This deserves some explanation. The function that takes an AutoCompleteQuery as input. This is in the end the input a user has put into the TextBox. In response it returns an Observable which yields IEnumerables of query results. I use an interface here to make sure that there is a textual representation of the query result which can in the end be put into the TextBox. The result provider function is not directly defined as a dependency property because the WPF designer had some issues in the preview although run-time and compile-time wise everything would be fine. Therefore there is a little wrapper that works around this issue. The code of the dependency property:

public AutoCompleteQueryResultProvider AutoCompleteQueryResultProvider
{
    get
    {
        return (AutoCompleteQueryResultProvider)GetValue(QueryResultFunctionProperty);
    }
    set
    {
        SetValue(QueryResultFunctionProperty, value);
    }
}
 
public static readonly DependencyProperty QueryResultFunctionProperty = DependencyProperty.Register(
    "AutoCompleteQueryResultProvider",
    typeof(AutoCompleteQueryResultProvider),
    typeof(AutoCompleteTextBox),
    new UIPropertyMetadata(AutoCompleteQueryResultProvider.Empty));

...and the wrapper class AutoCompleteQueryResultProvider:      

public class AutoCompleteQueryResultProvider
{
    [...]
  
    /// <summary>
    /// Initializes a new instance of the <see cref="AutoCompleteQueryResultProvider" /> class.
    /// </summary>
    /// <param name="getResults">The get results.</param>
    public AutoCompleteQueryResultProvider(Func<AutoCompleteQuery, 
                   IObservable<IEnumerable<IAutoCompleteQueryResult>>> getResults)
    {
        this.GetResults = getResults;
    }
 
    public Func<AutoCompleteQuery, IObservable<IEnumerable<IAutoCompleteQueryResult>>> GetResults { get; private set; }
} 

And finally the combined text changed event stream and the query result provider:

var textChanged = this.textChangedObservable
                .Where(text => text != null && text.Length >= this.MinimumCharacters)
                .DistinctUntilChanged()
                .Throttle(TimeSpan.FromMilliseconds(this.Delay));
 
var getResultsFunc = this.AutoCompleteQueryResultProvider.GetResults;
var resultsObservable = from searchTerm in textChanged
                        from suggestions in
                            getResultsFunc(new AutoCompleteQuery(searchTerm)).TakeUntil(textChanged)
                        select suggestions; 

Now we just need to subscribe to the resultsObservable and add the query results to our Results collection (which is the ItemsSource for the ListBox):

resultsObservable.ObserveOn(this).Subscribe(
        results =>
        {
            this.Results.Clear();
 
            foreach (var result in results)
            {
                this.Results.Add(result);
            } 
        });

Hooking the Control Up to a ViewModel

The control is ready but it requires an external query provider to work (the AutoCompleteQueryResultProvider). This is now really easy and very view model and test-friendly. Just define a ViewModel like this:

public class RottenTomatoesViewModel : ViewModelBase
{
    public AutoCompleteQueryResultProvider AutoCompleteQueryResultProvider
    {
        get
        {
            return
                new AutoCompleteQueryResultProvider(
                    query => Observable.FromAsync(() => this.SearchRottenTomatoes(query.Term)));
        }
    }
 
 
    private async Task<IEnumerable<AutoCompleteQueryResult>> SearchRottenTomatoes(string term)
    {        
        string address = string.Format(
            "http://api.rottentomatoes.com/api/public/v1.0/movies.json/?apikey={0}&q={1}&page_limit={2}&page={3}",
            "<<<YOURAPIKEY>>>", 
            term, 
            10, 
            1);
 
        var client = new HttpClient(new LegacyJsonMediaTypeConverterDelegatingHandler() 
                                   { InnerHandler = new HttpClientHandler() });
 
        HttpResponseMessage response = await client.GetAsync(address);
        response.EnsureSuccessStatusCode();
        JObject content = await response.Content.ReadAsAsync<JObject>();
 
        var res = new List<AutoCompleteQueryResult>();
        foreach (var movieDescription in content["movies"])
        {
            var movie = new AutoCompleteQueryResult();
            movie.Title = movieDescription["title"].Value<string>();
            movie.Thumbnail = movieDescription["posters"]["thumbnail"].Value<string>();
            res.Add(movie);
        }
 
        return res;
    }
}

Perform a DataBinding in the associated view:

<ctrls:AutoCompleteTextBox
    Grid.Row="1"
    AutoCompleteQueryResultProvider="{Binding AutoCompleteQueryResultProvider}"     
 Margin="10" FontSize="20" PopupHeight="300">      
    <ctrls:AutoCompleteTextBox.ItemTemplate>
        <DataTemplate>
            <Grid Height="100">
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="100"></ColumnDefinition>
                    <ColumnDefinition Width="*"></ColumnDefinition>
                </Grid.ColumnDefinitions>
                <Image Grid.Column="0" Stretch="None" Source="{Binding Thumbnail}"></Image>
                <TextBlock MaxWidth="280" Margin="5 0 0 0" TextWrapping="Wrap" 
                           Grid.Column="1" Text="{Binding Title}"></TextBlock>
            </Grid>
        </DataTemplate>
    </ctrls:AutoCompleteTextBox.ItemTemplate>
</ctrls:AutoCompleteTextBox>

... and the result:

Compared to the solution in the first post, it is very re-usable: Changing the backend just requires a change of the provider function and all the other parts stay the same.

Closing Words

The control is by no means perfect. It does not use the Visual State Manager, it does not support paging nor does it support nice UI candy such as showing the matched string highlighted in the query results. A little spinner animation would also be great... And an error reporting in the UI for remote queries would be nice, too. For the moment I leave these features as an exercise for the happy reader :-) I think as a demo that Rx can also have a place inside a control it has accomplished its purpose.

Source code on SkyDrive and GitHub.

 Some months ago I delivered a Workshop on Reactive Extensions (Rx). If you never heard about Rx, you should read this first.

One little exercise I did with the workshop attendees was to develop a basic auto-complete TextBox that would query an online dictionary service and the results would be shown in the UI. The challenge was derived from the great Rx Workshop on Channel 9. Naturally, the challenge does not focus on developing a re-usable control, but on the Rx aspects.

What we ended with was a simple UI like that used Rx to handle all events:

A Simple Scenario but Some Interesting Challenges

Even if it looks simple to implement an UI that does the job, taking a look at the details reveals some (maybe) unexpected complexity:

• How to do asynchronous service calls? The textbox input should be fed into a service endpoint. As it is the nature of remote endpoints, they won't answer instantly. That is, if we wait for the response on the UI thread our UI will freeze. Not acceptable. Thus we need to perform the endpoint calls asynchronously on a background thread.
• How to we handle minimum input length? Most often it does not make sense to start querying for results when the input is below a certain threshold of characters. For a dictionary search 2 letters might make sense.
• How do we avoid calling the service endpoint for every tiny keystroke? Some users type fast. Really fast. For those users we would like to avoid to create a request for every letter they put into the textbox. Only when a certain timespan of inactivity (300ms for example) is reached, we would like to send out a query to the remote service.
• How do we avoid calling the service when there are no changes in contents? Imagine that a user pastes the same text twice into the textbox or an undo resets the text to the previous contents. In these cases we should avoid doing an extra roundtrip and simply ignore the text changed event.
• How do we avoid mixing up the query result order? When we take the asynchronous approach we have to deal with a very difficult situation. A response to a request might appear out of order. That is another request's response reaches us earlier although the original request was sent later. There is no guarantee of order for us.

The good news is that Rx has for all these challenges some clever solutions.

Utilizing Rx on WPF Events

To transition from a classic event to an Rx Observable we can utilize the Obervable.FromEventPattern method. It allows us to create observable from the TextBox TextChanged Event:

IObservable<EventPattern<TextChangedEventArgs>> textChangedObservable = 

    Observable.FromEventPattern<TextChangedEventArgs>(textBox, "TextChanged");

Looks a bit more complex than hooking a standard event handler, but it will pay off later. Think of Rx as an IEnumerable for events.

With the help of System.Reactive.Linq we can now start to work on this stream of TextChanged events. The first thing I would like to apply is a selection in order to get the thing we really want to deal with from our event stream.

IObservable<string> textChangedObservable = 
    Observable.FromEventPattern<TextChangedEventArgs>(textBox, "TextChanged")
    .Select(evt => ((TextBox)evt.Sender).Text);

 What we now get is a nice stream of the user input that is currently present in the text box. If I would enter the search term "react" each with an individual key stroke the data that would be pushed to the subscriber our textChangedObservable would be the following:

• r
• re
• rea
• reac
• react

Nice. We get the raw input now. Before we fine tune the input handling, let us think about how we can feed this data now into our query service.

Connecting to the Dictionary Service 

The dictionary service is brought in as a web service. The interface (excerpt):

  public DictionaryWord[] MatchInDict(string dictId, string word, string strategy);

and the async counterpart:

public Task<DictionaryWord[]> MatchInDictAsync(string dictId, string word, string strategy);

As you can imagine the synchronous method is nothing we are interested in. Instead we will utilize one of Rx Observable Factory methods that convert a Task into an Observable. An Observable that is based on a Task will produce one result and than completes (or an error):

var queryResultObservable = Observable.FromAsync(
             () => service.MatchInDictAsync("wn", input, "prefix"));

 We make the parameters for the dictId and strategy fixed and use the input as our variable. The goal is that the input is provided from the textbox' event data stream that we created before. How to combine these? With Linq!

var results = from searchTerm in textChangedObservable
              from dictionaryServicesuggestions in ????
              select dictionaryServiceSuggestions;

What basically happens here is that we get updates from the text box text changes pushed into the searchTerm variable. What we want to do with this value is create a new observable for receiving the matching result to that search term. And here is our issue. We cannot just put the queryResultObservable here instead we need a little factory that will create us a new observable for every pushed down searchTerm. Let us introduce a little helper func to fill the gap:

Func<string, IObservable<DictionaryWord[]>> getSuggestions = 
    (term) => Observable.FromAsync(() => service.MatchInDictAsync("wn", term, "prefix"));

 We insert that into our results observable:

var results = from searchTerm in textChangedObservable
              from dictionaryServicesuggestions in getSuggestions(searchTerm)
              select dictionaryServiceSuggestions;

Now we can start observing the results Observable for query results from the dictionary service. If we would like to put them in a WPF ListBox named listBox it could look like this:

results.ObserveOn(listBox).Subscribe(
    words =>
        {
            listBox.Items.Clear();
            foreach (var word in words.Select(word => word.Word).Take(10).ToArray())
            {
                listBox.Items.Add(word);
            }
        });

The ObserveOn method is an extension method that comes with the Rx.WPF helpers. It will make sure that we receive the callbacks for new results on the Dispatcher thread and not on a background thread. We just take out 10 of the words in the result and add them to our listbox.

Fixing Issues 

From our list of challenges we can cross out the first one: we apply asynchronicity already. That is, the UI won't be blocked at any time by calling out to the remote dictionary service. However, there four other things are not addressed at the moment. Let us start to fix the minimum required input. We do not want to call the service before at least four characters are present in the textbox. To achieve that we simply apply a Where constraint to the textChangedObservable:

var textChangedObservable = Observable
    .FromEventPattern<TextChangedEventArgs>(textBox, "TextChanged")
    .Select(evt => ((TextBox)evt.Sender).Text)
    .Where(text => text != null && text.Length >= 4);

This really shows the power of Rx. But it is getting even better. Let us make sure that we do not query the service if the actual value in the textbox has not changed. Here Rx' DistinctUntilChange comes handy:

var textChangedObservable = Observable
    .FromEventPattern<TextChangedEventArgs>(textBox, "TextChanged")
    .Select(evt => ((TextBox)evt.Sender).Text)
    .Select(timestampedText => timestampedText.Value)
    .Where(text => text != null && text.Length >= 4)
    .DistinctUntilChanged();

 And finally let us make sure that the text changes do not trigger service calls too frequently. We apply Rx' Throttle:

var textChangedObservable = Observable
    .FromEventPattern<TextChangedEventArgs>(textBox, "TextChanged")
    .Select(evt => ((TextBox)evt.Sender).Text)
    .Throttle(TimeSpan.FromMilliseconds(200))     
    .Select(timestampedText => timestampedText.Value)
    .Where(text => text != null && text.Length >= 4)
    .DistinctUntilChanged();

The textChangedObservable is looking great now. The constraints help us to do diligent on resources. One last thing though - and this is the nasty one. We need to make sure that the pending request events are discarded properly once a new search term in pushed down from the textChangedObservable. Lucky us, Rx can deal with that, too by applying TakeUntil. TakeUntil takes an IObservable as its parameter and will hold on to the decorated observable until the parameter observable publishes a new value. In this case we will simply hold on the dictionary result observable until a new input has been accepted: 

var results = from searchTerm in textChangedObservable
                from dictionaryServiceSuggestions in getSuggestions(searchTerm)
                .TakeUntil(textChangedObservable) 
                select dictionaryServiceSuggestions;

Summary

 All well and good but not re-usable. What I would like to strive for is something like this - a reusable TextBox control:

 ... one that you can easily feed with the right connections from a ViewModel and use in various scenarios. But that's a topic for the second blog post in this series. The source code so far can be downloaded from SkyDrive. I added lots of debug output to the observables to ease understanding the process. The final version is availble on GitHub. See part 2 of the blog post for details.

What is an attached behavior?

From a high level perspective attached behaviors allow you to write a snippet of code that can add additional features to a WPF control without doing something that drastic as inheriting from an existing control class. As we all know inheritance should not be the default reaction to adding behavior to a class. Most often better results can be achieved in adding additional functionality via composition. And this is the approach of attached behaviors.

How do I build an attached behavior?

Two options: Build it from scratch or use a nice and simple SDK from the Blend team. This SDK allows you to build an attached behavior in a very straight forward manner. If you have VS2012 with Update 2 installed, you should find the System.Windows.Interactivity.dll assemby per default in "C:\Program Files (x86)\Microsoft SDKs\Expression\Blend\.NETFramework\v4.5". In earlier versions it is located in the Expression Blend installation folder. Many WPF developers seem to be unaware of this little gem so I would like to advertise it a bit by showing you a brief example.

The out-of-the-box WPF TextBox control has no property that can be changed to trigger the complete selection of the TextBox's text when a user navigates, e.g. with the TAB key, into that TextBox. When a user is required to enter a couple of input fields on a form this feature is often requested. An initial thought might be: OK, let us create a SelectAllTextBox that derives from the TextBox class and introduces a new property to enable that behavior. The alternative is as follows:

• Declare a normal TextBox in XAML that should be decorated with additional behavior
• Declare an external class (i.e. our attached behavior class) that extends the features of the TextBox control by using the TextBox instance's events and properties.
• Finally, hook the TextBox that needs additional functionality with the attached behavior.

The first step is straight forward - we just declare a TextBox control in XAML:

<StackPanel>
    <TextBlock>TextBox without behavior:</TextBlock>
    <TextBox>this is text</TextBox>
</StackPanel>

The second step requires us to define a new class - our attached behavior. To get a basic infrastructure that eases our development and wires things up seamlessly we need to implement a class that derives from the abstract base class Behavior<T> which is defined in the Blend SDK:

using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Interactivity;
 
public class SelectAllTextBoxBehavior : Behavior<TextBox>
{
    /// <summary>
    /// Called after the behavior is attached to an AssociatedObject.
    /// </summary>
    /// <remarks>Override this to hook up functionality to the AssociatedObject.</remarks>
    protected override void OnAttached()
    {
        base.OnAttached();
    }
        
    /// <summary>
    /// Called when the behavior is being detached from its AssociatedObject, but before it has actually occurred.
    /// </summary>
    /// <remarks>Override this to unhook functionality from the AssociatedObject.</remarks>
    protected override void OnDetaching()
    {
        // Recommended best practice: 
        // Detach the registered event handler to avoid memory leaks.
        base.OnDetaching();
    }
}

Blend's base class provides us two hooks and - most important - a property called AssociatedObject. This property will contain a reference to the control that is decorated with our behavior. The OnAttached and OnDetached hooks define the life cycle where our behavior is brought into play and is removed. In our small example we are interested in getting informed about focus changes of the TextBox. Let us extend the OnAttached method accordingly:

/// <summary>
/// Called after the behavior is attached to an AssociatedObject.
/// </summary>
/// <remarks>Override this to hook up functionality to the AssociatedObject.</remarks>
protected override void OnAttached()
{
    base.OnAttached();
    this.AssociatedObject.GotFocus += this.OnTextBoxGotFocus;
}

We wanted to be able to select all Text as soon as the TextBox receives focus. Luckily there is a SelectAll method defined that we can use to select the complete text in a TextBox  In consequence, the code inside the event handler could look like this:

/// <summary>
/// Handles the GotFocus event of the TextBox control.
/// </summary>
/// <param name="sender">The source of the event.</param>
/// <param name="e">The <see cref="RoutedEventArgs" /> instance containing the event data.</param>
private void OnTextBoxGotFocus(object sender, RoutedEventArgs e)
{
 this.AssociatedObject.SelectAll();
}

 (Important: The code so far would actually not behave completely as expected - edge cases like mouse selection would not work. The full sample code attached to this post handles that.) 

To be a nice citizen we should clean up after our selves in case the behavior is dynamically removed from the targeted TextBox at runtime. Leaving a dangling event handler could introduce a memory leak. So finally we should also take care in putting some clean-up code into the OnDetaching method:

protected override void OnDetaching()
{
    // Recommended best practice: 
    // Detach the registered event handler to avoid memory leaks.
    this.AssociatedObject.GotFocus -= this.OnTextBoxGotFocus;
    base.OnDetaching();
}

 The final step is the registration of the Behavior. We could do it in code or (most often) declaratively in XAML:

[...] xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity" [...]

<StackPanel>
    <TextBlock>TextBox with behavior:</TextBlock>
    <TextBox>this is text
        <i:Interaction.Behaviors>             <local:SelectAllTextBoxBehavior></local:SelectAllTextBoxBehavior>
        </i:Interaction.Behaviors>
    </TextBox>
</StackPanel>

 That's it - all is hooked up now!

Download Source

The complete source code can be downloaded from SkyDrive.

Want to know more about Attached Behaviors?

Josh Smith has an exhaustive article about Attached Behaviors on Codeplex.  

The #InnoJam (more background here) is a prequel session to SAP's TechEd and provides the possibility for attendees to work in teams (~8 members each) on innovative ideas around various scenarios. Here are two examples of the five challenges that were tackled at the InnoJam in Madrid:

• Better my journey. Teams that took this challenge thought about redesigning the service experience for commuters and city inhabitants in the context of getting around in the city. Especially the personalization aspect of this challenge was interesting.
• Ad-hoc parking lots. Teams that took this challenge thought about redesigning the service experience for visitors of the city or big events in the context of finding free parking lots.

The whole event spanned over two days (and the night in between :-)) and started with a design session where each team worked on fine tuning their ideas around their chosen scenario. During this phase innovation trainers helped the teams in the design thinking process and in developing a great story and business case around their scenario. In the late afternoon of the first day all teams had a short presentation of their project and from there they went straight into the implementation phase. A picture is worth more than 1k words (look out for the number of post-its and brown paper drawings at the wall - that's only 1/3 of the impressive output, more pictures here):

The implementation challenge encompassed the whole spectrum from backend to (mobile) front-ends. And this is were Windows 8 came into play. We brought a big bag of new and shiny Windows 8 devices with us and helped those teams that wanted to work on Windows 8 to develop apps for their scenarios. Especially our strengths in providing a modern UI and in connecting to SOAP web services, OData and REST services were a great fit to reach out to SAP solutions. Another cool thing that helped us a lot is our TFS in the cloud. You can spin up a source control in seconds - really important to parallelize the development efforts. We also received a lot of praise for the great integration of TFS in Visual Studio. Even devs that were new to our platform picked it up easily and enjoyed it a lot.

One of the teams that we supported throughout the event was team #parkit. They were working on a solution for finding ad-hoc parking lots. Together with team #parkit we built an app in roughly 18h that utilized Bing maps to route app users to a free parking lot by connecting to their SAP ByDesign web service that was build up in parallel and provided information about parking slot positions and their availability. The app featured additional customizations for the user such as setting weights for preferring parking slots with less costs or at a closer distance. To give you an impression this screenshot shows the hub screen of the app:

A big kudos to the #parkit team - they rocked and became one of the two winner teams at the InnoJam. And to top all this, they placed 3rd in the overall DemoJam of the TechEd. Great job guys! You can watch a recording here: http://www.sapvirtualevents.com/teched/sessiondetails.aspx?sId=3842.

From what I learned and saw at the InnoJam I can only recommend everybody who is working on SAP solutions to visit one if you have the opportunity to do so. You will find a diverse crowd of cool people with a lot of drive and different backgrounds. Project managers, technical experts, devs and even sales people - all locked up in a room with lots of caffeine, good food and (late at night) beer :-) What could you wish more?

The development events are vast: introduction events, more in-depth events and even Hackathons.

By the way - similar programs are also running outside of Germany. Just get in contact with your local Microsoft Developer Platform Evangelist - I am sure that they can help you.

• The vast majority of developers appreciates the possibilities that Windows 8 provides. There is a huge awareness that a completely new market becomes available and the reach of the platform is growing from Desktop to mobile (slate/pad) devices.
• Obviously, there are many questions around WinRT, application architecture, metro style design and also a few around hardware extensibility or custom driver support.

The first observation makes me happy since this will be one important driver for getting a lot of high quality apps into our market place. The second observation underlines how important these sessions are to clarify misunderstandings and also to receive first-hand feedback.

Hint: A very good resource on getting started with metro style app design is http://design.windows.com. It does not solely discuss pixels or grids but also the philosophy of information architecture that will be central to most Metro apps.

In the next weeks and months DPE will host more sessions on Windows 8 in various places. In Germany there will be sessions in Karlsruhe, Munich, Hamburg, Cologne and Berlin. Unfortunately, all sessions are already fully booked. But there is a waiting list! And as soon as I receive information on more events I’ll post it!

Apart from the Windows 8 sessions in the Microsoft “Entwickler-Forum” (developer panel) in exhibition hall 8, visiting the main stand in hall 4 was really impressive. Not only in terms of size but also in terms of the crowd that gathered around the stage:

Due to my schedule I wasn’t able to attend most of the talks at the center stage but a personal highlight was definitely the AntMe session. I am a big fan of getting kids early into programming so if you don’t know it and your kids are interested in the area - go and give it a try!

As a PFE I am part of the strategy, consulting, and support division of Microsoft and thus I am working directly with our customers.The Premier support is a special support contract that offers a 24x7 subject-matter-expert support to our customers. Premier service is further structured into areas like Premier Support for Proactive Services or Premier Support for Global and Enterprise Customers. My area is the Premier Support for Developers which offers our customers services around software engineering and software development, for example on-site workshops for specific Microsoft products or frameworks, troubleshooting and developer coaching.

What contents will you find in this blog? It is hard to predict the future but plans are that I’ll talk a lot about software engineering, .NET and Windows 8 Metro development. Enjoy your stay!