DroidKaigi 2018 に参加しました

Android 担当の松下です。 先日開催された DroidKaigi 2018 に参加しました。

droidkaigi.jp

本日は個人的にこれは！と思ったセッションについてレポートを書こうと思います。

kotlin アンチパターン

www.slideshare.net

僕も最近 kotlin を書いていますが、やってしまいがちなことが結構ありました。

例えば、スコープ関数だと、 apply, also があります。
apply だと、

button.apply {
  text = "hello"
}

というコードがあった時に、ローカル変数 text が定義されると、 button.text ではなく、変数の方に向いてしまうようです。
弊社では、 apply を考えなしに使った結果、以下のようなコードが量産されてしまうことがありました。

class HogeActivity: AppCompatActivity {
  @Inject
  lateinit var factory: ViewModelProvider.Factory

  private val viewModel: HogeViewModel by lazy {
    /* 省略 */
  }
  private lateinit var binding: ActivityHogeBinding
  
  override fun onCreate(savedInstanceState: Bundle?) {
    binding = DatabindingUtil.setContentView(/* 省略 */)
    binding.apply {
      viewModel = this@HogeActivity.viewModel // これ
    }
  }
}

この時、 also を使うと、

binding.also {
  it.viewModel = viewModel
}

とできるので、スライドのとおり also または let を使うのがベターなのかな、と思いました。
最後の、「無理に kotlin の機能を使わない方がわかりやすいことがある」というのは本当にその通りだなと思いました。

MVVMベストプラクティス

speakerdeck.com

MVVM の View, Model, ViewModel の「責務」や「関心」について考えさせられたセッションでした。
このセッションでは ViewModel を中心に話されていました。

ViewModel にテストできないものが無いか？というページを見た時はドキッとしてしまいました 😓 現在、 dagger2 で SharedPreference を inject していたり、 applicationContext を inject していたりしていましたが、どうやら SharedPreference は Repository 層に置いて viewModel はそこを叩くようにするのがよいようです。
context.getString(R.string.hoge) はラッパークラスを作り、そいつを inject するとテストがし易いようです。

いままで Robolectric でどうにか context を作って ViewModel のテストをしていましたが、これだと JUnit4 でも ViewModel のテストができそうです。

画面遷移やダイアログについても Navigator クラスを作るとよいようです。
Navigator クラスの作り方はこちらの本にも書いてありますので、気になった方は購入してみてはいかがでしょうか。

peaks.cc

すばらしきGraphQLのSEKAIへようこそ

speakerdeck.com

急に Android 関係なくなるように見えますが、意外にも自分が一番印象に残ったのがこれと gRPC のセッションでした。

speakerdeck.com

現在、弊社のどの製品も REST を使っている（はず…。）のですが、長く運用していくうちに、色々課題が浮き彫りになってきたように感じます。 例えば、

  • バックエンドが ruby on rails なのでレスポンスの型が決まっていない
  • 画面によっては必要としていない情報があり、それに対応するクエリが増えて把握が困難になってきた。
  • （クライアントから見て）同じ型を要求しているが、 rails のコントローラーが違うとクエリが反映されない場合がある
  • 破壊的な変更をするために API バージョンを変更しなくてはならず、それが面倒
  • API ドキュメントの整備が手間

GraphQL, gRPC (Protocol Buffer) だと全て解消されるということではありませんが、いくつかの課題が解決されるようです。

例えば、型問題は GraphQL, gRPC ともに型を決める必要があるので rails エンジニアも型を意識して書く必要がなくなります。
GraphQL だと今必要な情報をクライアントがクエリ言語を組み立ててリクエストするので画面に合わせてオプションを作って分岐をする必要がありません。 GraphQL は破壊的な変更を良しとせず、継続的に追加の変更のみをすることを推奨しているようです。従って API バージョンという概念はありません。*1

gRPC だと、 proto ファイルがドキュメントだ！というスタイルでもなんとかなりそうです。
GraphQL では GraphiQL という優秀なエディタ *2 が使える上、型ファイルに description "説明です" と書いておくと GraphiQL で見れるはずなので API を追加した後に API ドキュメントに追記し忘れてそのまま放置されるといったことは防げそうです。

色々便利そうな GraphQL ですが、ファイルアップロードなどは少々面倒らしく、ここだけ REST にしたほうが楽だったりするようです。

感想

今回初めて DroidKaigi に参加しましたが、来年も参加したいと思うくらい情報が濃いです。
自分からはあまり調べなさそうな分野の話も聞けたり、会場限定で実際の製品に使用されている kotlin の拡張関数が公開されていたりしますので、予定が合うなら参加されると良いかと思いました。

ねこじゃらしについて

ねこじゃらしでは Android に限らず Ruby (Ruby on Rails) や JavaScript での開発経験がある Web エンジニア、ネイティブエンジニア、UI/UX デザイナを募集しております。

ご興味をお持ちいただけましたら、以下のリンクからお問い合わせください。 www.nekojarashi.com

*1:http://graphql.org/learn/best-practices/#versioning

*2:githubのものを触ってみると感じがつかめると思います。 https://developer.github.com/v4/explorer/