ガジェット通信 GetNews

見たことのないものを見に行こう

体験を伝える―『ガジェット通信』の考え方

面白いものを探しにいこう 本物を体験し体感しよう 会いたい人に会いに行こう 見たことのないものを見に行こう そしてそれをやわらかくみんなに伝えよう [→ガジェ通についてもっと詳しく] [→ガジェット通信フロアについて]

ヤフーがAndroidアプリに関する技術や開発事例を共有する「CAMPFIRE Android」を開催

Yahoo!知恵袋をRxJavaでフルリニューアル

ヤフーのAndroidにおける技術情報を共有するMeetup「CAMPFIRE Android #1」が、4月19日にヤフーのコワーキングスペース「LODGE」で開催された。

「Yahoo! Japanでの取り組みや開発のコツを知ることができる」「Androidアプリ開発の情報をアップデートできる」ことから、定員100人を超える人たちが集まった。

まずはドリンクで乾杯。ラフな雰囲気で始まった

最初のセッションを行ったのは、Yahoo!知恵袋を担当している(取材時)中里直人氏。タイトルは「RxJavaを1年使って見えてきたこと」。

Yahoo!知恵袋は1年前にフルリニューアルしている。リニューアルに取りかかったのは2015年11月。その際に導入したのが、RxJava(RxJava1)だ。アプリの基本構成は次の通り。

RxJavaを使ってよかったのは「非同期処理が簡単になったことと、複数箇所で最新情報を表示できるようになったこと」。

まずは非同期処理が簡単にした方法について。API Requestについては、通信処理をRxでラップ。「OSSを使えば勝手にやってくれることも多いので」と中里氏は説明する。

またModelについてはレスポンスクラスをデータクラスに変換することで、適宜キャッシュを返したりするようにした。Activityについては、データを受け取って表示更新処理などを行い、エラー時の挙動も書いた。

続いて複数箇所で最新の情報を表示するために、ModelにBehaviorSubjectを保持し、観測用の関数を用意した。またdoOnTerminate() for Singleについては、成功しても失敗しても実行する処理を書いた(ObserbleにあるものをSingleに実装)。

そしてProgressDialogを簡単に表示するように実装、さらには二重リクエストを防止するようにした。

中里氏いわく「こうしておけば良かった」ことは、まずは通信要求と通信状態を分けること。画面回転などをしたときに、通信状態が引き継げなくなるからだ。

次にunsubscribeする場所をよく考えること。第三にストリームに流す値をimmutableにすること。第四にストリームにnullを流さないこと。なぜならRxJava2に移行できない可能性があるからである。

第五にListの更新方法を統一するなど、Listっぽいものの扱いに注意すること。第六にRecyclerViewを積極的に使うこと。要素の挿入や内容の変更が非常に大変になってしまったからだという。

中里氏は最後に、今後はRxJava2に移行を予定しており、またKotlin化も進めたいと語った。

大規模アプリケーションを支える設計とは?

続いて登壇したのは、Yahoo!JAPANアプリのプロジェクトマネージャーであり開発チームリーダーとしてメンバーをけん引している牧竜也氏。

セッションタイトルは「大規模アプリケーションを支える設計」。Yahoo!JAPANアプリで設計を見直すプロジェクトについて紹介した。

アプリ開発の初期パターンとしてよく活用されているのが、Smart UI Pattern。これはビジネスロジックをUIに実装するパターン。一般的にアンチパターンとして認知されており、シンプルな機能やスピード重視では採用されがちだが、「大規模なアプリケーションだと破綻する」と牧氏は言う。

ActivityやFragmentにビジネスロジックが集中し、肥大化するからだ。

そこで破綻しにくいアプリケーションを実現するために、ビジネスロジックをUIから切り離すことにした。

こうすることで、ActivityやFragmentが肥大化せず、ビジネスロジックのユニットテストが書きやすくなる。さらにUI・ビジネスロジックの変更がお互いに影響し合わず独立して行えるようになるからだ。

「ただ現実はそう簡単にはいかない」と牧氏は続ける。UtilやHelper、Managerなどの責務が不明瞭なクラスが量産され、課題が解決しなかった。

明確な設計指針が必要だと考え、採用したのはエリック・エヴァンスのドメイン駆動設計で紹介されているLayard Architecture。

アプリケーションをプレゼンテーション層(情報の表示やユーザー入力の解釈)、アプリケーション層(アプリケーションの要件を実現)、ドメイン層(ビジネスロジックを実現)、インフラストラクチャー層(上位層を支える基盤技術)の4層に分離。上位層は下位層にのみ依存する。

1 2 3次のページ
CodeIQ MAGAZINEの記事一覧をみる
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。

山寺宏一&高木渉で『ポプテピピック』

GetNews girl / GetNews boy