Thread by @plateau

今天看的是 NAVER DEVIEW 2021 的 Android Jetpack Compose Review of actual service use (deview.kr/2021/sessions/…)。這個 session 可以說是來灌水的吧！除了一開始有介紹一下他們開發的 APP Demae-can 外，後面就完全是在講 jetpack compose 這個主題，一點跟 Naver 也沒有關係

下面幾個是他提到的好處：編譯快，Binary 小，能續用原先 Native 的 UI，不需要再寫 xml layout 了，

另外還有 jetpack compose 的 list 比起 RecycerView 要好寫一百倍吧；而且還能即時修改 UI，甚至是在 Emulator 上也行。最後一點是：很輕量化，因為不再是把 tree 全部建立起來，而是依照當下的 state 去決定要繪製什麼 UI。

既然是新的 toolkit，當然要有足夠多的優點，開發者才會想要去使用。但，缺點他也講了不少：lifecycle 管理不易、Composable 間的變數共享不容易(或需要點學習時間)、state 管理、以及 firebase 在做 tracking 時，所有的 UI 都是在 MainActivity 上，看不到實際上畫面變化的相關記錄。

目前針對 jetpack compose 開發的架構相關例子還不多。傳統開發的話，有各式各樣的 MVP, MVVM, Clean Architecture 的範例可以參考。最後一點是，很容易在各個地方出錯？因為 state 的管理不是那麼直覺，所以容易踩到雷吧。

他們的結論是：如果 spec 要做的範圍不大的話，推薦可以試一次看看。

第五個重點是：要注意的地方。這邊大都是講 state managment 的地方，我就沒仔細聽了。

最後，他提出了適用於 state 的架構:MVSM。

果然看 app 開發相關的 session 就比較輕鬆。雖然還是很多聽不懂，但看看投影片就大概知道他講了什麼。