### Android Build Variants and Product Flavors Configuration

Source: https://github.com/azrael8576/traveltaoyuanlite/blob/main/README.md

This snippet explains the build configuration for the TravelTaoyuanLite application, detailing the use of standard debug and release build variants along with product flavors. It clarifies how demo and prod flavors are used to control content loading sources, noting that both currently connect to the backend server.

```APIDOC
Build Variants:
  - debug: Standard debug build.
  - release: Standard release build.

Product Flavors:
  - demo: Originally used static local data; currently connects to backend server. Allows developers to immediately build and explore the UI.
  - prod: Connects to backend servers for the latest content.

Recommended Usage:
  - For normal development: Use `demoDebug` variant.
  - For UI performance testing: Use `demoRelease` variant.
  Note: Always test Compose performance in release builds.
  Reference: Google official blog post "Why should you always test Compose performance in release?"
```

--------------------------------

### MVI UI Event Handling Best Practices in Android

Source: https://github.com/azrael8576/traveltaoyuanlite/blob/main/README.md

This snippet details the recommended approach for handling UI events within the MVI architecture, as per Android's official application architecture guidelines. It emphasizes avoiding Channels and SharedFlow for exposing ViewModel events directly to the UI, advocating for immediate processing of one-off events and exposing state via observable data holders.

```APIDOC
UI Event Decision Tree:
  (Refer to image: https://developer.android.com/static/topic/libraries/architecture/images/mad-arch-uievents-tree.png?hl=en)

UI Events Handling Principles:
  1. Immediately process one-off ViewModel events and reduce them to UI state.
  2. Use observable data holder types to expose state.
  Note: Do not use Channels, SharedFlow, or other reactive streams to expose ViewModel events to the UI.
  Reference: Google official blog post "ViewModel: One-off event antipatterns"
```

--------------------------------

### Integrating with Taoyuan Tourism Open API

Source: https://github.com/azrael8576/traveltaoyuanlite/blob/main/README.md

This section describes the integration with the official Taoyuan Tourism Open API, which serves as the backend data source for the TravelTaoyuanLite application. This API provides comprehensive tourism data, including events, attractions, and news specific to Taoyuan City.

```APIDOC
API Name: 桃園觀光導覽網 Open API (Taoyuan Tourism Guide Network Open API)
Endpoint: https://travel.tycg.gov.tw/open-api/swagger/ui/index#/Event/Event_News
Purpose: Provides tourism data from Taoyuan City, including events, attractions, and news.
```

--------------------------------

### Common MVI Class Encapsulation in TravelTaoyuanLite

Source: https://github.com/azrael8576/traveltaoyuanlite/blob/main/README.md

This section outlines the common class encapsulations used within the TravelTaoyuanLite application to implement the MVI (Model-View-Intent) architecture. It details the purpose and benefits of BaseViewModel, StateFlowStateExtensions.kt, and DataSourceResult.kt for managing UI state, event dispatching, and data source results.

```APIDOC
BaseViewModel:
  Purpose: Provides a MutableStateFlow for UI to subscribe to UI State and an abstract dispatch() method for subclasses to implement.
  Note: Unified event dispatching via dispatch() helps decouple View and ViewModel, facilitating log analysis and subsequent processing.

StateFlowStateExtensions.kt:
  Purpose: Encapsulates UI StateFlow streams, offering more convenient operation methods.

DataSourceResult.kt:
  Purpose: A sealed class encapsulating data source results, representing states such as Success, Error, or Loading.
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.