どうも、nkzn.netの更新を忘れてて転売屋に取られた人です。
今日はAndroid Bazaar and Conference 2014 Springですね。僕は業務都合的なアレで今回のABCに参加できないため、夜の裏会だけ行きます。
ただ、全くなにもしないのも寂しいので、景気付けに１本記事を書かせてもらいました。Effective Androidトラックの発表内容とネタ被りしたらごめんな！！
たぶん@mhidakaとか@sys1yagiさんがこの記事より良いこと喋ってくれると思うので、みなさん秋葉原UDXで著者たちと握手！！（宣伝）
- 作者: TechBooster,小太刀御禄,出村成和,重田大助,西岡靖代,宮川大輔,柏本和俊,あんざいゆき,八木俊広,木村尭海,小林慎治,有山圭二,中西良明,わかめまさひろ,新井祐一,桝井草介,久郷達也,寺園聖文,shige0501,山下智樹,前田章博,秋葉ちひろ,末広尚義,中澤慧,日高正博,塚田翔也,井形圭介,中川幸哉,山崎誠,山下武志,なまそで,橋爪香織,さとうかずのり,l_b__,ゼロハチネット,長汐祐哉
- 出版社/メーカー: インプレスジャパン
- 発売日: 2014/01/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (8件) を見る
はじめに
さて、ここ何ヶ月かで、「実際Android Studioどうなん」という質問を受ける機会が増えてきたので、ここらで一度、僕がAndroid Studioを常用していて嬉しいと感じていることを書きなぐってみました。
- はじめに
- 1. Gradleが標準ビルドツールとして採用されている
- 2. dependencies設定でライブラリ取り放題
- 3. AARなライブラリプロジェクトもdependenciesで取ってこれる
- 4. ビルドの種類を定義してソースフォルダ単位で切り替えられる
- 5. Android Studioのプロジェクト設定がGradle依存
- 6. 画像リソースの小さいプレビューがXMLやJavaから見える
- 7. colorリソースの色がXMLやJavaから見える
- 8. 各種リソースの参照が文字として見える
- 9. レイアウトXMLがテキストエディタモードでもリアルタイムプレビューできる
- 10. Kotlin言語が使える
- まとめ
- あわせて読みたい
昨年１１月から、業務で約４ヶ月使ってみての感想です。新人研修にも１ヶ月ほど使ってみています。
前半はどちらかというとAndroid Studioを使うことで利用可能になるGradleがいいよね的な話、後半はAndroid StudioというIDE自体の話です。
IntelliJ IDEA + Android Pluginでも同じようなことできると思うので、「IntelliJ IDEAを使うべき〜」に読み替えてもいいです。Android StudioをやめてIntelliJ IDEAを使うべき10の理由を書きたい人は是非お願いします！！！
※ここ４ヶ月、ほとんどEclipse+ADTの環境を触っていないので、「それEclipseでもできるよ！！！！」なことがあったらごめんなさい＆お知らせください
1. Gradleが標準ビルドツールとして採用されている
この記事を書き始めたモチベーションはこれが８割です。でも書き終えてみたら愚痴ばかりであんまり面白くなかったので、読み飛ばして次へ行ったほうがいい気がします。
読み飛ばす方のための１行まとめ：Android Studioが標準対応しているGradleは、Androidアプリ向けのビルドツールとしてAntやMavenより柔軟で使いやすいので良いよ！！
原初の時代：Ant
Eclipse（というよりは、旧来のAndroid App Projectの構造）では、コマンドライン向けの標準ビルドツールがAntでした。で、Eclipseからならサクッとできる方法が、コマンドラインからだとクソ面倒くさかった印象があります。
模索の時代：Maven
ビルドプロセスやライブラリ依存性をもっと柔軟に管理したかった人々が次に手を出したのがMavenでした。MavenにはMaven Central Repositoryというライブラリ置き場があり、設定ファイルにライブラリ名とバージョンを記述することで、ライブラリをダウンロードしてきてプロジェクト内で利用できるという、バージョン管理システムに優しい感じの仕組みもあり、有望かと思われました。少なくとも、コマンドラインからビルドやテストが実行できるという点で、CIのしやすさという条件は満たしていました。
が、そもそもMavenの設定ファイルであるpom.xmlはちょっと闇が深い系のアレであったことや、公式ツールではないことによる不安定さ（環境を安定させるために熟練の業を要した）、環境構築の度にmaven-android-sdk-deployerを実行するのがダルい、などの理由により、使いやすいかと言われるととても頷けるものではなかったと思います。
新たなる息吹：Gradle
そこにGoogleが公式にぶっ込んできたのがGroovyベースのDSLであるGradleとなります。手続き型な感じのスクリプトで、個人的にはMavenのXMLよりも何が書いてあるのか読みやすいと思いました。また、Maven Central Repositoryも利用できるため、ライブラリの取得も容易です。Groovyがそのまま書けるため、いざとなれば柔軟な処理も書けるのも、ポイントが高いところです。
Gradle Wrapper(gradlew, gradlew.bat)の仕組みにより、デベロッパーの手元にシェルやbatの実行環境（と、Android SDKへのパス）があれば、それだけでプロジェクトのビルドができてしまう点も、チーム開発やオープンソース開発を行う上では嬉しい点です。
そして、Android Studio側でビルドなボタンを押した時の挙動は、コマンドラインから ./gradlew assembleDebug をしたときと同じ。もう「IDEからは動くのに、コマンドラインからだと動かない」なんて謎現象に悩まされる必要はありません。*1
何を言いたかったかというと
Mavenでプロジェクト管理するの凄く苦しかったからGradleで管理できるようになって嬉しかった。（私怨 && 小並感）
2. dependencies設定でライブラリ取り放題
さて、Eclipse+Mavenだとpom力（ぽむりょく）を磨かないといけなくてマジファックでしたが、Android Studio + Gradleでは、↓のようなコードをbuild.gradleの中に書くだけでライブラリのダウンロードを行い、Androidアプリの中で使えるようにしてくれます。
dependencies {
compile "com.nineoldandroids:library:2.4.0"
}
compile "group_id:artifact_id:version" な感じですね。Mavenの枠組みで配布されているライブラリはこれで取ってこれます。DaggerだってPicassoだってすぐに使えるようになります。
GradleやAndroid Studioはまだまだ浸透してきたとは言いがたいですが、Maven Central RepositoryでJARライブラリを公開するのはJava界隈で既に広く浸透している文化ですので、この仕組みによって得られる恩恵は計り知れないと言ってもいいでしょう。
ライブラリ導入のコストが滅茶苦茶下がりました。やったね！！！
3. AARなライブラリプロジェクトもdependenciesで取ってこれる
AARはAndroid ARchiveの略らしいです。JARのAndroid版だという認識ですけどよくしらない。どうやらライブラリプロジェクトをビルドしたときに生まれる、ファイルとしての実体みたいですね。（そういう意味では、APKファイルに類する存在なのかも）
さて、この形式のライブラリプロジェクトは、作者が頑張ってくれている場合、gradleのdependenciesで取ってこれます。
詳しくはゆーいち先生の記事を御覧ください。
実際にこの形式で配布されているライブラリとしては、@sys1yagiさんのIndirectInjectorなどがあります。
4. ビルドの種類を定義してソースフォルダ単位で切り替えられる
社内向けデバッグ用、モニターユーザー向けリリース用、Playストア向け無料版リリース用、Playストア向け有料版リリース用、などの切り替えを、ビルド時にコマンドによって切り替えられる機能があります。Build TypeはDebugとReleaseの2種類ですが、Product Flavorは任意の数だけ用意できるので、色んなパターンのアプリを作らないといけない場合には便利な機能ですね。
下記の記事が詳しいです。
Build Variants によって別バージョンの Android アプリを同じプロジェクトからビルドする (Gradle 使用) - ひだまりソケットは壊れない
5. Android Studioのプロジェクト設定がGradle依存
プロジェクトフォルダの構造が少し複雑になってきたりすると、ソースが入ったフォルダをビルドパスに追加し忘れる凡ミスにより、上手くビルドできなかったりした経験はないでしょうか。
Android Studio + Gradleの環境では、settings.gradleやbuild.gradleに記述した内容がAndroid Studioのプロジェクト設定に直接反映されるため、そういったミスが起きづらくなっています。
また、チーム開発時にも、IDEの初期設定に割く時間を減らせそうです。
Intellij IDEAみたいに Mark Directory As > Test Source Root みたいな感じでIDEからソースフォルダを指定したくなるときもありますけどねー。
6. 画像リソースの小さいプレビューがXMLやJavaから見える
JavaやXMLで、drawableリソースの中身がエディタの左端に出てきます。
Javaのほうは式として成り立っていなくても出てきたので、判断基準が結構適当みたいです。
7. colorリソースの色がXMLやJavaから見える
JavaやXMLで、colorリソースの色がエディタの左端に出てきます。
color.xmlはなかなか壮観ですね。
いまどんな色が画面に出ているのかコードを書きながらイメージしやすいのは、嬉しい時もあるのではないでしょうか。（実はあんまり嬉しい場面が思いついていないけど綺麗なので挙げた）
8. 各種リソースの参照が文字として見える
XMLファイルやJavaファイルの中で、dimenやstringで定義した要素の値が、一時的に置き換えて表示されます。実際のファイル上で指定した値が書き換わるわけではなく、あくまでも見た目だけで、マウスオーバーすると元の値を見ることができたりします。
実際には↓のようになっているファイルも・・・
こんなふうに見えます。
Javaの中でgetString(resId: int)で呼ばれている値も同様に置き換えられます。
↑これが↓こうなる
これで、「あれ、このstringリソース、中に書いた日本語なんだったっけ？」とか「このdimen、実際には何dpだっけ？」なんて悩まずに済みますね！
9. レイアウトXMLがテキストエディタモードでもリアルタイムプレビューできる
レイアウトのXMLを編集すると、ほぼリアルタイムでプレビューに反映されます。Android Studio登場以前から、IntelliJ IDEAでAndroid開発をする際の魅力的な機能として挙げられていました。
何を置くとどんなふうに見えるのか、トライアンドエラーが大変捗るので、デザイナーさんやAndroid初心者なプログラマーの人にレイアウトXMLを勉強してもらう際にも、効果バツグンです。
10. Kotlin言語が使える
Android StudioはJetBrains製のIDEであるIntelliJ IDEAをベースにしているので、ちゃんと設定すればKotlin言語を利用することができます。Androidで使えるベターJava言語を探している方にオススメです。
Null-safety機能すっげえいいよ！！！！
まとめ
現状、僕がEclipseを使う理由は（業務上やむを得ないアレが無い限り）どこにもありません。*2
でも僕が魅力を感じているのはどちらかというとGradleのほうなので、ADTがGradleに対応したらそれはそれで触ってみたい気がします。
今回は「IntelliJ IDEAが元々持ってた良さ」みたいなものは基本的に挙げなかったので、他にもAndroid StudioやIDEAを敢えて使う利点はありそうです。そのへんは他の方が記事書いてくれてると思うので、探してみてください。
それでは、良いAndroidアプリ開発ライフを。
