從第二篇到第四篇，我們已經介紹了 Listener、State Machine 和 View Model。
在這個特別篇，我們來看看這三者之間是怎麼互相溝通的。
在第三篇中，我們提到 Listener 和 State Machine 之間並非直接溝通，而是透過資料串起來的，講的就是 View Model。
Listener 偵測到使用者的行為後，就能去改寫 View Model 裡的資料。
State Machine 根據 View Model 裡的資料，判斷條件是否滿足、要不要切換狀態。
Listener ↔ View Model
而事實上，Listener 不只能偵測使用者的行為，它同時也能偵測 View Model 裡的資料是否發生變化。
例如，當 View Model 裡的某個數值改變了，或某個 Trigger 被觸發時，Listener 就能接收到這個變化，並執行對應的動作。
所以 Listener 不只能更新 View Model 裡的資料，也能讀取它的資料。
View Model ↔ State Machine
除此之外，不只是 Listener 能改寫 View Model 裡的資料，State Machine 也可以，而且不只一種方式哦！
例如，當 State Machine 切換狀態時——某個 State 開始或結束，或某個 Transition 開始或結束的時候——你都可以設定讓它去更新 View Model。
還有另一種方式：透過 Data Binding。
在第四篇 View Model，我們提過 Data Binding 可以是雙向的。
也就是說，不只是 View Model 更新 View，View 也能反過來更新 View Model。
那 View 到底要怎麼更新 View Model 呢？
例如，你可以把 View 上的某個屬性，像是物件的 Position，Data Bind 到 View Model 的某個屬性，像是一個 Number 屬性。
方向設成 Target → Source，意思是由物件的 Position 去帶動 View Model 的 Number 屬性。
接著你就可以在 State Machine 的 Timeline 上，幫這個物件的 Position 設關鍵影格。
動畫一播放，那個 View Model 屬性就會跟著一起更新。
Rive 還有一個工具叫 Property Group，專門用來在 State Machine 的 Timeline 上，用關鍵影格把值寫回 View Model。
這個比較進階一點，我們未來再介紹。
重點是：State Machine 不只能讀取 View Model 的資料，也能更新它。
Listener ↔ View Model ↔ State Machine
到目前為止，我們就能畫出下面這張關係圖：
單看這張圖，可能不覺得有什麼特別，但有趣的地方來了：
想像一個 Artboard 裡面放了好幾個 Component（設計元件，像按鈕、卡片、圖示等）。
這個 Artboard 和每個 Component，都各自有自己的 Listener、View Model 和 State Machine。
．Artboard 可以存取任何一個 Component 的 View Model，Component 也能存取 Artboard 的 View Model。
．Component 與 Component 能透過彼此的 View Model 互相溝通。
所以 Listener、State Machine 和 View Model 三者之間的協作是非常靈活、變化多端的！
到這裡，你已經認識了 State Machine、Listener 和 View Model。
但目前為止，所有東西都還只在 Rive 編輯器裡。要讓它在使用者的裝置上跑起來，像是手機或網頁，你還需要最後一塊拼圖。
Part 5，我們就來認識它：Runtime。