MatrixのpostScaleで画像を拡大縮小させる

ImageViewなり、自分で作ったCustom Viewなりで表示させる画像を、動かしたり拡大縮小させたりするのに使えるMatrixをいじって学んだことのメモです。

特にpostScaleを使った拡大縮小がイメージ通りに動かなくてハマってしまいました。

ちなみにMatrixクラスを使ってBitmapを加工する – Techoboosterを参考に始めました。

使い方

ImageViewに設定するには、setImageMatrixメソッドでMatrixを渡してやるといいです。

Matrix matrix = new Matrix();
ImageView.setImageMatrix(Matrix);

CustomViewで使う場合は、オーバーライドしたonDraw()で描画するときにMatrixを渡せばいいです。

   @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        canvas.drawBitmap(mImage, mMatrix, mPaint);
    }

こんな感じ。mImageはBitmapオブジェクトで、mMatrixとmPaintはそれぞれnew Matrix(),new Paint()したものを渡してます。

今回は下のCustom ViewでMatrixを操作していて分かったことを書きます。

タッチ操作で動かす

画面上を指でなぞると、その動きに応じて画像も移動するようにする場合はこうすればOK。

mMatrix.postTranslate(float X移動量,float Y移動量);

移動量を取得するにはTouchEventを自分で判定するなり、GestureDetectorを使うなりして取得します。

GestureDetectorの使い方はDetecting Common Gestures – Android Developers参照。また別途記事書こうと思います。

移動に関しては特に難しくはありませんでした。ただし、移動制限を設けようとするとこれはこれでまた大変そうです。

こちらの記事が移動制限を実装するのに非常に役立ちそうな予感です。実装できたらまた記事書きたいと思います(そればっか)。

拡大縮小

ピンチイン・アウトで画像を拡大縮小させる場合がクセモノでした。

mMatrix.postScale(float X拡大率, float Y拡大率, float 拡大の起点X, float 拡大の起点Y);

ハマったポイントはここで渡す拡大率の扱いです。

postScaleに渡す拡大率は、Matrixを指定した拡大率に変形させるのではありません。現在のMatrixを渡した拡大率で拡大縮小させます。Matrixの拡大率が0.1のときにpostScale(0.1f,0.1f)するとMatrixの拡大率は0.01になります。

画像が過剰に縮小・拡大されないように渡す拡大率の値を制限したとしても、制限した値をそのまま渡してしまったら制限が効きません。

指定した拡大率に画像を変形させたい場合は変化量を計算して渡すようにします。

ScaleGestureDetectorを使って拡大縮小させていて、頭の中がこんがらがっていました(現在進行形ですけど)。ScaleGestureDetectorを使うと、onScaleメソッド内でdetector.getScaleFactor()を使うことでピンチイン・アウトによる拡大率を取得することができます。

この拡大率は、ピンチ操作が始まった段階では1.0から始まります。そのためこの値をそのままMatrixのpostScaleに渡すと、拡大縮小の開始時に一旦元の縮尺に戻ってしまいます。そのこととごっちゃになっていて間違ったこと書いてました。

float deltaScale = targetScale / nowScale;
mMatrix.postScale(deltaScale, deltaScale);

postScaleではなくsetScaleを使う方法もあるのかもしれませんが、動き始めに画像が元のサイズに戻ってしまうため、この方法がスマートな気がします。

Read full post gblog_arrow_right

Intentを発行して画像を選択orカメラで撮影して、画像を表示させる

端末内に保存されている画像を表示したり、もしくはその場でカメラで撮影した画像を表示させる方法です。

例えばSNSへ投稿する画像を選択したりするのに使うことが考えられますかね。

やり方としてはIntentを発行して、startActivityResult()で結果を受け取って表示させるようになります。

画像の選択とカメラでの撮影は異なるアクションなので、1つのIntentで表現するにはIntent.createChooser()で複数のIntentをひとまとめにして発行することになります。

やってみると、カメラで撮影した画像を受け取るのにちょっと工夫が必要なだけで、割と簡単に実装できました。

Getting a Result from an Activity – Android Developers

Intentの発行

画像を選択するIntent

        Intent pickPhotoIntent = new Intent()
                .setType("image/*")
                .setAction(Intent.ACTION_GET_CONTENT);

カメラで撮影するIntent

カメラで撮影する場合、以下のIntentでも撮影→その画像を受取ることができますが、そのままでは画像サイズがとても小さくなってしまいます。(サムネイルサイズの小さな画像が返ってくる)

        Intent takePhotoIntent = new Intent()
                .setAction(MediaStore.ACTION_IMAGE_CAPTURE);

