なるようになるかも

力は多くの場合、その人の思いを超えない。

Androidの通信処理に何使えばいいのか分からないって話。

特に結論はないです。本当に分からないので。

ソケットレベルまで踏み込むと、途端に面倒になってどのライブラリを使っても手に負えませんし、単にGETとかPOSTとかする分には正直どれ使ってもそこまで変わらない気がしてます。

それより自己署名証明書の検証を無視して通信を行うと端末が爆発するライブラリが必要だと思います。

Apache HTTP Client

みんなお馴染みDefaultHttpClient。色々なライブラリがあるけど、最終的にはここに行き着いていることが多いです。

しかし「Apache HTTP Clientとは何なのか」、という説明はあまり見ない気がします。

自分も「Apacheソフトウェア財団のトップレベルプロジェクトとして運用されている、RFCを満たす実装を目指したJava向けのHTTPインターフェース」という超ふんわりとした認識しかないです。

かなり巨大なライブラリで、全貌を理解するには、HTTPの仕様に関する理解が必要な感じ。

Android SDKの中にも入ってるから特に意識せず使ってる人も多いと思うんだけど、Android SDKに入っているApache HTTP Clientは、バージョン4.0の不完全な状態のものらしい？そのため、可能な限り最新の4.3との互換性を保つAndroid専用のサブライブラリがあります。

また、バージョンごとに大幅にAPIのインターフェースが変わる印象があって、Android以前の人が書き残したコードは、Deprecatedの嵐に見舞われていることが多いです。

Multipartの送信など面倒なことをやろうとする場合に、SDK内臓ではないApache HTTP Clientをライブラリとして選択するケースがあります。記述の冗長さがやはり大きな欠点ですが、RFCを意識したAPIは、仕様が共通言語の人たちにとっては苦にならないのかもしれません。

また、「Android向け」を謳うライブラリには通信量削減のために勝手にgzip圧縮などを行うものが多く、ほとんどの場合その方が効率的に通信を行えるのですが、「プログラマが書いた処理を厳密に実行して欲しい」という業務系ニーズでも強い印象です。

AndroidHttpClient

API Level8のころの遺物みたいなもの？それ以前では使えません。

Android SDKに組み込まれた「Apache HTTP ClientをAndroidに最適化したもの」という説明がされているDefaultHttpClientの亜種です。

コンテンツの送受信にgzip圧縮をかけていたり、タイムアウトの設定が携帯端末に合わせたものに調整されていますが、通信処理そのものはApache HTTP Clientに委譲しています。

また、API Level11以降のAndroidでは、UIスレッドで通信を行うとNetworkOnMainThreadExceptionでクラッシュしてくれる親切設計になりましたが、この時代は通信が平気でUIスレッドを固めていたので、プログラマの矯正の意味合いもありました。

これ使ってる人って本当にいるんです？

HttpURLConnection

java.net.HttpURLConnectionですが、AndroidのAPIは、当然ながらインターフェースが同じなだけでJDK実装とは別物です。

この事実は、基本的なコレクションクラス等でバグに遭遇することはないので、まず気にすることではないのですが、暗号論的擬似乱数生成器のはずのSecureRandomに脆弱性があった、などの闇が広がっています。

初期のHttpURLConnectionもそうした深淵の一つだったのですが、API Level10のころに大々的に「AndroidのHttpURLConnectionも進化したからみんな使ってね！」とアピールしていた記憶があります。もちろんAPI Level10未満の端末ではバグが残ったままなんですけどね…。

そのときアピールしてたメリットは、デフォルトでgzip圧縮してくれることでした。やっぱりAndroidHttpClient使ってる人いないのでは？

もともとはJDKのインターフェースだけあって、「DefaultHttpClientの生成方法がバージョンによってまったく別物になった」みたいな混乱はないですし、ちょっとした用途に使う分には十分です。

しかし、初期の試作にHttpURLConnectionのラッパーを作って楽をしようとした結果、後々複雑な通信をすることになってハマっているケースとか、OSのバージョンによって異なるIOExceptionのエラー文言を判定してる闇なコードを見たりします。

Async Http Client

Java用の非同期なHttpClient。

ちょっと前にAndroidの生きたライブラリとして紹介されてましたけども、Androidだと似たコンセプトの後者の採用率の方が高い気がします。

どうせAndroidではClosableとか使えませんからね…。

Android Asynchronous Http Client

中身としては、Apache HTTP Clientを、ExecutorServiceによるスレッドプールで非同期処理してくれるというものです。軽量なライブラリであることが特徴で、有名なアプリでも採用されており実績も豊富です。

ネットワークのために定型的な非同期処理を書く面倒さから解放してくれます。

反面、コールバックハンドラを記述する方式は、レスポンスをデータベースに格納するなど、非同期処理と連結させる必要がある場合に可読性を著しく損う印象があります。

簡単な処理は本当に簡単に書けますが、処理が複雑になることが予想される場合には、自前で非同期処理を書いたほうが見通しが良くなるかも？

Google HTTP Client Library for Java

冗長なApache Commonsの記述を、簡易に書くためのラッパーライブラリです（HttpURLConnectionでも使えるみたいです）。

ただしHTTP通信自体が主眼ではなくて、それより上位のユースケース、実際的にはXMLやJSONのシリアライズ/デシリアライズ等をアノテーションなどで簡潔に書くためのライブラリといった認識です。

このライブラリを直接使う機会はあまりないと思いますが、Googleのサービスとの接続に使われるGoogle APIs Client Libraryや、OAuth2.0による認可を簡単に行えるGoogle OAuth Client Libraryはこれがベースになっているので、間接的にお世話になっている人は多いんじゃないかなぁという印象です。

「AndroidだとGoogleサービスとの連携がシームレスだから、関係ないんじゃないの？」と思うじゃないですか。思いましたよ。しかしGoogle Drive Android APIとか凄まじく貧弱なので、それなりなことをしようとすると結局こっちを使うハメになるんですよね…。

Volley

いい意味でも悪い意味でも「えー、今時Volley使ってないのー」みたいなノリを感じます。

GoogleによるAndroid向けのネットワークライブラリと銘打っているだけあって、HTTPURLConnectionの闇を打ち払ったり、ImageViewなどActivityのコンポーネント群との連携は抜群で、特に厄介なBitmap周りの処理を簡潔にしてくれますが、それだけではなく非常に汎用性が高いです。

ただやや概念が特殊なので、最初のとっかかりが悪いのと、下手に拡張性が高いために独自のリクエストクラスを量産した結果、Volley職人にしか理解ができないみたいな状態になりかねないのが二の足を踏む要素です。