Wpf, Resources and DataContext

One of the frustrating things in WPF is that objects in the Resources Collection can't see the DataContext from their containing control. It makes sense when you think about it as they are not within the Logical / Visual Tree, which Dependency Properties can inherit down. Whilst it doesn't normally affect me, today I came across a need to have this.

I've just worked on a view where we want to expose a collection in a next-previous way, and expose a 'CurrentItem' property. Whilst we could have done it in our ViewModel, in our scenario we don't want the ViewModels becoming aware of the next / prev, and just to be aware that they are given a list of items, and one of them is selected.

I went down the approach of a control which inherited from FrameworkElement as it had a DataContext then put it in the Resources Collection. Of course this didn't work as as we said at the beginning, stuff in the Resources cannot access the DataContext. BUT back up a minute... there is a control which seems able to do this - the CollectionViewSource. How does it do it? Heh heh, Reflector revealed the internal hack which MS used to somehow ram the inheritence of DP's into this unsuspecting class.

Nasty, but it just so happens we can exploit this for our own purposes. CollectionViewSource wraps a collection which it can obtain by binding to the DataContext, and it is not marked as sealed so we can extend it and add our own behaviour.

What I ended up doing was subclassing CollectionViewSource and adding a NextCommand, PreviousCommand, and SelectedItem dependency property to my subclass. (side note - we use a OneWayToSource binding to reverse the SelectedItem back onto the ViewModel we can bind to a standard .Net property on the ViewModel).

All sounds good, but there was one more issue. The CollectionViewSource is a bit of a liar, in that when you bind to it, you don't actually bind directly to it, but instead to the Collection it exposes. It makes for a nicer syntax in that 99% of times you use it, all you are interested in is that exposed collection. For us though we need to drill into our actual class to get at our subclasses properties. That's where that strange property on Binding, BindsDirectlyToSource comes in. It lets us probe past that outer facade of the class and get into the real object.

Our code is not far off being acceptable now. It looks something like:

<SummaryContentActionView> <!-- the scaffolding view which uses a template to define the layout -->

<SummaryContentActionView.Resources>
<NextPreviousCollection x:Key="col" Items="{Binding Contract.Items}" SelectedItem="{Binding SelectedItem, Mode=OneWayToSource}" />
</SummaryContentActionView.Resources>

<SummaryContentActionView.MainContent> <!-- object DP exposed from the scaffold contol -->
<StackPanel>
<Button Command="{Binding Source={StaticResource col}, Path=NextCommand, BindsDirectlyToSource=True}" />
</StackPanel>
</SummaryContentActionView.MainContent>


</SummaryContentActionView>

Fun with NHibernate QueryOver and Linq provider

Given the following classes:

Blog
{
  Guid Id
  List<Post>
}

Post
{
  Guid Id
  Name
}

What's the best way to fetch a list of Blog ID's against the count of posts. Without going into HQL I've so-far got 2 ways, one using the Criteria (QueryOVer - nH3.0) and one using the NH linq provider. On a tiny database the results are quite interesting.

QueryOver needs to use a detached criteria and sub-select to get the results we need: we have to create 2 aliases, one for the select count bit of the query, and one to select over blog posts. We use a little trick with aliases to correlate the inner query to the outer query (correlated queries).

                Blog outerBlogAlias = null;
                Blog innerBlogAlias = null;

                var innerQuery =
                    (QueryOver<Blog, Blog>)session
                        .QueryOver(() => innerBlogAlias)
                        .Where(() => outerBlogAlias.Id == innerBlogAlias.Id)
                        .Inner.JoinQueryOver(o => o.Posts)
                        .ToRowCountQuery();

Did you catch the alias bit – QueryOver(() => innerBlogAlias) – the clever bit is we can reference the alias used in the outer query following to correlate the two. That’s the line which reads .Wher(() => outerBlogAlias.Id == innerBlogAlias.Id). 

                var outerQuery =
                    session.QueryOver(() => outerBlogAlias)
                    .Select(
                        list =>
                            list
                            .Select(o => o.Id)
                            .SelectSubQuery(innerQuery));

This is the outer query – look how we use .SelectSubQuery(innerQuery), to capture the count of all the children posts in the main select statement. Neat huh?

OK, wanna see the same in linq-nhibernate…

var results2 = session.Query<Blog>()
    .Select(o => new
                     {
                         Id = o.Id,
                         PostCount = o.Posts.Count
                     })
                     .ToList();

