Rx使いに送るKotlin Coroutine入門 - Qiita
Everything is a stream みなさん良いStreamライフを送っていますか？ 私は最高のStreamライフを送っています！ 特に最近Kotlin Coroutineを使い始め、新たな風が流れてきています。(Streamだけに) 寒いギャグのStreamはonCompleteするとして・・・ 昨今のAndroid開発において、RxJava(RxKotlin)とKotlin Coroutineのどっちを使うか問題があると思います。 RxJavaはもちろん素晴らしいフレームワークですが、Kotlin Coroutineは公式が出しているフレームワークなので、こちらを使う方が安心感があるようにも感じます。 Kotlin Coroutineを使ってみて、こちらの方が良いと感じる部分も多数あったので - RxJava使いがKotlin Coroutineを使い始めるための基本知識 -
リアクティブは難しいが役に立つ - Chatwork Creator's Note
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
MV* の「つなぎ」に RxJava を使うのをやめたい - Qiita
ここ数年、特にモバイルアプリ開発で流行ってるUIデザインパターンならなんでもですが、MVVM を例にすると、Usecase における Repository からの結果の受信、ViewModel における Usecase からの通知、あるいは View の変更の通知に RxJava の Observable<T> を使用する例は多いと思います（かくいう自分もそう作ってきました）。 DroidKaigi 2018 のアプリもそうですね。 via DroidKaigi 2018 official Android app しかし最近、この「つなぎ」の役割に RxJava を使うのはやり過ぎでは？と思うようになっています。その理由を次に書きます。 RxJava を使うのをやめたい理由 1. Rx は、できることが多すぎる RxJava の学習コストが高いことは知られています。 つなぎの型が Obse
Rx時代の先にあるもの
こんにちは、アプリケーション共同開発部のみなみです。 iOSアプリ開発を始めてから様々なライブラリを使ってきました。その中で特に強力でおもしろいと感じたのが、Rx (Reactive Extensions)に影響を受けたReactiveCocoaや、RxのSwift実装であるRxSwiftです。Rxライブラリとそれが実現するリアクティブプログラミングは、アプリ開発を大きく変えました。この記事では普段の開発で感じたRxライブラリの威力や課題、そして未来について書きたいと思います。 Rxライブラリは何を変えたのか イベント通知の統一 フラグ変数、深いネストを一掃して見通しが良くなった 複雑な非同期処理を分かりやすく表現 Rxライブラリの課題 依存度の強さ イベントを実行することの影響が予測できない 高い学習コストが割りに合わない部分がある 課題への解決策 async/await Redux 未
リアクティブ宣言
異なる分野で活動する組織が、同じようなソフトウェア構築のパターンを独立に発見している。このようなシステムはより堅牢で、より耐障害性があり、より柔軟で、より最新の要求を反映しやすくなっている。 こうした変化が起きているのは、近年、アプリケーションの要求が著しく変化してきているからだ。ほんの数年前、巨大アプリケーションは数十のサーバから構成され、数秒の応答時間と数時間のオフラインメンテナンスを許容し、データは数ギガバイトだった。今日のアプリケーションは、モバイル機器から数千のマルチコアプロセッサによって動作するクラウドベースのクラスタまで、あらゆる機器上に配備される。ユーザはミリ秒の応答時間と 100% の稼働率を期待する。データはペタバイト単位で測定される。昨日のソフトウェアアーキテクチャは、今日の要求を全く満たしていない。 求められているのは、システムアーキテクチャに対する明快なアプローチ
AvalonからMVVM、そしてRxへ: GUIプログラミングの哲学の歴史
MSテクノロジ知らんがな、とよしぞうに言われて、そういえばこの辺の話は外ではあまり聞かないな、と思ったので、ちょっと軽く振り返ってみる。 なお、Javaプログラマ向けに一部翻訳してるので、C# の実際とはちょっと違う。 かつて人々は、onclickでリクエストを発行しデータを取ってきて、その間はローディング中としてアイコンを回したりして、帰ってきたらアイコンを戻して取得したデータからtableを組み立てたりしていた。 このシーケンシャルな手続きプログラムは、非同期なGUIという物と大層相性が悪く、すぐにアイコンが回り続けたり途中で何か違う事をすると落ちたりといったバグを埋め込んでしまい、人々は悩んでいた。 GUIプログラムのバグはどこから来るのだろうか？ それはページの動的な所から来る、という観察があった。 静的なhtmlはあまりバグらない。 一旦動く、という事が静的に確認されれば、それ以
AvalonからMVVM、そしてRxへ(その2): GUIプログラミングの哲学の歴史
何故か書きかけで放り投げた前編が妙に反響あったので、一応続きも書いておく。 UIのプログラムというのを、準静的に書く為だけに存在するViewModelという物を導入する事にして、現実の要求と準静的なUIのギャップをだいたい埋める事に成功した人類だが、2つほど問題が残った。 1. UIからViewModelへの通知の粒度のミスマッチ 2. GUIアプリでは非UIの機能を非同期で実装しなくてはいけないが、そことViewModelのマッピングでかつての動的なGUIと似た問題が発生してしまう まず1について。 MVVMにおいては、直接イベントはハンドリングせず、基本的なUIの変化はViewModelのフィールドの変化にマッピングする(かICommandにマップする)。 例えばテキストボックスに値を入れると、対応するViewModelのstring型のメンバ変数(のsetter)に値が入る。 この対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
