ナカザンドットネット

それって私の感想ですよね

Android版ChatWorkアプリ内で使われているOSSを眺めてて見つけた15のライブラリ

12/10に、ビジネス用途向けのチャットサービス「ChatWork」のAndroidアプリが大幅リニューアルされました。

チャットワーク社といえば、国内有数のTitanium Mobileをガッツリ触っている会社としても有名ですが、今回のリニューアルではAndroid SDK + Javaによるネイティブ化を断行したようです。（ツール選びに関する感想は最後に書きました）

というわけで、Facebookアプリのときに続きまして、OSSライブラリのライセンス一覧を眺めていたら面白かったので、各ライブラリに感想を入れていきたいと思います。

ActiveAndroid

クックパッドAndroidアプリにおける最近のDB運用事情 - クックパッド開発者ブログ

クックパッドでも採用されて、苦しみの声が上がっているやつです。弊社では少し実用した後でContentProviderとの相性が死ぬほど悪い（検証当時）という理由でリプレイスしたことがある思い出深いライブラリでもあります。

現在ではContentProvider対応のPullReqがマージされたので、そのへんは解決されていると思われますが、作者が「5年以上ActiveAndroidやってきたけどさー、今の設計だとコレ以上パフォーマンス出ないんだよね。だから発想変えて別のO/Rマッパー作るわ！」とかぶっちゃけてて、今後の開発どうなるんだろう、と不安になるところです。 ただ、当のOllieとやらも数ヶ月更新が無いので、pardomさんが何かの拍子に我に返ったという可能性もあります。 （2015/1/19訂正：別ブランチで作業をしていただけなのか、全然活発に開発してらっしゃいました。）

後述のRealmと用途が被ってる部分もあるので、何と使い分けてるのかなという気持ちもあります。

とりあえず、O/Rマッパーとしての使い勝手や、クエリの発行しやすさで言えばORMLiteよりも楽な気がするので、良いライブラリだと思います（こなみ）

Android Priority Job Queue (Job Manager)

今回初めて存在を知ったやつです。やたら動く(＋)ボタンで一世を風靡したPathが公開しているライブラリなんですね。

順番に実行したいタスクをAsyncTaskとかLoaderとかServiceとかで実装するのは大変手間なので、良い感じに順次実行してくれる的なやつでしょうか。便利そうです。

Butter Knife

安定のJW。（広義で）Squareからの刺客その１。

アノテーションによるfindViewByIdやsetOnClickListenerの簡素化といったどこかで聞いたことのある機能を提供してくれるライブラリですが、他のライブラリに比べると責務を絞ってあり軽量であるという印象があります。

今度弊社でも採用しようかなと思っているところです。

というかAndroidAnnotationsは重厚すぎて全力でロックインする覚悟がないと採用しづらいし、RoboGuiceはスーパークラスを汚染するしで他に選択肢がない

Chunk Templates for Java

今回初めて知ったやつです。

Java向けのHTMLテンプレートエンジンらしいです。このへんを見ると分かりやすいでしょうか。WebViewに表示を任せている部分があるということだと思います。

EventBus

出た！死ぬほど便利なやつ！

従来はBroadcast Intent+BroadcastReceiverなどで実現していた「ある場所から別の場所へイベントを通知する」という目的を良い感じに果たしてくれるライブラリです。一説では、Fragment→Activityの通知や、Service⇔Activityの通信はもう全部これでいいんじゃないかという話もあります。

もちろん飛び道具の類なので、多用すると状態が増えすぎて死ぬ危険が増しますが、適切に使えば強い味方になってくれるはずです。

FloatingActionButton

チャットワークアプリの新UIの中で、一番おもしろかった部分です。

今回のリニューアルの目玉の１つがMaterial Designへの対応でしたが、その中でもFloating action buttonの実現にフォーカスしたライブラリがこちらになります。

他にも makovkastar/FloatingActionButton(★1024) や FaizMalkani/FloatingActionButton(★450) がある中で、このライブラリが選ばれたのは、ボタンが増えるアニメーションの面白さでしょうか。

image

実際、チャットワークアプリの新UIをひと通り触った時は、僕もこの(＋)ボタンを連打してしまいました。楽しいです。

しかしこれ、近いうちにappcompat-v7でサポートされて、リプレイスするかどうかの選択に迫られそうだなあ。ActionBarSherlock(→ActionBar)やViewPagerIndicator(→PagerTabStrip)が通ってきた道ですね。

Icepick

SavedInstanceStateを扱うのをちょっと楽にしてくれるライブラリみたいです。Android 1.6くらいの時代に使われていたIcicleという言葉が使われていて、古参の琴線をフルスイングで殴ってくる感じのライブラリになっています。

