社内でジェスチャーの話をしていて、久しぶりにふるふるブックマークのことを思い出した。端末を方向けるとブックマークのインターフェイスが出る斬新な機能。寝転がりながらはてなダイアリーを見ていると突然これが発動して混乱したりしていた。結局誤爆が多かったので取り外されたけど、一年くらいは本番に出ていたと思う。
今見るとスマートフォン黎明期を感じて面白い。
双眼鏡
ごくたまにコンサートを見に行くのだけど、毎回安いチケットしか買わないので、遠くからしか見られなかった。もう少し楽器の弾き方とか顔とか見たいと思ったので、Amazonで売ってた一番安い双眼鏡を買ってみたところ、すごく楽しめるようになった。手元も表情も見えるし、自分用のテレビカメラを持っているような気分。たった2000円でここまで楽しみ方が変わるとは思わなかった。おそらく観劇が好きな人とか、その筋の人には常識だと思われる。
NASHICA 双眼鏡 SPIRIT 10×21 CR-IR-W ポロプリズム式 10倍 21口径 シルバー 10×21CR-IR-S
- 出版社/メーカー: ナシカ
- メディア: Camera
- 購入: 5人 クリック: 38回
- この商品を含むブログ (2件) を見る
スマートフォンアプリでリアクティブプログラミングをしているが、Promiseとデータバインディングとして使っている
このところ、複数の人からリアクティブプログラミング（RP）ってつまり何なんですかと聞かれることがあった。そのたびに非同期データストリームが…みたいな説明をしていたのだが、たいてい双方納得した感じにはならなくて、まあ難しいっすね…という感じで終わってしまっていた。
iOSとAndroidでの用途
自分は理論より実践からしか考えられないタイプなので、もっと現場寄りの説明ができないか常々考えていた。そこで自分がiOSとAndroidアプリを実装する際に使っているReactiveCocoaとRxJavaの用途を考えてみたところ
の2つがメインだった。
この2つはRPライブラリを入れなくても実装できる。JavaScriptならそれぞれに独立した良いライブラリがあり*1、両方ともそこそこ普及している概念だと思う。
クライアントサイドで使うRPについての自分の理解は、この2つの概念と他の用途（イベントと時間、高階関数など）を包括した大統一理論というか、スーパーセットだというものだ。両方を1つのライブラリで実装しようとするとRPの形がしっくりくるし、なるほどストリームって必要だよねというのも感覚では理解できるようになった。
しかしやはり概念として大きすぎる気がするし、実際の仕事では使っていない機能も多い。選択肢がある場合は、小さくて普及しているものを採用した方が、現場の負荷も少なくて良いのではないかと思う。パラダイムの違うもの、怖いし。
プラットフォーム事情
ではなんで自分がRPというスーパーセットお化けを使っているかというと、スマートフォンアプリでPromiseとデータバインディングを実装するために最も完成度が高いライブラリがRPライブラリだったからという消極的な理由である。
iOSではPromiseKitなどのPromise系ライブラリは割とあるし使われていると思う。データバインディングのライブラリもあるのだが、自分の感想ではReactiveCoocaのデータバインディングが一番使いやすかった。
Androidでもライブラリは色々あるが、データバインディングもPromiseも広く使われている実装がないというのが自分の理解。RxJavaがAndroidでも人気なのは、Promiseの良い実装がないからではないかと自分は考えている。
おわりに
RPは大統一理論なので、Promiseとデータバインディングを両方実現できる上に、両方を繋いで！複雑なAPIコールとViewへの反映をObservableで接続！ということもできる。キメると実装者としては大変気持ちが良い。しかしたいていの場合そこまでやる必要は無いし、キマったコードはRPに慣れていない同僚を困らせる。
なので色々できるけど、今のところ自分はPromiseとデータバインディングをやるための便利なライブラリだよという説明を採用しているし、仕事でもその範疇の中で使っている。
RPのパラダイムがもっと普及して、RPで全部を考えるニュータイプが多勢を占めるようになるとこの状況も変わると思うので、それはそれで楽しみである*2。
補足
- サーバーサイドでの用途に言及すると混乱に拍車がかかるし、自分はやっていないので省いた
- プラットフォームでRxをサポートしている.netの方から見ると事情は全く違うだろうと思う
- これもよく聞かれるし、自分も前は間違えていたのだけど、React.jsはデータバインディングなどの概念での共通点はあるけど、リアクティブプログラミングの実装ではないという理解
- 多様なリアクティブプログラミングの世界を覗き見たければReactive Pornがとても参考になる
DroidKaigiの発表を募集しています（2/25締め切り）#droidkaigi
DroidKaigiというAndroidエンジニアのお祭りイベントで、現在発表を募集中です。自分もスタッフとして参加しつつ、会社のアプリのMaterial Design対応についての発表で応募する予定です（つまりまだ応募していない！君も間に合う！）。
DroidKaigiはYAPCのAndroidコミュニティ版みたいなイメージです http://t.co/wMHVLZnxh8 #droidkaigi
— ninjinkun (@ninjinkun) 2015, 2月 3自分はずっとスマートフォンアプリエンジニアにもYAPCのような大きなお祭りイベントがあると良いなと思っていました。今年こそDroidKaigiで発表するぞ、今年はDroidKaigiで発表できたので俺がんばった、みたいに思えるイベントになると良いなと思ってます。
今集まっている発表が、割と低レイヤーだったり硬派なものが多いので、もう少しUIやデザインぽい話題や、普段こうやってアプリを作っているみたいな話も欲しいねとスタッフ間では話しております。
DroidKaigiは初開催ですが、自分の経験上こういうイベントは発表者側に回ると倍くらい楽しめます。というわけでDroidKaigiはあなたの発表をお待ちしています。
■
IRKitでエアコンを付けて快適に目覚める予定だったけど、タイマー用のherokuのプロセスが死んでたので寝坊した
Android SDKのソースコードを読みながら開発する
この記事はAndroid Advent Calendar 2014の14日目です。
Androidアプリケーション開発をiOSのそれと比べると、SDKのソースコードが公開されていることがアドバンテージの一つになると思います。自分は半年ほど前から、開発時に時々SDKのソースコードを参照するようになり、それからSDKへの理解が深まって、開発効率が高まったと感じています。
この記事では、自分がSDKのソースコードを読む際に使っている方法をまとめます。たぶんよく知られている方法ばかりです。
1. ブラウザで見る
GrepCode
特定のクラス名でぐぐっていたりすると、GrepCode というサイトが時々引っかかります。Javaのソースコードを集めて検索可能にしてくれているサイトですが、ちょっとSDKのコードを読みたいというときは、このサイトで読むのがおすすめです。
Android SDKの各バージョンが置かれているので大変便利。SDKに同梱されているSupport Libraryも置いてあります（例えば新しく追加されたToolbarとか）。クラス名がリンクになっていて他のクラスにすぐ飛べるので、コードの流れを追いたいときにも便利です。コードレビュー時にリンクを貼る時にも重宝します。
ただし最新のSDKの反映は遅めなので、その点だけ注意が必要です（先週ようやく5.0のコードが反映されました）。
GitHub
オリジナルのgoogle codeのリポジトリをGitHubにミラーしたリポジトリがあります。最新のソースをWebで見たい場合は、こちらの方が便利です。GitHubのソースブラウザや検索が使えるというメリットもあります。こちらはコード名のリンクのような機能はありません。
2. SDK Managerでダウンロードして見る
SDK Managerを起動して、各バージョンのソースをダウンロードできます。ソースは$ANDROID_HOME/sources/android-21/support/のようなパスに保存されます。落としたソースは自動的にリンクされ、Andrdoid Studioを使っていればCommand+クリックでジャンプできるようになります*1。開発に使っているSDKと対応するものは、入れておいて損はないと思います。
Support Libraryのソースも自動的に入ります（$ANDROID_HOME/sources/android-21/support/）。しかしここにあるのはSDKリリース時点のもので、Support Library単体のアップデートには追従していないようです。そこで最新のSupport Libraryを読むには次の方法を使っています。
3. gitでcloneして見る
google codeからSDKやSupport Libraryのソースがgit cloneできます*2。恐らくこちらにあるソースが、アプリケーション開発者が手に入れられる一番最新のものだと思います*3。そのままcloneするとかなり時間がかかるので注意。 リリースバージョンにはtagが振られているので、特定のバージョンのソースを見たければtagをcheckoutする必要があります。
gitのローカルリポジトリになるのでgit grepでコードを追うことができます。自分はSDKが提供しているパーツがSDK内でどう使われているかを探す場合によく使います。（たとえばIntentのflagの使われ方の例を探す、とか）
2の方法で手に入れたソースをgit initしたり、何らかのindexを作っておくだけでも検索はできるので、grep用途だけならこの方法は必要ないかもしれません。ただ自分はghq+percol/pecoでリポジトリを横断するフローに慣れてしまったため、他のgithubプロジェクトと同じ方法でソースにアクセスできるこの方法をよく使っています。
おわりに
色々書いてみましたが、自分が一番主張したいのは、Android SDKのソースを読みながら開発すると捗る！ということです。自分としては、これはもっと早くに知っておけば良かったと思っています*4
先日勉強会で、他社のAndroidエンジニアさんたちに「SDKのソース読んでますか？」と聞いてみたところ、話したほとんどのエンジニアは多かれ少なかれSDKのコードを読んだ経験を持っていました*5。その席で聞いてみたところでは、よく読むものとしてはFragment、Activity、Viewなどが人気があるようでした。
自分の経験では、Support LibraryのFragmentとViewPagerは読みづらいけど役に立つ鉄板、PagerTitleStripはカスタムViewの勉強になりました。
Android SDKのコードベースはとても大きく、知らないクラスを読む度新たな発見があります。SDKの語りかけに耳を澄ませて、彼の気持ちを理解するのです。そのとき、SDKは大いなる力、新たな可能性をあなた開示することでしょう。
という感じで雑に締めたいと思います。
*1:自分の環境ではたまにSDKのディレクトリへのリンクが切れることがあるので、その都度Attache Sources…で指定し直しています
*2:他にも多数のリポジトリがありますが、NDKを使わない自分の用途としては、ほぼplatform/frameworks/baseとplatform/frameworks/supportだけで足りています
*3:SDK MangerでSDKやSupport Libraryのリリースがあっても、その直後にはまだ反映されていなかったりすることがあるので、その場合はじっと待つしかないです。
*4:しかしこれは自分がiOS脳だったので思いつかなかっただけで、OSSなプラットフォームならフレームワークを読むのは当たり前のことではあります
*5:ぐぐったりして見たことがある人はほぼ全員、積極的に読むという人もそれなりに居る様子
