The scenario is that we have a list of items displayed in a list (ListView on Android and UITableView on iOS). The ItemSource comes from a web service. In addition to the da
Your UI list item cell has a DataContext that its controls bind to - that DataContext is the cell's own individual ViewModel.
MvvmCross doesn't (as of v3.1 today) let you look outside that DataContext - it doesn't let you (for example) inspect another UIElement's DataContext or doesn't let you ask for a Parent.
To work within this, I generally create my DataContext for my list item cell's so that they contain all the data and actions that those cells need - so that they are genuinely the ViewModel for the list item view. Where there is some convenient Model class to reuse, then this will often mean that I create a wrapper class to assist with the DataContext. Occasionally (rarely) I will do this in a ValueConverter (see below)*, but in general I will do this using wrapper classes exposed by the ViewModel instead.
For example, for something like your case, if I had a List<Foo> as my core model, then in the page level ViewModel I would create a FooWithSelectionState class:
public class FooWithSelectionState : MvxNotifyPropertyChanged
{
public Foo Foo { get; set; /* normal INPC in here */ }
public bool IsSelected { get; set; /* normal INPC in here */ }
}
This would then allow my ViewModel to expose a List<FooWithSelectedState> as a Property - and individual list item cells can then bind to IsSelected as well as to chained properties of the underlying object like Foo.Name.
Architecturally, this pattern is robust, it's testable, it's clean and it's "correct" in that each list item cell has its own well-defined ViewModel. However, I do understand it can feel a bit code-heavy - it can feel a bit overkill. In some cases, dev's just want to use the Model classes directly without a ViewModel step. Maybe in some future version of Mvx, then MvvmCross might add some alternative mechanism to allow DataBound UI elements to look outside of their own DataContext - this has been suggested in e.g. https://github.com/MvvmCross/MvvmCross/issues/35 - but today this doesn't exist (that I know of)
If you did want to use the ValueConverter route, then one way of doing this is to use a ValueConverter on the ItemsSource - for example, something like:
public class FooWrappingValueConverter : MvxValueConverter<IList<Foo>, IList<FooWithSelectionState>>
{
protected override IList<FooWithSelectionState> Convert(IList<Foo> value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
var viewModel = parameter as MyViewModel;
return value.Select(f => new FooWithSelectionState()
{
Foo = f,
IsSelected = viewModel.IsSelected(f)
})
.ToList();
}
}
This could be used in binding with an expression like ItemsSource FooWrapping(SourceList, .) - but be careful using this in dynamic situations (where the list changes frequently) as this could be slow.