Done! And it even creates an anonymous class to hold the results. The interesting bit is the generated query. The QueryOver actually has to join Blog –> Posts. As a Post doesn’t hold a back reference to a Blog I can’t think of a better way to do this (other than changing the domain model which may or may not be acceptable). No such drama with the linq version though. It goes straight to the Posts table.

The lack of the extra join in a table with ooo, 8 posts, means that the QueryOver takes 61% of the query time (in sql), whilst the linq version only sucks up 39% of the overall time. Sql’s query plan for the QueryOver version shows that Sql Serve has to perform more work.

So what’s my conclusion – it’s that linq-nh, and queryover, are both really cool powerful query mechanisms. Each can do things the other can’t do, and you should not discount either of them up-front. Use the right query tool for the right job… And of course I should take my own advice and learn HQL as-well! For the record the reason I haven’t is that both QueryOver and Linq-NH are type-safe which is something I really like.

C# to iPhone Objective-C

This set of blog posts is more for my own memory than anything else. I’m playing with iPhone development and wanted to draw similarities as-well as write down things I learn whilst getting to grasp with Objective-C.

So here we go. Let’s start at the beginning by looking at some core differences between the 2. The order might be a bit rambling but that’s just me writing stuff down that drops into my head! Soon I’ll try get onto the more visual aspects of iphone development but I think it’s essential to get your head around how to structure objective-c code before diving into guis.

For the record I learnt a lot from Dr Google, and this website was especially good: http://www.otierney.net/objective-c.html

1. Almost everything is a pointer.

To ‘create’ an instance of an object in Objective-C we tend to have 2 choices. The first involves ‘allocating’ memory for the object then ‘initialising’ it in some way. The 2nd involves calling a factory (think static) method on a class.

Whichever we do what we end up with is a pointer to an object. In Objective-C we must explicitly show this by using the * character. So to create an NSString object (a fairly core object) we can say:

NSString* myString = [NSString alloc];

more on the syntax in a minute.

To create the string object with a value:

NSString* myString = [[NSString alloc] initWithString: @”Hello” ];

Or you can say:

NSString* myString = [NSString stringWithString: @”Hello”];

The 1st two use instance methods on the NSString to initialize it. The 2nd uses a factory method to create the string. The main difference between the 2 is that by explicitly allocating the string (the 1st way) you are responsible for releasing the memory. With the 2nd way you aren’t. I’ll leave the specifics for another post as it deserves more time!

2. Calling a method on an object.

In C# / Java this is done via the dot (.) notation. So to call method Foo on object bar we say bar.Foo(). If we want to pass parameters to this method call we put them inside the parenthesis. So bar.Foo(someParameter);

Objective-C talks in terms of messages instead of method calls but for this example lets think of them as the same sort of idea. There are reasons for this as we’ll see soon. The syntax is weird at first sight -

[bar Foo];

means the same as bar.Foo(); in C# and

[bar foo: someParameter]

is the equivalent of bar.Foo(someParameter);

As you can see Objective-C looks a bit confusing at 1st sight especially if you’ve used C# Attributes before which use a square bracket notation.

3. Declaring a method on an object.

Objective-C uses Interface (header) files to declare members, methods, properties etc. that will appear in the class body. So you have 2 files. A .h and a .m file.

To declare a method we must add its signature to the .h file, and the contents of it to the .m file. Using the Foo.Bar(someParameter method) we end up with:

.h file

- [void] Bar: (NSString*) theParameter

.m file

- (void) Bar: (NSString*) theParameter

{

   //do something

}

In a nutshell

the minus sign denotes an instance method rather than a class (static) method which would use a + sign.

[void] is the return value. In this case my method returns nothing.

Bar is the name of the method (followed by colon if there are parameters).

Then come the parameters. In this case I’m asking for an NSString* where the * means a pointer. Objective-C pretty much uses pointers for everything other than primitive values (int, float, etc). So-far (heh heh caveat alert) I haven’t seen a pointer being de-referenced explicitly as in C++.

To send multiple parameters is a bit weird:

- (void) setLatitude: (int) latitude andLongitude: (int) longitude
{
}

This method requires 2 integers. ‘latitude’ and ‘longitude’. To call this method we’d write:

[myFoo setLatitude: 98 andLongitude: 50];

Looks a bit bizarre huh?!

OK that’s enough for today. Next time I’ll try write about some other fundamentals – especially memory management (iphone’s version of Objective-C doesn’t have Garbage Collection).