maui-data-binding

Set x:DataType at the page root where BindingContext is assigned and inside every DataTemplate, which creates its own binding scope. Avoid scattering x:DataType on child elements, and add XC0022 and XC0025 to WarningsAsErrors in the csproj to catch binding errors at build time.

CommunityToolkit.Mvvm ObservableObject is recommended because its source generator creates properties, PropertyChanged raising, and RelayCommand automatically from attributes. Manual INotifyPropertyChanged works but requires boilerplate property setters that raise PropertyChanged events.

Only specify Mode when overriding the control's default. Most display properties default to OneWay and editable controls like Entry.Text default to TwoWay, so adding Mode=OneWay or Mode=TwoWay explicitly is redundant noise.

Common causes are a missing BindingContext, a ViewModel that does not implement INotifyPropertyChanged, or binding to non-public properties. Also verify x:DataType is set so XC0022 warnings surface unresolved binding paths at compile time.

PropertyChanged events are automatically marshaled to the UI thread, but direct ObservableCollection Add or Remove calls from background threads may crash. Wrap collection mutations in MainThread.BeginInvokeOnMainThread to stay safe.

Use dedicated skills for CollectionView item templates and layouts, Shell navigation parameter passing, or dependency injection setup. Property-change-triggered animations should use the built-in .NET MAUI animation APIs instead.