droidkaigi2018 レポート 1日目
3年ぶりのdroidkaigi 2018
僕が参加したのは、2015年の初めて開催されたdroidkaigiでした。
当時は、渋谷のマークシティのビルで、2部屋ぐらいの規模で開催されていたのを今でも覚えていますね。
今日のオープニングトークでも話していたけど、400人ぐらいの規模が、気づけば1000人オーバーって規模。
すごく大きくなったなぁってびっくりしました。
今ではdroidkaigiに参加すること自体が日本のAndroidエンジニアのステータス、みたいになってて面白いなぁとw
1日目レポート
さて、1日目のレポートに入ります。 全部見たことを本当は書きたくて仕方ないんですが、如何せん量が多くて、2日目もあって寝れなくなってしまうので、 これは・・・!と特に気になったものをピックアップして備忘します。
時間と気力が降って湧いたら更新します。
基調講演
最初のセッションは、全員参加で見る基調講演でした。
kotlinのアンチパターンを紹介するプレゼンでしたが、kotlinを事前に手をつけていた身としては、
あーそう書くそう書くww みたいのがあってとても良かったですね。
僕の中で印象深かったのは、拡張関数の乱発についてでした。
拡張関数はどこにでも生やせるので、副作用を生みやすいっていうのは肌感で感じてました。
個人的には、ビジネスロジック層で横断的に利用したい関数が出て来たら、 初めて生やす、ぐらい特別視していいんじゃないかと思ってます。
例えば、UserがLoginしているのかどうか確認したいけど、いちいちレイヤ挟んで確認するのが面倒な時とか。
fun User.isAlive(element: ConfirmElement) {
element.confirm()
}
ユーザーインタフェース層で拡張関数を作るのは、
副作用を許容できないことが多いと思うので、僕なら面倒な方法をとるかなぁ。
と、拡張プロパティを利用する際は、特別視しつつも、副作用が出やすいという特徴を利用・許容する感じでいいと思います。
ただし、こちらもビジネスロジック層で利用することが前提です。
data class User(val sex: String, val name: String) // -------- 以下をどこか別のクラスで利用する Translateあたりとか? ------- // val User.formatName: String get() = if (this.sex == "men") this.name + "君" else this.name + "さん"
この程度であれば、副作用といっても却って特別視されて、分かりやすく明示化されるので、良いんじゃないかなぁと。
意外とまだ、僕が思っていたよりkotlinで開発するエンジニア少なかったので、 希少価値をつけていこうと思った次第でした笑
Model-View-Intent アーキテクチャ
最近はMVPとかより、Unidirectioanl Data Flow という考え方が良いとされてますよね。
その実現方法の一つとしての提案として MVIアーキテクチャという考え方を教わりました。
Rxをふんだんに有効活用してる感がすごかった。
ユーザーインタフェース層は、
- あくまで、Stateに応じたデータを表示する
- ユーザーからのインプットを
Intents
として表現する
という考え方で、IntentsをActionに変換、Actionでロジックを集約してRxにぶん投げるって感じがすごく刺激的でした。
眠いので続きは3連休に書きます!!!