Zonble 裡面提到一開始會用 iOS 的思考模式去寫 flutter (在 on create 這類的 method 做事)
這讓我想到如果單寫一個平台太久，的確容易在不同平台發生搞錯方向的問題。現在的工程師分工太細，有點太專了 (只寫 iOS, 只寫 react .... 等等)，想法容易僵化。有時候還是要逼一下自己學一些跟專長完全不同的東西…
Flutter 不能算 Android 原生，因為完全不相容，而且很多低階的事做不到。
Google 的專案就算投入資源，也很容易變成只有它們內部使用，短期雖然不會死，但 community 最後會變死水。Dart 本身在 Flutter 出現之前就陷入這個問題。
而做個 Flutter 真的需要龐大的資源，期待 open source 的社群能延續這個專案不太實際 (react-native 也有一樣的問題，沒有 FB 在背後撐著根本養不起來)。
Flutter 最理想的狀況就是它本身變成某平台的原生，例如 Fuchsia 後來爆紅，那 Flutter 自然變第一把交椅，這樣的狀況下原罪就消失了。
zonble 覺得 Flutter 是 Google 要「完全掌握的 mobile platform stack」的一環，再加上它是開源專案而不是針對使用者的 web service，所以比較不需要擔心死掉。至於跨平台，其實從 UI 來說 Flutter 也可以算是 Android 原生？
flutter 做的在好, 也是背著兩個原罪
- google 旗下死亡率高
- 歷史告訴我們跨平台的技術一直都沒有超越原生
不過我覺得可以活絡個三年就很夠了, 所以個人還是會跳這個火坑
其實這就是個完整的 state machine 實作。寫 state machine 本來就要考慮到要拆成多少 state。還好這件事是可以慢慢成長的，不用一開始就知道要多少 state
然後寫多了就免不了會出現 hierarchy state machine (一層包一層)，這時候問題就更複雜了。
不過我猜 mobile app 用不太到 hierarchy ，因為狀態複雜到這種程度其實用戶的理解成本也會上升。還是傾向一個頁面只做一兩件事就好。只有遊戲族群願意學習複雜的互動/狀態。
state machine 很適合處理複雜的狀態切換，但如果 UI 只是個 if 就能搞定的話，它就算 over kill (你要多寫很多 state/event class)。也就是說這個 pattern 可大，但不可小。