15 min/d

ぼうずやのにっき

bouzuya/bbna 1.4.0 (beta) をつくった

bouzuya/bbna 1.4.0 (beta) をつくった。

blog.bouzuya.net for Android - Android Apps on Google Play

bbna は blog.bouzuya.net for Android 。このブログの Android 向けのクライアントだ。

bbna の過去の記事は↓のとおりだ。

1.4.0 は↓の変更点は↓のとおりだ。

  • URL を他のアプリへシェアできるようになりました
  • 記事の読み込み中が表示されるようになりました
  • 端末の再起動なしでも更新が通知されるようになりました

1.3 でブラウザ→ bbna という経路を追加し、 1.4 で bbna →他のアプリという逆向きの経路を追加した形だ。

内部実装としては ReactiveX/RxAndroid の採用が大きい。

これまでは AsyncTaskLoader を使ってきた。 LoaderManager 経由でのこれは Activity / Fragment と密に結合している点などで良くなかった。 Activity から PresenterLoaderManager を渡すと回避できるが、 PresenterAndroid Framework に依存してしまう。それを隠したとして、 init / restart / destroy という操作やピンとこないコールバックに振り回される。メインスレッドとバックグラウンドスレッドの境界にこれを配置しないといけないという制約がつらかった。

RxAndroid は特に Activity などとは結びつかない。スレッドの違いは Scheduler で対応。良い。 Activity などのライフサイクルに合わせた dispose は必要だが、逆に言うとそれだけだ。そも AsyncTask -> AsyncTaskLoader をいまは失敗だったと思っている。 AsyncTask をラップした独自クラスを用意するほうが動きやすかったと思う。ちなみに AsyncTaskexecute だと並行して処理できないし、再実行の注意などが必要なのでラップするほうが良い。極端な話、愚直に HandlerThread (まわりの Java 標準クラス) を使った独自のクラスを持つと良い。 Rx を使うのはその代替のようなものだ。

RxAndroid は上記のようなスレッドまわりの都合もそうだが、 Fragment をまたがる状態の共有に良い。更新通知が流れてくる形だ。オブザーバーパターンを実装すればいいだけではあるが、いろいろな箇所ですこしずつ違うコールバックがあってつらくなる。慌てて共通化したら EventEmitter のようなものをつくってしまったところで、ぼくは諦めた。最初から素直に RxAndroid を使えば良かったんだ。

ちなみに Android Architecture Components | Android Developers として更新通知を流すような仕組みは導入されるようだ。もう標準はどうでもいいという気持ちになっているが……。