複数のIntentを埋め込む

        Intent chooserIntent = Intent.createChooser(pickPhotoIntent, "画像を選択");
        chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS,new Intent[]{takePhotoIntent});

作成したIntentの1つを元にしてcreateChooser()を呼び出して作成したIntentに、Intentの配列を埋め込みます。

画像を受け取る

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        if(requestCode == REQUEST_GET_IMAGE && resultCode == Activity.RESULT_OK) {
            if (data != null) {
                Bitmap image = null;
                if (data.getExtras() != null && data.getExtras().get("data") != null) {
                    image = (Bitmap) data.getExtras().get("data");
                    mImageView.setImageBitmap(image);
                } else {
                    try {
                        InputStream stream = getContentResolver().openInputStream(data.getData());
                        image = BitmapFactory.decodeStream(stream);
                        mImageView.setImageBitmap(image);
                    } catch (FileNotFoundException e) {
                        e.printStackTrace();
                    }
                }
            }
        }
        super.onActivityResult(requestCode, resultCode, data);
    }

Intentによって選択されたファイルは、当該ファイルを一意に識別するためのUriがIntentに埋め込まれて返ってきます。これはdata.getExtra()で取得できます。上記の例ではBitmapファイルとして取得して、独自View(mImageView)に渡しています。

Read full post gblog_arrow_right

音声コマンドで自分の作ったアプリのActivityを起動する

Android Wearでアプリを起動するのに音声入力でアプリが起動できるととても便利です。Wear用アプリを作る上では外せない要素だと思います。

Android Developersのトレーニングを見ると、AndroidManifest.xmlでintent-filterかけておくだけでいいということです。activityに設定したlabelをキーワードとして、Activityが起動するようになります。

ぶっちゃけると、ラベルをしっかり設定さえすれば、初期状態で音声入力によってActivityが起動するということであります。

Adding Voice Capabilities – Android Developers

しかしいくらやってみてもうまくいかなくて、何がいけないのかサッパリ分かりませんでした。

単純すぎるのか調べてもなかなかピタリとくる情報もなくて困っていたら、Stack over Flowを見て謎が解けました。

Wear: Open my app with custom voice Start command, not working – Stack Over Flow

つまるところ、mobile側のActivityにintent-filterをつけてないとうまく動作しないのです。

私はデバッグのため、wear側のアプリしか動かしていませんでした。(開発中のサンプルアプリはwearにしかインストールされていない状態)

スマホ側に音声コマンドを受け取るintent-filterがなかったためにWear上のActivityも起動しなかったということなんだと思います。

Wearアプリを開発する場合は、Wearモジュールだけでなく、mobileモジュールも実行してスマホにインストールしておかないと、ちゃんとした動作確認ができないということが分かりました。

実験

構成

Android StudioのNew Projectウィザードで作成した初期状態のままです。

wearモジュールもmobileモジュールも、Hello Worldの文字列を表示するだけのMainActivityがあるだけの状態です。

mobileのラベルとwearのラベルを同じにする

mobile側のActivityのラベルに「サンプル」と設定して、wear側のActivityのラベルにも「サンプル」と設定します。

この状態でOK Googleから「サンプル開始」と言うと、WearのMainActivityが起動します。スマホのMainActivityは起動しません。

mobileのラベルとwearのラベルを異なるものにする

mobile側のActivityのラベルに「サンプル」と設定して、wear側のActivityのラベルに「テスト」と設定します。

この状態でOK Googleから「サンプル開始」というと、スマホ側のMainActivityが起動します。(Wear端末には「アプリを開いています・・・」というメッセージが表示され、スマホ側で指定したActivityが起動します)

一方で「テスト開始」というと「テスト開始」でWeb検索を行った結果がWear端末に表示されます。

どちらにせよWearのMainActivityは起動しませんでした。

スマホ側での音声入力

ちなみにスマホ側でOK Googleからの音声入力を行った場合は、全てWeb検索として扱われてしまい、MainActivityは起動しませんでした。

Read full post gblog_arrow_right

adbコマンドを使ってアプリを手動で削除する

adbコマンドを使ってアプリを手動で削除するのは、スマホのアプリを作成する上では必要ないと思っていましたが、Android Wearアプリを作る場合には覚えておいた方がいいです。

というのもWearに一度インストールしたアプリは、Wear上での操作では削除することができないからです。

