昨天完成了 React Native 與原生 Widget 之間的資料傳遞。

資料可以交給 Widget 之後，下一個問題就是：哪些資料適合長期放在桌面上？

Widget 最大的限制不是資料不夠，而是更新頻率、顯示空間與互動方式都受到系統限制。

所以 Widget 不能只是把 App 的畫面縮小，而是需要重新決定哪些資訊值得放在桌面上。

先決定 Widget 要解決什麼問題

我希望 Widget 最主要是讓使用者不用打開 App，就能快速知道最近的散步狀況。

因此目前只做兩個：

• 今日散步
• 本週進度

今日散步回答「今天走了多少」，本週進度則回答「最近有沒有維持散步」。

其他功能則不直接放進 Widget。

Widget 可以作為 App 的入口，但不負責取代 App。

為什麼不放即時散步？

GPS 在散步過程中可能每幾秒就更新一次，但 Widget 並不是設計來做這種高頻率資料顯示。

而且目前的架構中，散步進行時的距離只是 App 根據 GPS 暫時計算的結果；真正的正式距離，要等散步結束、資料同步到後端後重新計算。

如果 Widget 顯示即時距離，就可能出現：

App：2.3 km
Widget：2.3 km
完成同步後：2.2 km

這不一定代表哪一邊錯了，而是兩者的資料階段不同。

因此我最後讓 Widget 只使用 local_walk_history 中已經完成的正式統計。

GPS / 暫存資料
      ↓
完成散步
      ↓
後端重新計算
      ↓
local_walk_history
      ↓
WidgetSnapshot
      ↓
Widget

Widget 不參與正在進行中的散步流程。

今日 Widget：只留下真正需要的資訊

今日 Widget 最重要的是距離，因此讓距離成為主要資訊。

目前顯示：

1. 今日距離
2. 散步時間
3. 散步次數
4. 最近完成時間

其他像平均速度、最大速度、配速、熱量、步數則不放進去。

這些資訊不是不能顯示，而是放進 Widget 後需要更多空間，也增加閱讀成本。

Widget 的目標是「看一眼就知道」，不是提供完整統計。

本週 Widget：不要只看總距離

本週統計如果只顯示本週 10 km，其實看不出散步習慣。

同樣是 10 km：

10
0
0
0
0
0
0

和：

1
2
1
2
1
2
1

代表完全不同的活動模式。

因此本週 Widget 除了總距離，還加入：

• 本週活動天數
• 最近七天每日距離
• 與上週相比的變化

最近七天使用長條圖，而不是折線圖。

因為這裡關注的是「每天走了多少」，而不是連續變化的趨勢，長條圖更容易看出哪些天有活動。

Widget 也需要處理不同狀態

Widget 顯示的資料不一定永遠存在。

至少需要區分：

• 尚未登入
• 沒有任何散步紀錄
• 今天沒有散步
• 本週沒有散步

例如「今天沒有散步」和「還沒有任何資料」其實是兩件不同的事情。

前者可以正常顯示：

今日
0 km

後者則可以顯示空狀態或引導使用者開始第一次散步。

這些狀態在 React Native 產生 Snapshot 時就先整理好，Widget 本身只負責根據 Snapshot 顯示。

Widget 不應該承擔太多互動

另外一個限制是 Widget 的互動能力和一般 App 畫面不同。

因此我不會在 Widget 裡加入：

• 開始散步
• 暫停散步
• 結束散步
• 編輯紀錄
• 路線設定

這些操作都會涉及 App 狀態與同步流程。

目前 Widget 主要負責查看資訊與進入 App，真正需要操作的功能仍然交給 App 處理。

小結

Widget 只顯示低頻、已完成、適合快速閱讀的資訊，不負責即時散步與複雜操作。

因此目前保留今日散步與本週進度兩個 Widget，資料則統一來自正式完成的散步紀錄。

但資料放進 Widget 之後，還有一個問題：當 App 裡的資料發生變化時，Widget 要怎麼知道？

明天就來處理 Widget 的更新機制。