AndroidAnnotationsにも@InstanceStateっていう似たようなアノテーションあるけど、たぶんIcepickのほうがいい。

Joda-Time

java.util.Calendarがアホみたいに使いづらいのを何とかしてくれる神ライブラリ。あまりにも神すぎて、JDK1.8ではJoda-Timeにインスパイアされた形で"Date and Time API"（JSR-310）というのが入ったりしました。

参考： http://acro-engineer.hatenablog.com/entry/20130213/1360691391

ちなみに内部のメソッド数が4611個とかある（当社調べ）ので、dexのメソッド数65536上限問題に立ち向かうときには少しお気をつけて。

jQuery

言わずと知れたJavaScriptライブラリ界の巨人ですね。Chunkと組み合わせてWebViewに使っていると予想されます。

json-simple

公式のorg.jsonをシンプルにしたやつらしい。

たまにorg.json.JSONObjectとorg.json.simple.JSONObjectが紛らわしくてアレなイメージしかないんだけど、動作が速かったりするんだろうか。

OkHttp

Squareからの刺客その２。お手軽な使い勝手のHTTPライブラリ。

現状、AndroidでSPDYプロトコルが使える、数少ないネットワークライブラリなので、近年いろいろなところで重宝されているようです。

Picasso

Squareからの刺客その３。素晴らしい画像読み込みライブラリです。

URL, Drawableリソース, java.util.Fileオブジェクトなど、様々な形で画像を指定すると、とりあえずロードしてきてImageViewに放り込んでくれる素敵なライブラリです。画像表示はこれがないとやっていられません。

内部でOkHttpを全力で使って、画像のキャッシュにも対応しています。

Realm (realm-java)

iOSのCoreDataやSQLiteを置き換えるために生み出されたという、C++製RDBMSライブラリですね。

@さんがたまに 言及しておられるような印象があります。

ActiveAndroid的なクエリ発行の使い勝手の良さも感じますし、速度が凄いとのことなのでちょっと興味はあるんですが、流石にプロダクトに使っていい品質ではないだろうなあと邪推して、今のところは手を出していません。

流石チャットワークアプリさん、チャレンジャーだぜ！

と思っていたんですが、チャットワークアプリver3.0.3ベースで本記事を書き始めた後、ver3.0.4でRealmがライセンス一覧から消えました。どうやらRealmを使うのをやめたようです。

やはり人類にはまだ早すぎたのでしょうか。

Secure-preferences

SharedPreferenceに保存するKey, Valueそれぞれを256-bit AESで暗号化してくれるやつだそうです。自分でやるよりは楽そうですね。

TimesSquare for Android

Square最後の刺客。カレンダーライブラリです。

おしゃれ感ありますよね（小並感）

まとめ

ちょいちょい攻めてる感じのライブラリ選定をしていてアツいなと思いました（既に１件思い直されていますが）。ただJSON周りはJsonPullParserとか使うと型安全にマッピングできていいんじゃないかなと思ったり（ステマ）

あとやっぱりSquare社とJWに足を向けて寝られないことになっているアプリって多そうだなと再認識したところであります。

その他、RoboGuiceやAndroidAnnotations重すぎてつらいということを再認識できました。

チャットワークさんは社内チャットとして大変お世話になっておりますので、今後とものご繁栄をお祈り申し上げます。改めまして、リニューアルおめでとうございました。

余談：発足初期の技術選択について

やっぱりクロスプラットフォーム系ツールは保守が大変だったのかなあ、と邪推してはいるものの、「だったら最初からJavaで作ればよかったのに」とは思っていません。

恐らく、初期のメンバーのスキルセットの範囲で、最も早く顧客に価値を届けうる選択肢がTitanium Mobileだったのでしょう。

サービス発足初期は、迅速にプロダクト（≒価値）をユーザーに届け、使ってもらいながらサービスのどの部分の価値を最大限に高めていくのか見極めるのも、また１つの戦術です。

「顧客に本来届けたいもの」が出来上がるまで顧客に価値を全く届けないことより、80%くらいの中核となる価値を真っ先に届けた上で、フィードバックを得ながら時間をかけて「本来届けたかったもの」を届ける。外部から見て、チャットワーク社はこれを実践したように思います。

というわけで、現代のサービスの立ち上げ方、育ち方として、良い事例が１つ生まれたなあと思う次第でございます。

12/15 9:20追記

チャットワークCTOの山本さんも、似たようなお話を講演されていました。既に公知の話題だったことを改めて書いた形になって恥ずかしい(´・ω・｀)

自分がいなくてもうまくいく仕組み

自分がいなくてもうまくいく仕組み

自分がいなくてもうまくいく仕組み

自分がいなくてもうまくいく仕組み