スマホ経由でインストールしたアプリの場合、スマホ側でアプリを削除すればWearにインストールされたアプリも一緒に消えてくれますので、一般的にはあまり問題にならないのかもしれません。

しかしWearアプリを開発していると、デバッグのためなどでWearに直接アプリをインストールすることが多くなります。こうなるとWearがデバッグ用のアプリで埋め尽くされる事態になってくるのです。

インストールされているパッケージの一覧を確認する

adb shell pm list package

ターミナルからコマンドを入力すると、対象デバイスにインストールされているパッケージの一覧が表示されます。

adb shell pm list package

アプリを削除するためにはパッケージ名が必要になるので、このコマンドで確認しましょう。

ちなみにパソコンに複数の端末が接続されている場合、adbコマンドを送るデバイスを指定する必要があるので注意しましょう。

アプリを手動で削除する

adb uninstall アプリのパッケージ名

adb uninstall

Wearのアプリを削除する場合は、コマンドの結果が返ってくるまで時間がかかります。

Wearの初期化のほうが早いかもしれない

ちなみに、Wearを初期化してしまえば済む話でもあるので、手動で消さなくてもなんとかなる話ではあります。Wearは初期化したところでスマホとペアリングし直すだけでほぼ元に戻ると言っても過言ではないため、初期化したほうが手っ取り早いのかもしれません。

ただ、サンプルアプリを1個インストールする度に初期化するのも馬鹿らしいので、コマンドを使えば簡単にアプリを消せるということを知っておくと何かと便利かもしれません。

Android Wearアプリ開発にエミュレータを利用する

Android Wearアプリを開発する際にエミュレータを利用する場合の話です。

開発中のアプリを実行してデバッグを行うためには、エミュレータなり実機なりを用意する必要があります。Wearアプリの場合、スマホとWear端末が必要になるため、普通のスマホアプリを開発するより用意するものが多くて面倒なところです。

最も簡単なのはスマホとWear端末共に実機を用意することです。既にペアリングを行った実機があれば、その2つをパソコンにUSB接続すればデバッグできます。特に設定を要しません。

一方で、片側をエミュレータ、もしくは両方をエミュレータでデバッグしたい場合は話がややこしくなります。

エミュレータを利用するにしてもスマホは実機で

エミュレータではBluetooth通信まではエミュレートしてくれないので、ポートフォワーディングを利用してスマホ・Wear端末間の通信を再現します。

片方をエミュレータにする場合でも簡単なのはスマホを実機で、Wear端末はエミュレータでやる方法です。

というのもAndroid Wearとのペアリングを行うためには、スマホ側で「Android Wear」というアプリを操作する必要があります。

スマホをエミュレータに置き換えてやろうとすると、このAndroid Wearを使えるようにするのが難しいようなので大変だと思います。どうも直接apkを拾ってきてエミュレータにインストールしないといけないようなので・・・。

Android Wearアプリを開発する場合、基本的にはスマホもWear端末も実機を用意するのがオススメです。実行速度の観点からもそれが一番だと思います。

Android WearのエミュレータはAVDを利用せざるを得ず、上述のポートフォワーディングを利用してペアリングを行ったとしても、端末間の通信は実機に比べるとだいぶタイムラグが生じます。

スマホ実機とWearエミュレータをペアリング

パソコンにスマホ実機をUSBで接続し、AVDでWearエミュレータを起動した状態から始めます。

まずターミナルからポートフォワーディングを行うようコマンドを入力します。

adb -d forward tcp:5601 tcp:5601

ポート番号は何でもいいようです。(ただし現在使われていないものでないとダメ)

ちなみに-dはUSBで接続されているデバイスという意味です。-dをつけるか、デバイスを直接指定しないとerror: more than one device and emulatorとエラーが出ます。

特にエラーメッセージが表示されなければ成功です。

スマホからAndroid Wearアプリを起動し、右上の三点ドットをタップ→新しいウェアラブルとペア設定を選びます。(歯車アイコンの設定ではないです)

端末を選択画面が表示されるので、右上の三点ドットをタップして「エミュレータをペア設定」を選べばエミュレータと接続完了します。

エミュレータをペア設定

どうでもいいことですが、ペアリングが完了するまでの速度だけは実機より早いです。

Wear端末(実機)とペアリングし直す場合は、エミュレータから切断を行った後、端末を選択画面から自分の使っているWear端末を選べばペアリングし直されます。

adbによるポートフォワーディングについて補足

