2026.09.02 16:20 ~ 17:00 Meerkat

AndroidにおけるServer-Sent Events: 工場の現場を生き抜くリアルタイムストリーム

アプリアーキテクチャ English

DroidKaigi 2025での産業用RFIDに関する登壇後、最も多く寄せられた質問は、登壇中に回答しなかったものでした。それは「実際にデータはどのように工場の現場からAndroidダッシュボードへリアルタイムにストリーミングされるのか？」という疑問です。本セッションはその回答となるものです。 Androidでのリアルタイム処理においてはWebSocketが議論の中心になりがちです。しかし、一方向のサーバーからデバイスへのストリーム（多くのリアルタイムモニタリングがこれにあたります）においては、Server-Sent Events（SSE）の方がよりシンプルで信頼性が高く、Androidでは驚くほど活用されていません。日本の自動車製造の現場において、SSEはAndroidダッシュボードでのリアルタイム工場モニタリングに最適なツールです。本セッションは、その実務経験に基づいて構成されています。 調査はさらに深まりました。2026年4月の2週間にわたり、私はRage Ruby WebフレームワークのSSE実装に対して4つのプルリクエストを送信し、3つの異なるストリームタイプ（formatted、raw、single-value）にわたる3つの接続リークを修正しました。それぞれに異なる修正パターン（rescueとensureのセマンティクス、非同期ファイバー境界のガード条件、テレメトリを考慮したクリーンアップ）が必要でした。4つのPRはすべて完全なレビュー履歴とともにGitHub上にマージされています。サーバー側の調査によって、モバイルクライアントが正確に処理すべき内容が明確になりました。 本セッションでは、本番のシフト（作業時間）を乗り切るAndroid上のSSEコンシューマーを構築する方法について解説します： - SSE仕様が実際に保証するものと、クライアントの責任範囲 - AndroidのHTTPスタックが自動再接続を処理する場所と処理しない場所 - サーバーがデバイスの処理速度を超えた場合のバックプレッシャー設計 - シフトの途中で工場のWi-Fiが切断された場合のオフラインバッファリングパターン - 堅牢なリアルタイムクライアントと脆弱なクライアントを分けるエラーリカバリ状態マシン また、産業用モニタリングにおけるSSEとWebSocketの比較を行い、それぞれがどのような場面で有効であるかを解説します。参加者は、通信の両側（サーバー・クライアント）で開発を行った経験者から、プロダクションで使えるパターンを持ち帰ることができます。 （DroidKaigi実行委員会による翻訳）

対象者

対象者: - バックエンドサービスからリアルタイムデータストリームを受信する Android アプリを構築している方 - WebSocket を実装したことがあり、Android でどのような場面で SSE がより良い選択肢となるかを理解したい方 - モバイルにおいてオフライン耐性のあるリアルタイム処理（産業用モニタリング、ダッシュボード、ライブフィードなど）を必要としている方 - サーバー側の接続ライフサイクルのバグが Android クライアント上でどのように表出するかを理解したい方 - 自身の DroidKaigi 2025 産業用 RFID セッションを聴講し、ダッシュボードが実際にどのようにリアルタイムでデータをストリーミングしているかを知りたい方 - 正しくリリースするためにサーバーとクライアントの両方を理解しなければならないクロススタックのパターンに興味がある方

同じ時間帯のセッション

すべてのセッションを見る