星屑アトリエ

並行世界のエンジニア界にいる端くれ一般ぴーぽー。いろいろ備忘録。

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連休に書きます!!!