ちなみに現在adbでポートフォワードを行っているポートを確認するには以下のコマンドを使います。

adb forward --list

現在行っているポートフォワーディングを止めるには以下のコマンドを使います。

adb -d forward --remove ポート番号

全てのポートフォワーディングを解除してしまって問題ないならadb forward --remove-allでもいけます。–remove-allの方が入力する量が少なくて楽かもしれません。

GitHubで公開されているプロジェクトをAndroid Studioで開く

GitHubで公開されているサンプルやライブラリプロジェクトをローカルに拾ってきて、そのプロジェクトをAndroid Studioで開く方法についてです。

GitHubからソースコードをcloneする

取得したいプロジェクトをgit cloneなりDownload ZIPなりでリポジトリから取得してきます。

今回はandroidmvp – GitHubをcloneしてみました。

ソースコードを保管したいディレクトリに移動して次のコマンドを叩きます。

git clone リポジトリのURL (ディレクトリ名:省略可)

今回の場合だと、git clone https://github.com/antoniolg/androidmvp AndroidMvpという感じです。ディレクトリ名はつけなかったらリポジトリのものがそのまま使われます。私は分かりやすいようにと、既存のプロジェクトと名前を揃える意味でAndroidMvpとしました。

gitコマンドなんてよく分からないという人は、素直にDownload ZIPでソースコードを拾ってくるといいでしょう。

Android Studioで開く

Import project

Open an exisiting Android Studio projectではなくImport Project (Eclipse ADT, Gradle, etc.)を選ぶのがポイントです。

Gradle形式のプロジェクトだから、前者で開くのかなと思ったら全然開けなくて困りました。

プロジェクトによっては開けるのかもしれませんが、Gradle Homeの場所を指定するように言われる場合は、後者のImportの方を選ぶといいです。

Gradle Homeを指定するように言われる

この場合、/Applications/Android Studio.app/Contents/plugins/gradle/libを指定するといいなんて情報を見かけたのですが、指定してもうまくいきませんでした。

Gitで管理するプロジェクトファイルの設定によって変わってくるものなのかもしれませんが、GitHubなどで公開されているプロジェクトをAndroid Studioで開くには、Import projectで読み込むようにしたほうが無難なのかもしれません。

Android Studioで直接GitHubで公開されているリポジトリをcloneする

GitHubに公開されているソースコードは、Android Studioからcloneすることも可能です。

まずCheck out project from Version ControlからGitHubを選びます。

Check out project from Version Control > GitHub

Read full post gblog_arrow_right

Wear端末をパソコンに接続し、Android Studioでデバッグできるようにする方法

せっかくAndroid Wear端末を手に入れたのだから、Wearアプリも作ってみようかなと思いましたが、Wear端末をAndroid Studioに認識させるのも一苦労です。

Android Wearアプリのデバッグやら実行状況を確認するのにUSBで接続するには、クレードル経由でパソコンに接続する必要があります。しかしクレードルを持ち運ばないといけないのは非常に面倒くさいです。

ちなみにクレードル経由でUSB接続すれば、パソコンにAndroid Wearが認識されてlogcatも確認できます。(クレードルとWear端末は充電端子でしか繋がっていないのに、いったいどういう仕組でLogcatが確認できるんでしょうか・・・)

それはともかく、USB経由で繋ぐにはクレードルを持ち運ばなければならず、腕にはめたままデバッグできないのは面倒くさいです。

そんな場合に備えてBluetooth経由でデバッグすることも可能です。

Bluetooth経由で接続する方法

Bluetooth経由はクレードルを持ち運ばなくて済む点はGoodですが、一方でその他の面で面倒くさいです。

  1. Wear端末とペアリングしているスマホをパソコンにUSBで接続する。
  2. スマホ側でAndroid Wearアプリを起動し、設定(歯車のアイコン)→Bluetooth経由のデバッグを有効にする
  3. Wear端末側でBluetooth経由のデバッグを有効にする(事前に開発者モードを有効にしておく必要あり)
  4. パソコン側でadbコマンドを打ち込み接続を行う
以上のステップを踏むことで、パソコンにWear端末が認識されるようになります。

Wear端末の開発者モードを有効にするには、設定→端末情報→ビルド番号を7回タップします。

adbコマンド

adb forward tcp:4444 localabstract:/adb-hub
adb connect localhost:4444

ポートは自分で決めていいみたいです。

Android StudioのTerminalタブで打つなり、Macのターミナルを起動して打つなりすればOKです。

