How not to highlight alternate items in a virtualised list

It's a common requirement: highlighting alternate items in a list. There are various reasons for wanting to do this and almost infinite ways to visually represent the highlighted item.

As I've been asked to show an example of how to do this right, I present this simple example.

Grab the full source.

Here's all the CS.

And here's the corresponding XAML.




This code is for a page containing a pivot with 2 items. The first contains a ListBox using the "BadConverter" and the second contains a LongListSelector using the "GoodConverter". The same view model is bound to both lists.

The simple way to do the highlighting is with a converter. In the bad example the converter uses it's own reference to keep track of which items to highlight. (It just alternates the color that it applies to the items as they are realized.) The good example always applies the color based on a property of the item. This will always be the same for each item.
This means that if the lists are scrolled quickly the bad list may end up highlighting items in an order different to the one they are displayed in but the good list will always be highlighted based on the identifying property of the items, assuming that the items are in the correct order.

Obviously there are some assumptions in the above that it's probably good to make clear:

• The use of a LongListSelector is only to help remind that the ListBox is deprecated in favor of the LongListSelector.
• The "Id" property is used exclusively for determining the highlighting color. It has no other value. If the underlying property has an "Id" property that represents something else and might not always be in a sequential order, with no gaps, then creating another property ("PositionInList"?) for this purpose would be appropriate.
• The values of the "Id" property could just be "1" and "2" repeatedly. For this example they don't need to increment.
• The "Entry" class could have a property that returns a color and this could be bound to the display. This probably couple the display logic to the underlying view model too strongly. MVVM purists will have very strong objections to this ;)

I hope this helps.