There are a couple different ways you could do it. It depends on how pervasive you want the concept to be in the app. Probably the most straightforward way to do this is to just do it at the UI layer
(i.e. don’t bother messing with the Contigo project or the FacebookPhotoAlbum/FacebookPhoto classes)
In Fishbowl/Resources/Themes there are a few XAML files that describe the different pages for photos and albums:
GalleryHomeResources.xaml is the page you see when you click the Photos tab at the top of the window.
PhotoAlbumResources.xaml is the album summary page that displays a full album with the photos spread out in a wrap panel.
PhotoViewerResources.xaml is the individual photo viewing page (this one has 3 different templates for displaying photos which are triggered based on window size).
You can probably trigger the visualizations in the UI for any of those views using Converters. You can create a statically accessible object that’s a lookup table for which objects have been tagged
as favorites. If it supports INotifyPropertyChange then if you bind to it in the XAML it will cause your triggers to get reevaluated so it will update when you change state.
For coherence with the existing app infrastructure, you may want to leverage View/ActionCommands.cs and just add another there that exposes commands that work against your lookup table.
Alternatively you can build the notion into Contigo on the raw data objects (Friends’ interest level is implemented this way), but I think that may be more work and since it’s at a lower level it’s
just a deeper change. The UI would then just be triggered from a property you’d expose of the objects, rather than through a converter and a dictionary. If you go with this approach then you can use FacebookContact.InterestLevel as an example
of what would be involved, but exposing filtered collections gets complicated and it’s easy to accidentally do it in a way that causes bad performance characteristics or race conditions.
Hope that helps,