Plaidの設計を参考にした, Kotlin coroutines + Retrofit2 でAPI通信をするアプリの実装 モチベーション KotlinConf 2018の「Shaping Your App's Architecture with Kotlin and Architecture Components by Florina」というセッションで、KotlinとArchitecture Componentsを使った設計の話がありました。 Shaping Your App's Architecture with Kotlin and Architecture Components by Florina Plaidというマテリアルデザイン実装のショーケースとなっているアプリを上記設計でリファクタリングする話でした。 Plaid 以下の理由から、Plaidの設計に沿って簡単なサンプルア
システムの要求仕様を決めるのに、ユースケースを使うことがよくあります。 しかし、ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。 たいていのユースケースは、アクターが1人2人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。 役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。 ユースケースは何のために書くのでしょうか。ここでは、ユースケースの目的をはっきりさせて、良いユースケースを書くための考え方を紹介します。 開発者は、細かいことまでユースケースに書き込みがち Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者&LSI
Kotlin系いきます。 youtu.be 理想的なコード こんなコード、書けるといいよね。 val user = fetchUser() // ネットワークからユーザー情報をとってくる textView.text = user.name でも、当然ながらUIスレッドでこんなコード書くと、 fetchUser() が NetworkOnMainThreadException 投げちゃうので、だめ。 じゃあこうするとどう? thread { val user = fetchUser() // ネットワークからユーザー情報をとってくる textView.text = user.name } 今度は textView への変更で CalledFromWrongThreadException 投げちゃう。 これならどうだ。 fetchUser { user -> textView.text = u
※こちらは古いので FlowのchannelFlowを使ってRxBindingを置き換える - visible true を参照ください。 Kotlin Coroutine 1.2.xでFlowというコールドストリームをサポートするクラスや関数群が登場しました。 Flow - kotlinx-coroutines-core 次のような感じでめっちゃRxJavaっぽい雰囲気ですが動作の仕組みはコルーチンでやってる感じです。 val f = flowOf(1, 2, 3) // Flowを固定値で作る .map { it * 2 } .flowOn(Dispatchers.IO) // 実行コンテキストを設定できる runBlocking { f.collect { // この呼出しで初めて値が送出され始める println(it) } } Channelはホットストリームなので取扱いが難しい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く