スマホを繋いだ時に自動的には認識してはくれないので、毎回このコマンドを打たなければなりません。

スマホのAndroid Wearアプリの表示

Bluetooth経由のデバッグを有効にすると、その下にホストとターゲットの表示が出てきます。

ホストはパソコンのことで、adbコマンドを打って接続してやる必要があります。

ターゲットはWear端末のことです。Wear端末でBluetooth経由のデバッグを有効にすれば接続状態になります。

ホストとターゲットの両方が接続状態になると、パソコンからWear端末が認識できるようになります。

ちなみにWear端末のBluetooth経由でバッグをオフにする度に、再度adbコマンドを打ち込まなくてはなりません。

Bluetoothデバッグ中のAndroid Wear

Bluetooth経由のデバッグを有効にすると、常に「Bluetooth経由のデバッグが有効です」と表示され、他のWearアプリを動かしたりできなくなります。

開発中のアプリをWear端末で実行することはできますが、Wear端末からは設定を開く以外なにもできなくなります。

Bluetooth経由のデバッグが有効と常に表示される

結局どっちがいいのか

スマホとWear端末を行き来する必要があるので、Bluetooth経由でのデバッグも面倒くさいです。

Read full post gblog_arrow_right

Android StudioでLogcatが表示されず、何が原因でアプリが落ちてるのかわからなくて困った話

Android Studioでデバッグ実行を行った際に、起動直後にアプリが終了してしまう症状に悩まされました。通常ならLogcatが表示されるはずなのに、それすら表示されなかったため、何が原因で落ちてるのかすら分かりませんでした。

通常、デバッグを実行すると、

デバッグの実行

Logcatが表示されるのですが、何の反応もなくアプリだけが落ちているという状況に陥ったのです。

通常ならLogcatが表示される

他のプロジェクトだと普通に表示されるのに、特定のプロジェクトでだけLogcatも何も表示されずに落ちるのです。アプリが落ちる原因もわからない上に、Logcatが表示されない理由も分からないと、ムダにハマってしまいました。

最終的には、使っていたFragmentのonCreate()super()を呼び出していなかったことが原因でアプリは落ちていました。たったそれだけなのに、Logcatが確認できないせいで迷走してしまったのです。

今回記事を書くに当たり、super()をわざと呼び出さないサンプルプロジェクトを作って再現するかどうか試してみたんですが、普通にLogcatが表示されました。super()呼ばなかったせいで表示されなかったのかなと思ったのですが、どうも違うようです。

なぜAndroid StudioでLogcatが表示されなかったのかはよく分かりませんが、もし同様のトラブルに遭遇した場合に備えて、ADMでLogcat確認できないか試してみましょうというお話です。

そんなときはADMを使う

Android StudioでLogcatが見えなければADMを使います。

Android Studioの右上にあるドロイド君のアイコンを押せば、Android Device Monitorが起動します。(Android SDK > Tools > Monitorが実体です)

ADMの起動アイコン

何かいろいろありすぎてよく分かりませんが、本格的なデバッグはこれを使うといいと思います。Android Studioからデバッグできなくとも、ADMのLogcatなら表示されていました。

adb kill-serverとかしても効果がなかった

ちなみにadbの調子が悪いのかと、adb kill-serveradb start-serverも試してみたのですが全く効果がありませんでした。

というか他のプロジェクトだとLogcatは表示されていましたし、該当のプロジェクトでも単にActivityだけを表示させたらLogcat普通に出ていたので、adbのせいではなかったんでしょうけどね。

そもそもなんかおかしかったら再起動が吉

わざわざADMを使うよりも、素直にエミュレータ、Android Studioを再起動、(それでもうまくいかないならOSごと再起動)するのが一番いいかもしれません。

使っているうちに終了したつもりがプロセスが生きたままになってるということはまれによくあることです。

私はエミュレーターにGenymotion使っていますが、終了させたのにVirtual Box上では動きっぱなしになっていることがよくあります。

本題でないところにこだわって無為に時間を使うより、さっさと再起動した方が早かったように思います。

Android Studioをインストールする(Windows 8.1 64bit)

Android Studioをダウンロードしてきてインストーラーを起動してインストールします。

Android Studioをインストールするには、まずJDK1.7以上が必要です。

JDKをインストールしていない、もしくはインストールしているがJDKへのパスが通っていない場合、Android Studioのインストーラーで「JDKの場所を指定してください」というメッセージが表示されます。

Android Studioインストール時にJDKの場所を聞かれる

