Update with latest code

Author: jamesmontemagno

.openpublishing.redirection.architecture.json

@@ -812,6 +812,10 @@
         {
             "source_path_from_root": "/docs/architecture/modernize-desktop/windows-migration.md",
             "redirect_url": "https://github.com/dotnet-architecture/eBooks/blob/1ed30275281b9060964fcb2a4c363fe7797fe3f3/current/modernize-desktop-apps/Modernize-Desktop-Apps-on-Windows-with-NET.pdf"
+        },
+        {
+            "source_path_from_root": "/docs/architecture/maui/configuration-management.md",
+            "redirect_url": "/dotnet/architecture/maui/app-settings-management"
         }
     ]
 }

docs/architecture/maui/accessing-remote-data.md

@@ -3,10 +3,10 @@ title: Accessing Remote Data
 description: Communicating with Web APIs in .NET MAUI
 author: michaelstonis
 no-loc: [MAUI]
-ms.date: 07/12/2022
+ms.date: 05/30/2024
 ---
 
-# Accessing remote data
+# Accessing Remote Data
 
 [!INCLUDE [download-alert](includes/download-alert.md)]
 
@@ -33,11 +33,11 @@ For more information about REST, see [API design](/azure/architecture/best-pract
 
 ## Consuming RESTful APIs
 
-The eShopOnContainers multi-platform app uses the Model-View-ViewModel (MVVM) pattern, and the model elements of the pattern represent the domain entities used in the app. The controller and repository classes in the eShopOnContainers reference application accept and return many of these model objects. Therefore, they are used as data transfer objects (DTOs) that hold all the data that is passed between the app and the containerized microservices. The main benefit of using DTOs to pass data to and receive data from a web service is that by transmitting more data in a single remote call, the app can reduce the number of remote calls that need to be made.
+The eShop multi-platform app uses the Model-View-ViewModel (MVVM) pattern, and the model elements of the pattern represent the domain entities used in the app. The controller and repository classes in the eShop reference application accept and return many of these model objects. Therefore, they are used as data transfer objects (DTOs) that hold all the data that is passed between the app and the containerized microservices. The main benefit of using DTOs to pass data to and receive data from a web service is that by transmitting more data in a single remote call, the app can reduce the number of remote calls that need to be made.
 
 ## Making web requests
 
-The eShopOnContainers multi-platform app uses the `HttpClient` class to make requests over HTTP, with JSON being used as the media type. This class provides functionality for asynchronously sending HTTP requests and receiving HTTP responses from a URI identified resource. The HttpResponseMessage class represents an HTTP response message received from a REST API after an HTTP request has been made. It contains information about the response, including the status code, headers, and any body. The HttpContent class represents the HTTP body and content headers, such as Content-Type and Content-Encoding. The content can be read using any of the `ReadAs` methods, such as `ReadAsStringAsync` and `ReadAsByteArrayAsync`, depending on the format of the data.
+The eShop multi-platform app uses the `HttpClient` class to make requests over HTTP, with JSON being used as the media type. This class provides functionality for asynchronously sending HTTP requests and receiving HTTP responses from a URI identified resource. The HttpResponseMessage class represents an HTTP response message received from a REST API after an HTTP request has been made. It contains information about the response, including the status code, headers, and any body. The HttpContent class represents the HTTP body and content headers, such as Content-Type and Content-Encoding. The content can be read using any of the `ReadAs` methods, such as `ReadAsStringAsync` and `ReadAsByteArrayAsync`, depending on the format of the data.
 
 ## Making a GET request
 
@@ -291,12 +291,12 @@ The most common form of caching is read-through caching, where an app retrieves
 
 This data can be added to the cache on demand the first time it is retrieved by an app. This means that the app needs to fetch the data only once from the data store, and that subsequent access can be satisfied by using the cache.
 
-Distributed applications, such as the eShopOnContainers reference application, should provide either or both of the following caches:
+Distributed applications, such as the eShop reference application, should provide either or both of the following caches:
 
 - A shared cache, which can be accessed by multiple processes or machines.
 - A private cache, where data is held locally on the device running the app.
 
-The eShopOnContainers multi-platform app uses a private cache, where data is held locally on the device that's running an instance of the app. For information about the cache used by the eShopOnContainers reference application, see [.NET Microservices: Architecture for Containerized .NET Applications](https://aka.ms/microservicesebook).
+The eShop multi-platform app uses a private cache, where data is held locally on the device that's running an instance of the app. For information about the cache used by the eShop reference application, see [.NET Microservices: Architecture for Containerized .NET Applications](https://aka.ms/microservicesebook).
 
 > [!TIP]
 > Think of the cache as a transient data store that could disappear at any time.
@@ -318,7 +318,7 @@ It's also possible that a cache might fill up if data is allowed to remain for t
 
 ## Caching images
 
-The eShopOnContainers multi-platform app consumes remote product images that benefit from being cached. These images are displayed by the Image control. The .NET MAUI Image control supports caching of downloaded images which has caching enabled by default, and will store the image locally for 24 hours. In addition, the expiration time can be configured with the CacheValidity property. For more information, see [Downloaded Image Caching](/dotnet/maui/user-interface/controls/image#image-caching) on the Microsoft Developer Center.
+The eShop multi-platform app consumes remote product images that benefit from being cached. These images are displayed by the Image control. The .NET MAUI Image control supports caching of downloaded images which has caching enabled by default, and will store the image locally for 24 hours. In addition, the expiration time can be configured with the CacheValidity property. For more information, see [Downloaded Image Caching](/dotnet/maui/user-interface/controls/image#image-caching) on the Microsoft Developer Center.
 
 ## Increasing resilience
 
@@ -352,7 +352,7 @@ If a request still fails after a number of retries, it's better for the app to p
 
 Use a finite number of retries, or implement the [Circuit Breaker](/azure/architecture/patterns/circuit-breaker) pattern to allow a service to recover.
 
-The eShopOnContainers reference application does implement the retry pattern. For more information, including a discussion of how to combine the retry pattern with the HttpClient class, see [.NET Microservices: Architecture for Containerized .NET Applications](https://aka.ms/microservicesebook).
+The eShop reference application does implement the retry pattern. For more information, including a discussion of how to combine the retry pattern with the HttpClient class, see [.NET Microservices: Architecture for Containerized .NET Applications](https://aka.ms/microservicesebook).
 
 For more information about the retry pattern, see the [Retry](/azure/architecture/patterns/retry) pattern on Microsoft Docs.
 
@@ -367,7 +367,7 @@ The circuit breaker pattern can prevent an app from repeatedly trying to execute
 
 A circuit breaker acts as a proxy for operations that might fail. The proxy should monitor the number of recent failures that have occurred, and use this information to decide whether to allow the operation to proceed, or to return an exception immediately.
 
-The eShopOnContainers multi-platform app does not currently implement the circuit breaker pattern. However, the eShopOnContainers does. For more information, see [.NET Microservices: Architecture for Containerized .NET Applications](https://aka.ms/microservicesebook).
+The eShop multi-platform app does not currently implement the circuit breaker pattern. However, the eShop does. For more information, see [.NET Microservices: Architecture for Containerized .NET Applications](https://aka.ms/microservicesebook).
 
 > [!TIP]
 > Combine the retry and circuit breaker patterns.

docs/architecture/maui/configuration-management.md renamed to docs/architecture/maui/app-settings-management.md

@@ -1,12 +1,12 @@
 ---
-title: Configuration Management
+title: Application Settings Management
 description: Managing persistent configurations in .NET MAUI
 author: michaelstonis
 no-loc: [MAUI]
-ms.date: 06/28/2022
+ms.date: 05/30/2024
 ---
 
-# Configuration management
+# Application Settings Management
 
 [!INCLUDE [download-alert](includes/download-alert.md)]
 
@@ -18,10 +18,10 @@ User settings are the customizable settings of an app that affect the app's beha
 
 ## Creating a Settings Interface
 
-While the preferences manager can be used directly in your application, it does come with the drawback of making your application tightly coupled to the preferences manager implementation. This coupling means that creating unit tests or extending the functionality of preferences management will be limited since your application will not have a direct way to intercept the behavior. To address this concern, an interface can be created to work as a proxy for preferences management. The interface will allow us to supply an implementation that fits our needs. For example, when writing a unit test, we may want to set specific settings, and the interface will give us an easy way to consistently set this data for the test. The following code example shows the `ISettingsService` interface in the eShopOnContainers multi-platform app:
+While the preferences manager can be used directly in your application, it does come with the drawback of making your application tightly coupled to the preferences manager implementation. This coupling means that creating unit tests or extending the functionality of preferences management will be limited since your application will not have a direct way to intercept the behavior. To address this concern, an interface can be created to work as a proxy for preferences management. The interface will allow us to supply an implementation that fits our needs. For example, when writing a unit test, we may want to set specific settings, and the interface will give us an easy way to consistently set this data for the test. The following code example shows the `ISettingsService` interface in the eShop multi-platform app:
 
 ```csharp
-namespace eShopOnContainers.Services.Settings;
+namespace eShop.Services.Settings;
 
 public interface ISettingsService
 {
@@ -45,13 +45,13 @@ public interface ISettingsService
 > [!TIP]
 > Preferences is meant for storing relatively small data. If you need to store larger or more complex data, consider using a local database or filesystem to store the data.
 
-Our application will use the `Preferences` class need to implement the `ISettingsService` interface. The code below shows how the eShopOnContainers multi-platform app's `SettingsService` implements the `AuthTokenAccess` and `UseMocks` properties:
+Our application will use the `Preferences` class need to implement the `ISettingsService` interface. The code below shows how the eShop multi-platform app's `SettingsService` implements the `AuthTokenAccess` and `UseMocks` properties:
 
 ```csharp
 public sealed class SettingsService : ISettingsService
 {
     private const string AccessToken = "access_token";
-    private const string AccessTokenDefault = "";
+    private const string AccessTokenDefault = string.Empty;
 
     private const string IdUseMocks = "use_mocks";
     private const bool UseMocksDefault = true;
@@ -74,9 +74,9 @@ Each setting consists of a private key, a private default value, and a public pr
 
 ## Data binding to user settings
 
-In the eShopOnContainers multi-platform app, the `SettingsView` exposes multiple settings the user can configure at runtime. These settings include allowing configuration of whether the app should retrieve data from microservices deployed as Docker containers or whether the app should retrieve data from mock services that don't require an internet connection. When retrieving data from containerized microservices, a base endpoint URL for the microservices must be specified. The image below shows the SettingsView when the user has chosen to retrieve data from containerized microservices.
+In the eShop multi-platform app, the `SettingsView` exposes multiple settings the user can configure at runtime. These settings include allowing configuration of whether the app should retrieve data from microservices deployed as Docker containers or whether the app should retrieve data from mock services that don't require an internet connection. When retrieving data from containerized microservices, a base endpoint URL for the microservices must be specified. The image below shows the SettingsView when the user has chosen to retrieve data from containerized microservices.
 
-![User settings exposed by the eShopOnContainers multi-platform app.](./media/endpoint_settings.png)
+![User settings exposed by the eShop multi-platform app.](./media/endpoint_settings.png)
 
 Data binding can be used to retrieve and set settings exposed by the `ISettingService` interface. This is achieved by controls on the view binding to view model properties that in turn access properties in the `ISettingService` interface and raising a property changed notification if the value has changed.