diff --git a/doc/Overview/Mvux/Assets/MvvmWeather.jpg b/doc/Overview/Mvux/Assets/MvvmWeather.jpg
new file mode 100644
index 0000000000..d2e6f720ef
Binary files /dev/null and b/doc/Overview/Mvux/Assets/MvvmWeather.jpg differ
diff --git a/doc/Overview/Mvux/Assets/MvvmWeatherUpdated.jpg b/doc/Overview/Mvux/Assets/MvvmWeatherUpdated.jpg
new file mode 100644
index 0000000000..55489f391a
Binary files /dev/null and b/doc/Overview/Mvux/Assets/MvvmWeatherUpdated.jpg differ
diff --git a/doc/Overview/Mvux/Overview.md b/doc/Overview/Mvux/Overview.md
index a53a7da3e6..4149d79ddb 100644
--- a/doc/Overview/Mvux/Overview.md
+++ b/doc/Overview/Mvux/Overview.md
@@ -4,121 +4,362 @@ uid: Overview.Mvux.Overview
# MVUX Overview
-**M**odel, **V**iew, **U**pdate, e**X**tended (**MVUX**) is an evolution of the MVU design pattern, that encourages unidirectional flow of immutable data. MVUX supports data binding, bringing together the best of the MVU and MVVM design patterns.
+**M**odel, **V**iew, **U**pdate, e**X**tended (**MVUX**) is an implementation of the Model-View-Update design pattern, that encourages the flow of immutable data in a single direction. What differentiates MVUX from other MVU implementations is that it has been designed to support data binding.
-MVUX uses a source code generator to generate bindable proxies for each Model. Additional bindable proxies are generated for other entities where needed.
-Bindable proxies are used as a bridge that enables immutable entities to work with the Uno Platform data-binding engine.
+## Why MVUX?
-Changes in the bindable proxies result in parts of the Model being recreated, rather than changing properties. This ensures the Model is immutable, and thus eliminates a large set of potential exceptions and issues related to mutable entities.
+To better understand the need for MVUX, let us consider a weather application that will display the current temperature, obtained from an external weather service. At face value, this seems simple enough. All the app has to do is call a service to retrieve latest temperature and display the returned value.
-## Learning MVUX by samples
+### Weather App Example - MVVM
-To better understand MVUX, let us consider a weather application that will display the current temperature, obtained from an external weather service. At face value, this seems simple enough: call service to retrieve latest temperature and display the returned value.
+For example, using a Model-View-ViewModel (MVVM) approach, the following `MainViewModel` initializes the `CurrentWeather` property with the information obtained from the weather service. The XAML binds the `CurrentWeather` property of the `DataContext` (an instance of the `MainViewModel`) to the Text property of a TextBlock
-Although this seems like an easy problem, as is often the case, there are more details to consider than may be immediately apparent:
+# [MainViewModel](#tab/viewmodel)
-- What if the external service isn't immediately available when starting the app?
-- How does the app show that data is being loaded? Or being updated?
-- What if no data is returned from the external service?
-- What if an error occurs while obtaining or processing the data?
-- How to keep the app responsive while loading or updating the UI?
-- How do we refresh the current data?
-- How do we avoid threading or concurrency issues when handling new data in the background?
-- How do we make sure the code is testable?
+```csharp
+public partial class MainViewModel : ObservableObject
+{
+ private readonly IWeatherService _weather;
-Individually, these questions are simple enough to handle, but hopefully, they highlight that there is more to consider in even a very trivial application. Now imagine an application that has more complex data and user interface, the potential for complexity and the amount of required code can grow enormously.
+ [ObservableProperty]
+ private WeatherInfo? _currentWeather;
-MVUX is a response to such situations and makes it easier to handle the above scenarios.
+ public MainViewModel(IWeatherService Weather)
+ {
+ _weather = Weather;
+ _ = LoadWeather();
+ }
-## WeatherApp Sample
+ private async Task LoadWeather()
+ {
+ CurrentWeather = await _weather.GetCurrentWeather();
+ }
+}
+```
+The `ObservableObject` comes from the [`CommunityToolkit.Mvvm`](https://www.nuget.org/packages/CommunityToolkit.Mvvm) package and provides an implementation of the [`INotifyPropertyChanged`](https://learn.microsoft.com/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.inotifypropertychanged) interface, which is used to notify the UI when property values change. The `ObservableProperty` attribute (also from the `CommunityToolkit.Mvvm` package) is used to instruct the source code generator to emit properties that include raising the `PropertyChanged` event when the value changes. In this case the `CurrentWeather` property is generated, from the `_currentWeather` field, and will raise the `PropertyChanged` event when the value is set in the `LoadWeather` method.
-You can find the code for our weather app here: https://github.com/unoplatform/Uno.Samples/tree/master/UI/MvuxHowTos/WeatherApp
+# [MainPage](#tab/page)
-## What is MVUX?
+```xml
+
+
+
+
+
+
+
+
+```
+The DataContext on the MainPage is set to be an instance of the MainViewModel
-MVUX is an extension to the MVU design pattern, and leverages code generation in order to take advantage of the unique data-binding engine of WinUI and the Uno Platform.
+```csharp
+public MainPage()
+{
+ this.InitializeComponent();
-### Model
+ DataContext = new MainViewModel(new WeatherService());
+}
+```
+----
+Here's this simple application running:
+![Mvvm Weather App](Assets/MvvmWeather.jpg)
+
+
+The code required to call the `GetCurrentWeather` and displaying the resulting `Temperature` using XAML is simple enough. However, there are a few things we should consider:
-The **Model** in MVUX is similar in many ways to the viewmodel in MVVM. The **Model** defines the properties that will be available for data binding and methods that include any business logic. In MVUX this is referred to as the **Model**, highlighting that it is immutable by design.
+- If the `GetCurrentWeather` method takes a finite amount of time to complete, what should be displayed while the app is waiting for the result?
+- If the `GetCurrentWeather` service fails, for example due to network issues, should the app display an error?
+- If the `GetCurrentWeather` service returns no data, what should the app show?
+- How can the user force the data to be refreshed?
-For our weather app, `WeatherModel` is the **Model**, and defines a property named `CurrentWeather`.
+The previous example has been updated in the following code to addresses these points. As you can see the updated code is significantly more complex than the original code.
+
+# [MainViewModel](#tab/viewmodel)
```csharp
-public partial record WeatherModel(IWeatherService WeatherService)
+public partial class MainViewModel : ObservableObject
{
- public IFeed CurrentWeather => Feed.Async(this.WeatherService.GetCurrentWeather);
-}
-```
+ private readonly IWeatherService _weather;
-The `CurrentWeather` property returns a feed (`IFeed`) of `WeatherInfo` entities (for those familiar with [Reactive](https://reactivex.io/) this is similar in many ways to an `IObservable`). When the `CurrentWeather` property is accessed, an `IFeed` is created via the `Feed.Async` factory method, which will asynchronously call the `GetCurrentWeather` service.
+ [ObservableProperty]
+ private WeatherInfo? _currentWeather;
-### View
+ [ObservableProperty]
+ private bool _isError;
+
+ [ObservableProperty]
+ private bool _noResults;
+
+ public MainViewModel(IWeatherService Weather)
+ {
+ _weather = Weather;
+ LoadWeatherCommand.Execute(default);
+ }
+
+ [RelayCommand]
+ public async Task LoadWeather()
+ {
+ try
+ {
+ IsError = false;
+
+ CurrentWeather = await _weather.GetCurrentWeather();
+ NoResults = CurrentWeather is null;
+ }
+ catch
+ {
+ IsError = true;
+ }
+ }
+}
+```
+`IsError` and `NoResults` properties are generated from the `_isError` and `_noResults` fields respectively. The `LoadWeather` method now has the `RelayCommand` attribute (also from the `CommunityToolkit.Mvvm` package) which will generate an [`ICommand`](https://learn.microsoft.com/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.input.icommand), `LoadWeatherCommand`. The `LoadWeatherCommand` implementation also includes an `IsRunning` property that returns true when the `ICommand` is being executed. The `IsError`, `NoResults` and `IsRunning` properties are used to control the visibility of the UI elements in the XAML.
-The **View** is the UI, which can be written in XAML, C#, or a combination of the two, in the same way that you would if you were using another design pattern. For example, the following can be used to data bind the `Text` property of a `TextBlock` to the `CurrentWeather.Temperature` property.
+# [MainPage](#tab/page)
```xml
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
```
+The XAML includes four visual states which are triggered based on the value of `IsError`, `NoResults` and `LoadWeatherCommand.IsRunning`. The `Get Weather` Button is data bound to the `LoadWeatherCommand`, which will invoke the `LoadWeather` method when the Button is pressed.
+
+----
+
+Here's the updated application running, showing the progress ring in action while the data is loading and a Get Weather Button for refreshing the data.
+
+![Mvvm Weather App](Assets/MvvmWeatherUpdated.jpg)
+
+This simple example illustrates how quickly simple code can grow in complexity when we consider the various states that an application can be in.
+
-This XAML data binds the `Text` property on the `TextBlock` to the `CurrentWeather.Temperature` property on the `DataContext` of the page. In other words, the `CurrentWeather` property is retrieved from the `DataContext`. If the resulting object is not null, the `Temperature` property is retrieved and used to set the `Text` property on the `TextBlock`.
+### Weather App Example - MVUX
-What's unique to MVUX is the additional information that `IFeed` exposes, such as when data is being loaded and whether there was an error loading the data. For this, we can leverage the MVUX `FeedView` control.
+With Model-View-Update-eXtended (MVUX) we can simplify this code, making it easier to maintain and less error prone. Let's take a look at an equivalent weather application written using MVUX.
+
+# [MainModel](#tab/model)
+
+```csharp
+public partial record MainModel(IWeatherService WeatherService)
+{
+ public IFeed CurrentWeather => Feed.Async(this.WeatherService.GetCurrentWeather);
+}
+```
+The `MainModel` (as distinct from the `MainViewModel` used in the MVVM example) includes a single `CurrentWeather` property that exposes an `IFeed` that will call `GetCurrentWeather` to retrieve the current weather. The `IFeed` interface is used to represent a stream, or sequence, of values that are loaded asynchronously.
+
+# [MainPage](#tab/page)
```xml
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
```
+The `DataContext` on the `MainPage` is set to be an instance of the `BindableMainModel`, which is a bindable proxy for the `MainModel` that is generated by MVUX to provide data binding support to the `MainModel`.
-The `FeedView` control is designed to work with an `IFeed`, and has visual states that align with the states that an `IFeed` can be in (e.g. loading, refreshing, error, etc.). The above XAML defines the `ValueTemplate`, which is required in order to display the `Data` from the `IFeed`. Other templates include `ProgressTemplate`, `ErrorTemplate` and `NoneTemplate`, which can be defined in order to control what's displayed depending on the state of the `IFeed`.
+```csharp
+public MainPage()
+{
+ this.InitializeComponent();
-### Update
+ DataContext = new BindableMainModel(new WeatherService());
+}
+```
+----
+
+Here's a quick summary of the changes:
+- MainModel defines a single property `CurrentWeather` that returns an `IFeed` of type `WeatherInfo`.
+- Instead of defining additional properties to reflect the state of the `GetCurrentWeather` call, this information is encapsulated in the `IFeed`.
+- The `MainPage` XAML has been simplified to use the `FeedView` control, which automatically handles the various states of the `IFeed`.
+- The `FeedView` control has a `Source` property that is bound to the `CurrentWeather` property of the `MainModel`.
+- The `FeedView` control has a `ValueTemplate` that defines the UI to display when the `IFeed` has a value, `ProgressTemplate` that defines the UI to display when the `IFeed` is loading, `ErrorTemplate` that defines the UI to display when the feed has an error, and `NoneTemplate` that defines the UI to display when the `IFeed` has no results.
+- The `Get Weather` Button is data bound to the `Refresh` command of the `FeedView` control, which will cause the `IFeed` to invoke the `GetCurrentWeather` method when the Button is pressed.
-An **Update** is any action that will result in a change to the **Model**. An **Update** is often triggered via an interaction by the user with the **View**, such as editing text or clicking a button. However, an **Update** can also be triggered from a background process (for example a data sync operation or perhaps a notification triggered by a hardware sensor, such as a GPS).
+At this point, don't worry if you don't understand all of the details of the code. We'll cover this in more detail in the following sections. For now, it's important to understand that the `MainModel` code is much simpler than the previous `MainViewModel`, and that the `FeedView` control can be used to encapsulate the various visual states of the application.
-In the weather example, if we wanted to refresh the current weather data, a `Refresh` method can be added to the `WeatherModel`.
+## What is MVUX?
+
+Now that you've seen an example of MVUX in action, let's discuss the main components of MVUX.
+
+### Model
+
+As we saw in the example, a **Model** in MVUX (eg MainModel) is similar in many ways to a ViewModel in MVVM (eg MainViewModel). Both define the properties that will be available for data binding and any methods that will handle user interactions.
+
+In the context of MVUX the term **Model** also includes any data entities that are used by the application. For example, the `WeatherInfo` class, returned by the `GetCurrentWeather` method, is considered part of the **Model**.
+
+In MVUX the entities that make up the **Model** are assumed to be immutable, meaning that both `MainModel` and `WeatherInfo` can be defined as `record` types. This is a key difference between MVUX and MVVM, where the ViewModel is typically mutable.
+
+For the weather application example, `MainModel` is the **Model** for the `MainPage`, and defines a property named `CurrentWeather`.
```csharp
public partial record WeatherModel(IWeatherService WeatherService)
{
public IFeed CurrentWeather => Feed.Async(this.WeatherService.GetCurrentWeather);
- public async ValueTask Refresh() { ... }
}
-```
+```
+
+The `CurrentWeather` property returns an `IFeed` of `WeatherInfo` entities. An `IFeed` represents a stream, or sequence, of values. For those familiar with [Reactive](https://reactivex.io/) this is similar to an `IObservable`.
+
+When the `CurrentWeather` property is accessed, an `IFeed` is created via the `Feed.Async` factory method, which will asynchronously call the `GetCurrentWeather` service, and return the result as a `WeatherInfo` entity.
+
+Feeds are covered in more detail in the [Feeds](xref:Overview.Mvux.Feeds) documentation.
-In the `View` the `Refresh` method can be data bound to a `Command` property on a `Button`.
+### View
+
+In MVUX, the **View** is the UI, which can be written in XAML, C#, or a combination of the two. For example, the following can be used to data bind the `Text` property of a `TextBlock` to the `CurrentWeather.Temperature` property.
```xml
-
-
-
-
+
+
+
+
+
+
```
-As refreshing a feed is such a common scenario, the `FeedView` control exposes a `Refresh` command, that removes the requirement to have a `Refresh` method on the `WeatherModel` and can be data bound, again to the `Command` property, of a `Button`, as follows:
+Unlike MVVM where the `DataContext` of the page would be set to an instance of the ViewModel, in MVUX the `DataContext` is set to an instance of a generated bindable proxy that wraps the **Model**. In this case, the bindable proxy for MainModel is named `BindableMainModel`.
+
+```csharp
+public MainPage()
+{
+ this.InitializeComponent();
+
+ DataContext = new BindableMainModel(new WeatherService());
+}
+```
+
+The generated `BindableMainModel` exposes the `IFeed` properties of the `MainModel` in a way that they can be data bound using simple data binding expressions, for example `{Binding CurrentWeather.Temperature}`.
+
+What's unique to MVUX is the additional information that `IFeed` exposes. The `IFeed` includes information about the state of the asynchronous operation, such as whether the operation is in progress, whether the operation returned data, or not, and whether there was an error. This information can be used to display the appropriate UI to the user.
+
+To simplify working with an `IFeed`, we can leverage the MVUX `FeedView` control. The `FeedView` has been designed to work with `IFeed` sources and exposes an simple way for developers to define what the layout should be for the different states of the asynchronous operation.
+
+The following XAML shows how the `FeedView` can be used to display the current temperature. The `Source` property is bound to the `CurrentWeather` property of the `BindableMainModel`. Inside the `DataTemplate` the `Data` property contains the data returned by the `CurrentWeather` property, which will be a `WeatherInfo` entity.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+The `FeedView` control has different visual states that align with the different states that an `IFeed` can be in (e.g. loading, refreshing, error, etc.). The above XAML defines the `ValueTemplate`, which is used when the `IFeed` has data. Other templates include `ProgressTemplate`, `ErrorTemplate` and `NoneTemplate` These automatically control what's displayed based on the state of the `IFeed`.
```xml
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
```
-Clicking the button will execute the `Refresh` command on the `FeedView` which will signal the `IFeed` to reload. In the case of the weather app it would invoke the `GetCurrentWeather` method of the service again.
-
-### eXtended
-
-At this point you might be wondering how we're able to data bind to `CurrentWeather.Temperature`, as if it were a property that returns a single value, and then also bind the `CurrentWeather` property to the `Source` property of the `FeedView` to access a much richer set of information about the `IFeed`. This is possible because of the bindable proxies that are being generated by the MVUX source code generators.
-
-The **eXtended** part of MVUX includes the generation of these bindable proxies, that bridge the gap between the **Model** that exposes asynchronous feeds of immutable data and the synchronous data binding capability of WinUI and the Uno Platform.
+### Update
-Instead of an instance of `WeatherModel`, the `DataContext` on the **View** is set to be an instance of the generated bindable proxy, `BindableWeatherModel`, which exposes a property, `CurrentWeather`, the same as the original `WeatherModel`. The `BindableWeatherModel` also exposes a property, `Refresh`, that returns a command that wraps a call to the `Refresh` method on the `WeatherModel`.
+An **Update** is any action that will result in a change to the **Model**. Whilst an **Update** is often triggered via an interaction by the user with the **View**, such as editing text or clicking a button, an **Update** can also be triggered from a background process (for example a data sync operation or perhaps a notification triggered by a hardware sensor, such as a GPS).
-For the purpose of this example, the `DataContext` property can be set in the page's code-behind file:
+We can make the weather example a bit more realistic by passing a city name as a parameter to the `GetCurrentWeather` service. In order for our `WeatherModel` to accept a user entered city, it needs to define an `IState` property, `City`.
```csharp
-public sealed partial class MainPage : Page
+public partial record MainModel(IWeatherService WeatherService)
{
- public MainPage()
- {
- this.InitializeComponent();
-
- DataContext = new BindableWeatherModel(new WeatherService());
- }
+ public IState City => State.Empty(this);
+ ...
}
```
-### Result
-
-When the app is launched, a waiting progress ring appears while the service loads the current temperature:
-
-![Video showing a progress-ring running in the app while waiting for data](Assets/SimpleFeed-3.gif)
+An `IState` is a special type of property that is used to store state. The bindable proxy generated for the `MainModel` will now include a `City` property that can be two-way data bound in order to accept user input.
-It is thereafter replaced with the temperature as soon as it's received from the service:
-
-![A screenshot of the app showing a refresh button](Assets/SimpleFeed-5.jpg)
-
-When the 'Refresh' button is pressed, the progress ring shows again for a short time, until the new temperature is received from the server. The Refresh button is automatically disabled while a refresh request is in progress:
-
-![A screenshot showing the refresh button disabled and temperature updated to 24](Assets/SimpleFeed-6.jpg)
-
-For the full weather app tutorial see [How to create a feed](xref:Overview.Mvux.HowToSimpleFeed).
-
-## Recap
-
-In order to summarize what we've just seen, let's return to the list of challenges posed by our simple application.
-
-- What if the external service isn't immediately available when starting the app?
-**The `FeedView` has an `ErrorTemplate` that can be used to control what's displayed when data can't be retrieved.**
+```xml
+
+```
-- How does the app show that data is being loaded? Or being updated?
-**The `FeedView` has a `ProgressTemplate` that defaults to a `ProgressRing` but can be overwritten.**
+The `City` property can now be combined with the `CurrentWeather` property in order to pass the city name to the `GetCurrentWeather` service. The `IFeed` returned by the `CurrentWeather` property will now await the `City` property and pass the value to the `GetCurrentWeather` service.
-- What if no data is returned from the external service?
-**The `FeedView` has a `NoneTemplate` that can be defined.**
+```csharp
+public IFeed CurrentWeather => Feed.Async(async ct =>
+{
+ var city = await City;
+ if (city is not null)
+ {
+ return await this.WeatherService.GetCurrentWeather(city, ct);
+ }
+ return default;
+});
+```
-- What if an error occurs while obtaining or processing the data?
-**The `FeedView` has both a `ErrorTemplate` can be used to control what's displayed when data can't be retrieved.**
+This can be expressed in a more declarative way using the `SelectAsync` extension method. As the value of the `City` property changes, the `SelectAsync` method will automatically trigger a refresh of the `CurrentWeather` feed. The `GetCurrentWeather` method will be invoked, passing the current value of the `City` property.
-- How to keep the app responsive while loading or updating the UI?
-**MVUX is inherently asynchronous and all operations are dispatched to background threads to avoid congestion on the UI thread.**
+```csharp
+public IFeed CurrentWeather => City.SelectAsync(this.WeatherService.GetCurrentWeather);
+```
-- How do we refresh the current data?
-**Feeds support re-querying the source data and the `FeedView` exposes a `Refresh` property that can be bound to `Command` properties on UI elements such as `Button`.**
+This is just one example of how user input can be accepted in order to trigger a change to the **Model**. Another example is for a `Button` to trigger a refresh of the weather data, which was shown earlier with the `Get Weather` Button that was data bound to the `Refresh` command on the `FeedView`.
-- How do we avoid threading or concurrency issues when handling new data in the background?
-**The `IFeed` handles dispatching actions to background threads and then marshalling responses back to the UI thread as required.**
-- How do we make sure the code is testable?
-**The Model doesn't depend on any UI elements, so can be unit tested, along with the generated bindable proxies.**
+### eXtended
-## Key points
+In summary, MVUX is a set of abstractions that are designed to work well with the data binding engine. The use of `IFeed` and `IState` properties allow the **Model** to be expressed more declaratively. The source code generator then generates bindable proxies for each **Model**. The bindable proxies are used as a bridge that enables immutable entities to work with the data-binding engine.
-- Feeds are reactive in nature, similar in many ways to Observables.
+#### Key points
+- Feeds are reactive in nature.
- Models and associated entities are immutable.
- Operations are asynchronous by default.
-- Feeds include various dimensions such as loading, if there's data or if an error occurred.
-- Feeds borrow from Option concept in functional programming where no data is a valid state for the feed.
-- MVUX combines the unidirectional flow of data, and immutability of MVU, with the data binding capabilities of MVVM.
+- Feeds include additional information such as loading, if there's data or if an error occurred.
+- States are used to accept input from the user and can be two-way data bound.
+- MVUX combines the unidirectional flow of data of MVU, with the data binding capabilities of MVVM.
+
-## Learning MVUX by Creating your own
+## Creating your own
-To create a new project using MVUX on Uno Platform, see [How to set up an MVUX project](xref:Overview.Mvux.HowToMvuxProject).
+You can get started with MVUX by creating a new project. Follow the [How to set up an MVUX project](xref:Overview.Mvux.HowToMvuxProject) tutorial to get started.
-You can then use the example above as a reference to create your own solution.
+You can then use the MVUX example above as a reference to create your own `IFeed` and `IState` properties, and use the `FeedView` to display data.
### In the Model
- Define your own Models
- MVUX recommends using record types for the Models in your app as they're immutable
- The MVUX analyzers auto-generate a bindable proxy for each `partial` `class` or `record` named with a _Model_ suffix
-- For every public feed property (returning `IFeed` or `IListFeed`) found in the model, a corresponding property is generated on the bindable proxy.
-- You can use [states](xref:Overview.Mvux.States) for accepting input from the user
-- For example:
-
- ```csharp
- public partial record MainModel(IGreetingService GreetingService)
- {
- public IFeed WelcomeMessage => Feed.Async(this.GreetingService.Welcome);
- ...
- ```
+- For every public [`IFeed`](xref:Overview.Mvux.Feeds) property found in the model, a corresponding property is generated on the bindable proxy.
+- You can use [`IState`](xref:Overview.Mvux.States) properties to accepting input from the user
### In the View
- Create your views and add data binding to the XAML elements as required
-- Create and customize your FeedView as you can see in [The FeedView control](xref:Overview.Mvux.FeedView).
+- Customize the layout of your application using the [FeedView](xref:Overview.Mvux.FeedView) control.
- Use two-way binding to a state to allow input from the user
-### Update
-
-- Trigger feeds to be refreshed
-- Update states in the Model, or two-way data bind to states in the XAML
+## WeatherApp Sample
-### eXtended
+You can find the code for our weather app here: https://github.com/unoplatform/Uno.Samples/tree/master/UI/MvuxHowTos/WeatherApp
-- Bindable proxies have already been generated for you
-- You just need to create an instance of the bindable proxy for your Model and assign it to the `DataContext` and it is done.