この画面が表示されたら、一旦インストールを中止し、JDKのインストールと環境変数の設定を行いましょう。

JDKをインストールしている場合、JDKの場所を指定してやれば先へ進めるかと思います。しかしここで場所を指定するより、環境変数の設定を行った方が後々便利だと思うので、後述する環境変数の設定を行うことをオススメします。

JDKのダウンロードとインストール

OracleのサイトからJDKをダウンロードしてインストールします。

Oracle – Java SE Downloads

JDKは開発ツールが含まれたものになります。JREとは違うので注意してください。

JDKを選ぶ

ダウンロードページに飛んだら、Accept Licenseにチェックをつけて、自分のWindowsが32bit版ならWindows x86を、64bit版ならWindows x64をダウンロードしてインストールします。

Accept LicenseにチェックをつけてJDKをダウンロード

JDK1.8でもいいのか

このスクリーンショットはJDK1.8(JDK 8)のダウンロードとインストールを行っています。

1.8だとエラーが出るというような情報もあるので、1.8だとインストール出来ないのだろうかと試してみた際に撮ったものだからです。

1.8でもAndroid Studioのインストール、Wizardを使って作ったHello Worldプロジェクトの実行までは無事にできました。

ただ公式にはJDK1.7(JDK 7)が必須とあるので、敢えて1.8で冒険する必要はないような気もします。

1.8だと問題あるのかよく分からないので、詳しい方は教えてくださると助かります。

環境変数の設定

JDKをインストールし終わったら、今度は環境変数の設定を行い、JDKへのパスを通します。

Windows 8.1の場合、コントロールパネル→システムとセキュリティ→システムを開き、システムの詳細設定を開きます。

システムの詳細設定を開く

そうするとシステムのプロパティが開くので、詳細設定のタブの下にある環境変数のボタンを押します。

システムのプロパティから環境変数のボタンを押す

ユーザー環境変数とシステム環境変数と2つありますが、どちらに追加しても構いません。ユーザー環境変数だと、現在Windowsにログインしているユーザーだけ有効になるだけです。今回はシステム環境変数で設定します。

新規ボタンを押し、変数名にJAVA_HOME、変数値にJDKのインストール先を指定します。特に変更していなければ、C:¥Program Files¥Java¥jdk1.8.0_31という感じになっていると思います。(数字はインストールしたJDKのバージョンによって異なるので、自分の環境に合わせて指定しましょう)

システム環境変数の新規ボタンを押し、JAVA_HOMEを設定する

以上で環境変数の設定は完了です。

Android Studioのインストール

環境変数の設定さえしてあれば、Android Studioのインストーラーの指示にしたがって「次へ次へ・・・」と進んでいけば特に迷うところはないと思います。

Read full post gblog_arrow_right

Android StudioでButterKnifeを使う

ButterKnifeはViewのインジェクションに特化したライブラリです。

Android Studioで利用する場合はとても簡単で、app/build.gradleのdependenciesに1行追加するだけです。

app/bulid.gradleに1行追加するだけ

    compile 'com.jakewharton:butterknife:6.1.0'

これだけで使えるようになります。

ButterKnifeを使うことでfindViewById()をコードからなくすことができるので、ActivityやFragmentのコードがすっきりします。

public class MainActivity extends ActionBarActivity {

    @InjectView(R.id.test)
    TextView mTextTest;
    @InjectView(R.id.hello)
    TextView mTextHello;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.inject(this);

        mTextTest.setText("ButterKnife Sample!!!");
        mTextHello.setText("Next text here!!");
    }
}

ButterKnifeサンプルの実行結果

@InjectView(ViewのID)で、TextViewなどを保持するクラスフィールドを指定してやります。

後はonCreate()内でButterKnife.inject(this)を実行すれば、findViewById()を使うことなく、Viewに対する操作ができるようになります。

扱うViewが多くなればなるほど、その効用が実感できるようになります。

ButterKnifeを使わない場合、以下のようになります。

public class MainActivity extends ActionBarActivity {

    TextView mTextTest;
    TextView mTextHello;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        (TextView) mTextTest = (TextView) findViewById(R.id.test);
        (TextView) mTextHello = (TextView) findViewById(R.id.hello);

        mTextTest.setText("ButterKnife Sample!!!");
        mTextHello.setText("Next text here!!");
    }
}

Android Studioだとbuild.gradleに1行追加するだけで使えるようになるので、とても便利ですね。

GitHub – ButterKnife