Further improvements.

Author: madeline-underwood

content/learning-paths/smartphones-and-mobile/build-android-selfie-app-using-mediapipe-multimodality/6-flow-data-to-view-1.md

@@ -9,7 +9,7 @@ layout: learningpathall
 
 [SharedFlow](https://developer.android.com/kotlin/flow/stateflow-and-sharedflow#sharedflow) and [StateFlow](https://developer.android.com/kotlin/flow/stateflow-and-sharedflow#stateflow) are [Kotlin Flow](https://developer.android.com/kotlin/flow) APIs that enable Flows to optimally emit state updates and emit values to multiple consumers.
 
-In this Learning Path, you will experiment with both `SharedFlow` and `StateFlow`. This section focuses on SharedFlow, and the section focuses on StateFlow.
+In this Learning Path, you will experiment with both `SharedFlow` and `StateFlow`. This section focuses on SharedFlow, and the next section focuses on StateFlow.
 
 `SharedFlow` is a general-purpose, hot flow that can emit values to multiple subscribers. It is highly configurable, allowing you to configure settings such as the replay cache size and buffer capacity.
 
@@ -366,5 +366,5 @@ class GestureOverlayView(context: Context?, attrs: AttributeSet?) :
 
 4. Build and run the app again. Now you should see face and gesture overlays on top of the camera preview as shown below. Good job!
 
-![overlay views](images/6/overlay%20views.png)
+![overlay views alt-text#center](images/6/overlay%20views.png "Figure 7: Face and Gesture Overlays.")
 

content/learning-paths/smartphones-and-mobile/build-android-selfie-app-using-mediapipe-multimodality/7-flow-data-to-view-2.md

@@ -6,7 +6,7 @@ weight: 7
 layout: learningpathall
 ---
 
-`StateFlow` is a subclass of SharedFlow and internally use a SharedFlow to manage its emissions. However, it provides a stricter API, ensuring that:
+`StateFlow` is a subclass of `SharedFlow` and internally uses `SharedFlow` to manage its emissions. However, it provides a stricter API, ensuring that:
 1. It always has an initial value.
 2. It emits only the latest state.
 3. It cannot configure its replay cache (always `1`).
@@ -15,7 +15,7 @@ Therefore, `StateFlow` is a specialized type of `SharedFlow` that represents a s
 
 ## Expose UI states in StateFlow
 
-1. Expose two `StateFlow`s named `faceOk` and `gestureOk` in `MainViewModel`, indicating whether the subject's face and gesture are ready for a selfie.
+1. Expose two `StateFlow`s named `faceOk` and `gestureOk` in `MainViewModel`, indicating whether the subject's face and gestures are ready for a selfie.
 
 ```kotlin
     private val _faceOk = MutableStateFlow(false)
@@ -25,14 +25,14 @@ Therefore, `StateFlow` is a specialized type of `SharedFlow` that represents a s
     val gestureOk: StateFlow<Boolean> = _gestureOk
 ```
 
-2. Append the following constant values to `MainViewModel`'s companion object. In this demo app, you will focus on smiling faces and thumb-up gestures.
+2. In this demo app, you will focus on smiling faces and thumb-up gestures. Append the following constant values to `MainViewModel`'s companion object: 
 
 ```kotlin
         private const val FACE_CATEGORY_MOUTH_SMILE = "mouthSmile"
         private const val GESTURE_CATEGORY_THUMB_UP = "Thumb_Up"
 ```
 
-3. Update `onFaceLandmarkerResults` and `onGestureResults` to check if their corresponding results are meeting the conditions above.
+3. Update `onFaceLandmarkerResults` and `onGestureResults` to check if their corresponding results are meeting the conditions above:
 
 ```kotlin
     override fun onFaceLandmarkerResults(resultBundle: FaceResultBundle) {
@@ -75,7 +75,7 @@ Therefore, `StateFlow` is a specialized type of `SharedFlow` that represents a s
     <string name="condition_indicator_text_gesture">Gesture</string>
 ```
 
-2. In the same directory, create a new resource file named `dimens.xml` if it does not exist. This file is used to define layout related dimension values:
+2. In the same directory, create a new resource file named `dimens.xml` if it does not exist already. This file is used to define layout related dimension values:
 
 ```xml
 <?xml version="1.0" encoding="utf-8"?>
@@ -85,7 +85,7 @@ Therefore, `StateFlow` is a specialized type of `SharedFlow` that represents a s
 </resources>
 ```
 
-3. Navigate to `activity_main.xml` layout file and add the following code to the root `ConstraintLayout`. Add this code after the two overlay views which you just added in the previous section.
+3. Navigate to the `activity_main.xml` layout file and add the following code to the root `ConstraintLayout`. Add this code after the two overlay views which you have just added in the previous section:
 
 ```xml
     <androidx.appcompat.widget.SwitchCompat
@@ -111,7 +111,9 @@ Therefore, `StateFlow` is a specialized type of `SharedFlow` that represents a s
         app:layout_constraintBottom_toBottomOf="parent" />
 ```
 
-4. Finally, navigate to `MainActivity.kt` and append the following code inside `repeatOnLifecycle(Lifecycle.State.RESUMED)` block, after the `launch` block you just added in the previous section. This makes sure each of the three parallel `launch` run in its own co-routine concurrently without blocking each other.
+4. Finally, navigate to `MainActivity.kt` and append the following code inside the `repeatOnLifecycle(Lifecycle.State.RESUMED)` block, after the `launch` block. 
+
+This makes sure each of the three parallel `launch` code sections run in its own co-routine concurrently without blocking each other.
 
 ```kotlin
                 launch {
@@ -127,20 +129,21 @@ Therefore, `StateFlow` is a specialized type of `SharedFlow` that represents a s
                 }
 ```
 
-5. Build and run the app again. Now you should see two switches on the bottom of the screen as shown below, which turn on and off while you smile and show thumb-up gestures. Good job!
+5. Build and run the app again.
+Now you should see two switches on the bottom of the screen as shown below, which turn on and off while you smile and show thumb-up gestures. Good job!
 
 ![indicator UI](images/7/indicator%20ui.png)
 
 ## Recap on SharedFlow vs StateFlow
 
-This app uses `SharedFlow` for dispatching overlay views' UI events without mandating a specific stateful model, which avoids redundant computation. Meanwhile, it uses `StateFlow` for dispatching condition switches' UI states, which prevents duplicated emission and consequent UI updates.
+This app uses `SharedFlow` for dispatching overlay views' UI events without mandating a specific stateful model, which avoids redundant computation. Meanwhile, it uses `StateFlow` for dispatching condition switches' UI states, which prevents duplicate emission and consequent UI updates.
 
-Here's a overview of the differences between `SharedFlow` and `StateFlow`:
+Here is an overview of the differences between `SharedFlow` and `StateFlow`:
 
 |  | SharedFlow | StateFlow |
 | --- | --- | --- |
-| Type of Data | Transient events or actions | State or continuously changing data |
+| Type of Data | Transient events or actions | State or continuously-changing data |
 | Initial Value | Not required | Required | 
-| Replays to New Subscribers | Configurable with replay (e.g., 0, 1, or more) | Always emits the latest value |
+| Replays to New Subscribers | Configurable with replay (for example, 0, 1, or more) | Always emits the latest value |
 | Default Behavior | Emits only future values unless replay is set | Retains and emits only the current state |
-| Use Case Examples | Short-lived, one-off events that shouldn't persist as part of the state | Long-lived state that represents the current view's state |
+| Use Case Examples | Short-lived, one-off events that should not persist as part of the state | Long-lived state that represents the state of the current view |

content/learning-paths/smartphones-and-mobile/build-android-selfie-app-using-mediapipe-multimodality/8-mediate-flows.md

@@ -6,11 +6,13 @@ weight: 8
 layout: learningpathall
 ---
 
-Now you have two independent Flows indicating the conditions of face landmark detection and gesture recognition. The simplest multimodality strategy is to combine multiple source Flows into a single output Flow, which emits consolidated values as the single source of truth for its observers (collectors) to carry out corresponding actions.
+Now you have two independent Flows indicating the conditions of face landmark detection and gesture recognition. 
+
+The simplest multimodality strategy is to combine multiple source Flows into a single output Flow, which emits consolidated values as the single source of truth for its observers, the collectors, to carry out corresponding actions.
 
 ## Combine two Flows into a single Flow
 
-1. Navigate to `MainViewModel` and append the following constant values to its companion object. 
+1. Navigate to `MainViewModel` and append the following constant values to its companion object: 
 
     * The first constant defines how frequently you sample the conditions from each Flow.
 
@@ -39,7 +41,7 @@ You might need to add the `@OptIn(FlowPreview::class)` annotation as `sample` is
 
 {{% /notice %}}
 
-3. Expose a `SharedFlow` variable which emits a `Unit` whenever the face and gesture conditions are met and stay stable for a while, which means `500`ms as defined above. Again, add `@OptIn(FlowPreview::class)` if needed.
+3. Expose a `SharedFlow` variable which emits a `Unit` whenever the face and gesture conditions are met and stays stable for a while, which means `500`ms as defined above. Again, add `@OptIn(FlowPreview::class)` if required.
 
 ```kotlin
     val captureEvents: SharedFlow<Unit> = _bothOk
@@ -138,13 +140,11 @@ You can also opt to use `SharedFlow<Boolean>` and remove the `map { }` operation
                     }
                 }
 ```
-4. Even though the photo capture has already been implemented, it is still quite inconvenient to check out the logs afterwards to find out whether the photo capture has been successfully executed. 
-
-You can now add a flash effect UI to explicitly show the users that a photo has been captured.
+4. Even though the photo capture has already been implemented, it is still inconvenient to check out the logs afterwards to find out whether the photo capture has been successfully executed, so you can now add a flash effect UI to explicitly show the users that a photo has been captured.
 
 ## Add a flash effect upon capturing photo
 
-1. Navigate to the `activity_main.xml` layout file and insert the following `View` element between the two overlay views and the two `SwitchCompat` views. This is essentially just a white blank view covering the whole surface.
+1. Navigate to the `activity_main.xml` layout file and insert the following `View` element between the two overlay views and the two `SwitchCompat` views. This is essentially just a white blank view covering the whole surface:
 
 ```
     <View
@@ -187,6 +187,6 @@ You can now add a flash effect UI to explicitly show the users that a photo has
 
 4. Build and run the app:
 
-    * Try keeping up a smiling face while presenting thumb-up gestures. 
+    * Try to maintain a smiling face whilst also presenting thumb-up gestures. 
     * When you see both switches, turn on and stay stable for approximately half a second.
-    * The screen should flash white and then a photo should be captured and show up in your        album,  which might take a few seconds depending on your Android device's hardware. Good job!
+    * The screen should flash white and then a photo should be captured. This will show up in your album, which might take a few seconds depending on your Android device's hardware. Good job!

content/learning-paths/smartphones-and-mobile/build-android-selfie-app-using-mediapipe-multimodality/9-avoid-redundant-requests.md

@@ -6,7 +6,9 @@ weight: 9
 layout: learningpathall
 ---
 
-So far you have implemented the core logic for MediaPipe's face and gesture task results and photo capture execution. However, the view controller is not communicating its execution results back to the view model, which raises the risk for photo capture failures, frequent or duplicate requests, and other potential issues.
+So far you have implemented the core logic for MediaPipe's face and gesture task results and photo capture execution. 
+
+However, the view controller is not communicating its execution results back to the view model, which raises the risk for photo capture failures, frequent or duplicate requests, and other potential issues.
 
 ### Introduce camera readiness state
 
@@ -54,11 +56,11 @@ Copy in the following:
 ```
 
 
-## Introduce camera cooldown
+## Introduce a camera cooldown mechanism
 
 The differences in hardware mean that the duration of an image capture varies across Android devices. Additionally, consecutive image captures place a heavy load on the CPU, GPU, camera, and flash memory buffer.
 
-To address this, you can implement a simple cooldown mechanism after each photo capture that can enhance the user experience while conserving computing resources.
+To address this, you can implement a simple cooldown mechanism after each photo capture that can both enhance the user experience whilst also conserving computing resources.
 
 1. Add the following constant value to `MainViewModel`'s companion object. This defines a three-second cooldown before making the camera available again.
 
@@ -91,7 +93,7 @@ However, silently failing without notifying the user is not a good practice for
 
 {{% /notice %}}
 
-## Entire sample code on GitHub
+## Further resource for support: entire sample code on GitHub
 
 If you run into any difficulties completing this Learning Path, you can check out the [complete sample code](https://github.com/hanyin-arm/sample-android-selfie-app-using-mediapipe-multimodality) and import it into Android Studio.