ポエムです。
皆さん、Icepickをご存知でしょうか。ActivityやFragmentに書いたプロパティをSavedInstanceStateで保存/復元する責務だけを持つ、アンチAndroidAnnotations界隈では人気のあるAndroid向けライブラリですね。
このIcepickに、下記のコミットが行われました。
さよなら、@Icicle。
分かる人には分かる、寂しい変更です。この記事ではAndroid界の老害たちに向けて、昔を懐かしむ話をしたいと思います。
続きを読むポエムです。
皆さん、Icepickをご存知でしょうか。ActivityやFragmentに書いたプロパティをSavedInstanceStateで保存/復元する責務だけを持つ、アンチAndroidAnnotations界隈では人気のあるAndroid向けライブラリですね。
このIcepickに、下記のコミットが行われました。
さよなら、@Icicle。
分かる人には分かる、寂しい変更です。この記事ではAndroid界の老害たちに向けて、昔を懐かしむ話をしたいと思います。
続きを読むBBCさんの取り組みがあまりにもアツくて、ちょっと気持ちが盛り上がってしまったので、今回は珍しく、かなりポエミーな内容を書きたいと思います。
英国BBC、ミニ基板コンピュータ『Micro Bit』100万台を無償配布。中1生全員にコーディング教育 - Engadget Japanese
全ての人がコンピュータを自在に操れる数十年後の世界に向けての取り組みが、どんどん増えてきています。
Scratch - Imagine, Program, Share
こういった取り組みへのコメントを見ていると、「普通の人がコンピュータを覚える必要なんて無い」と言った意見を見かけます。これは、昔の下流階級の人々が「普通の人が文字を覚える必要なんて無い」と言っていたのと同じことだと、私は思ってます。
手紙を書くにも、文字の読み書きができる人を探してきて、お願いするなりお金を払わなければいけなかった時代。現代の、プログラミングができる人、できない人の関係と似ていますね。
(私はプログラマーなので、ここから先の話はプログラミングに寄ります。コンピュータの広大な分野の中から一部分だけをピックアップすることをお許し下さい。)
こんな話をすると、「普通の人がプログラミングできるようになったら、プログラマーが職を失うじゃないか」という話が出てきますが、そうです、一般の人々が最低限作れるような、メモ書きレベルのプロダクトしか生み出せないプログラマーは職を失います。代筆を生業としていた人々も、同じく職を失っていったのでしょう (要出典) から、自然な流れです。
では、文章を書くプロの仕事はなくなったのでしょうか。そうではないのです。 作家、記者、詩人、作詞者、脚本家。現代でも、文章を書くことを生業にする人たちは、確かに残っているのです。
プログラミングによってものを作る職業は、きっと無くなりません。
ですが、おそらく、他人に頼まれたものをそのまま作る、という仕事は、少しずつ少しずつ、なくなっていくのでしょう。だって、ちょっとしたものならば、世間一般の(私達の子の世代や孫の世代の)人々は、自分で作れてしまうのですから。現在でも、Excelを上手に扱える人々は家計簿ソフトなどを買うことなく、家計簿を電子的に作成・集計できている*1ことを考えると、その片鱗は少しずつ現れているとも言えます。(Excelの式を書く作業は紛れも無くプログラミングです)
基板となる技術が一般に普及した後にも、生業としてお金を稼ぐことができるのは、その技術を「上手く」使って、他人にとって価値のあるものを生み出せる人です。私は、そう思っています。
識字率の上昇に伴い職を失っていった人がきっといたように、識コンピュータ率の上昇によって、職を失う人々が出てきます。でもきっと、その後にプロの仕事として残ったものが、プログラミングの、エンジニアリングの、本質的な価値なのではないでしょうか。
10年後なのか50年後なのか分かりませんが、そんな時代がいつかやってきます。
その時に向けて、エンジニアとしての自分の価値を、見直し続けていけたらいいなと、そんな風に思うのです。
どっとはらい。
タイトルはソロバンとコンピュータの対比みたいになってたのに、実際には識字率にしか注目していなかったことに書き終わってから気がついた。まあ寺子屋教育が日本にもたらしたもの的なニュアンスでなんとか。
*1:もちろん、クラウドにアップロードしたりといった付加価値の点では、市販のものに分があります
第40回勉強会(2015/02/21) - 長岡 IT開発者 勉強会(NDS)
第40回 長岡IT開発者勉強会に参加した皆様、お疲れ様でした。初心者Dayという名前ながら知見にあふれた良いイベントだったと思います。
さて、私は「Android再入門 〜Eclipseのことは忘れろ〜」と銘打ち、Android初心者向けにネット情報の取捨選択を行うにあたって考慮してほしいことを発表しました。
また、今回は講演内容をQiitaに下書きして、勉強会と同時に公開するという初めての試みも行いました。
Android再入門 〜Eclipseのことは忘れろ〜 #nds40 - Qiita
1週間で400ストックという凄いペースで伸びていて、承認欲求が大幅に満たされつつもビクビクしている日々です。
この記事では、今回試みたことを簡単に紹介したいと思います。
この順でやってみて、全体的には良かったと思っていますが、もちろんデメリットもありました。それぞれ紹介します。
単純に数だけ見れば資料を2本仕上げたことになるので、作業量としてはただスライドを作るよりも少し重くなりました。とはいえ、倍という程ではなかったと思います。
スライドだけを作っている分には、枚数を見ながら「1枚○分ずつは喋れるな」のような算段ができたのですが、Qiita向けの原稿を書く体で作っていると、実際に喋るときの分量が想像しづらく、作りすぎてしまいました。(実際に、15分枠だったセッションを30分枠に変更してもらうことになりました)
技術記事として成り立つものにしようというスタート地点で原稿を書き始めると、スライドにキーワードを書き連ねていくよりも具体的に発表テーマについて検討することができます。また、スライドに比べて1つの見出しに書ける一連の情報を大きくできるため、情報に深みを持たせることができました。
勉強会の後にSlideShareやSpeaker Deckに資料を公開して、当日会場にいた人やいなかった人が見れるようにすることは一般的になってきています。公開を前提にしてスライドを作成する講演者も多いのではないでしょうか。
資料の公開自体はありがたいのですが、少し困ったことが起こります。喋る内容を概ね再現した資料を作成しなければならなくなるのです。講演者が読みながら喋るための「原稿としてのスライド」は、聴き手が読むことに集中してしまい、肝心の口頭の話を聞けなくなってしまう危険性を帯びています。
私の感覚では、講演スライドには2種類あります。
この2つのどちらを採用するかは、現場での読みやすさと公開時の資料としての価値を天秤にかけることになり、非常に悩ましいところでした。
ですが、今回のように「資料としての内容はQiitaに投稿する」と最初から決めてしまっていれば、迷う必要はありません。スライドだけなら冗長すぎて書けなかったような余談も含め、話題をガンガン深めていくことができます。
深めすぎた結果、喋れない分量になったらどうするって? そうなったらスライドを作るときに推敲して、省ける項目を原稿から省いてしまえばよいのです。
前述のとおり、「資料としてのスライド」を作る必要性が薄くなったので、「背景としてのスライド」に寄せられるようになりました。
文章量は極力抑えてみたところ、これまでのイベントでの講演に比べて、聞き手の目が僕に向いている時間がとても長かったように思います。ただ、当の僕が練習不足で、別途カンペを見ながらでないと喋れない状態だったので、聞き手のほうを見ながら喋ったりができなかったのが悔やまれます。
原稿にある内容を表現すればいいという性格上、新しくネタを考える時間は取られませんし、文章量も原稿に比べればかなり少ないです。そのため、原稿+スライドでかかる時間は、中身を悩みながらスライドだけを作る場合の1.5倍程度の時間でできるのではと思います。
Kobitoで重厚な原稿を書いて、軽いスライドで発表して、Qiitaに公開する。このサイクルで、公開スライドが抱えていたジレンマが少し解消されそうです。
スライドだけを作ると話題が中途半端になってしまうような感覚を持っている方は、是非このスタイルを試してもらえればと思います。
ウォーターセル株式会社では、農業分野でのITツールの開発・改善に一緒に取り組んでくれるAndroidエンジニアを募集しています。
農業IT分野がどんなものなのか話を聞いてみたいレベルでも結構ですので、興味のある方は@Nkznまで空リプを飛ばすなり何なりして、コンタクトを取っていただければと幸いです。
この記事はQiitaからの転載です。
Javaで「小数第N位以下を四捨五入したい」「ある桁はゼロ埋めしたいけど、あとは桁があるときだけ表示したい」などなど、数値を文字列で表現したい場合には、 java.text.DecimalFormat
を使うのが便利ですね。
今回はこのDecimalFormatで四捨五入が失敗するバグを見つけたので紹介します。
$ java -version java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
// Java8DecimalFormat.java import java.text.DecimalFormat; import java.math.RoundingMode; class Java8DecimalFormat { public static void main(String[] args) { final DecimalFormat df = new DecimalFormat("0.##"); df.setRoundingMode(RoundingMode.HALF_UP); String hoge = df.format(10.145); System.out.println(hoge); // 10.14 String fuga = df.format(13.555); System.out.println(fuga); // 13.55 } }
四捨五入を期待して RoundingMode.HALF_UP
を指定しているにもかかわらず、挙動としては切り捨てになってしまっています。
[#JDK-8062013] DecimalFormat / rounding / HALF_UP - Java Bug System
OpenJDKのバグトラッカーに同様の報告が上がっていました。ver1.8.0u20にも同様のバグがあったので、それなりに前に混入したバグなのかもしれませんね。
テストコードの処理系をJDK1.7からJDK1.8に切り替えた途端にいくつかのテストが通らなくなり、原因を色々探した結果がこれでした。さて、どうしたものか。。。
問題切り分けのために、他のパターンでも実験してみました。
// jdk1.7.0_21 String hoge = df.format(10.145); System.out.println(hoge); // 10.15 String fuga = df.format(13.555); System.out.println(fuga); // 13.56
JDK1.7.0u21環境での実行結果です。期待した結果が出ています。
10.145 は 10.1449(以下略)という内部数値だったはず
コメント欄で上記のご意見をいただいたので、もう一桁加えてみました。
// jdk1.8.0_25 String hoge = df.format(10.1451); System.out.println(hoge); // 10.15 String fuga = df.format(13.5551); System.out.println(fuga); // 13.56
期待した結果が出ました。
丸め誤差の問題であれば、バイナリ的に綺麗になる $2^{-3}=0.125$ を処理する分には問題が起きないはずですね。
// jdk1.8.0_25 String piyo = df.format(0.125); System.out.println(piyo); // 0.13
期待した結果が出ました。
というわけで、古き良き浮動小数点の丸め誤差問題でした。
「java.text.DecimalFormatの四捨五入が切り捨てになるバグ」というタイトルで公開しましたが、実際には切り捨てではなく「丸め誤差で5が4扱いになってしまう」という現象でしたので、少しタイトルを変えました。
12/10に、ビジネス用途向けのチャットサービス「ChatWork」のAndroidアプリが大幅リニューアルされました。
チャットワーク社といえば、国内有数のTitanium Mobileをガッツリ触っている会社としても有名ですが、今回のリニューアルではAndroid SDK + Javaによるネイティブ化を断行したようです。(ツール選びに関する感想は最後に書きました)
というわけで、Facebookアプリのときに続きまして、OSSライブラリのライセンス一覧を眺めていたら面白かったので、各ライブラリに感想を入れていきたいと思います。
クックパッドAndroidアプリにおける最近のDB運用事情 - クックパッド開発者ブログ
クックパッドでも採用されて、苦しみの声が上がっているやつです。弊社では少し実用した後でContentProviderとの相性が死ぬほど悪い(検証当時)という理由でリプレイスしたことがある思い出深いライブラリでもあります。
現在ではContentProvider対応のPullReqがマージされたので、そのへんは解決されていると思われますが、作者が「5年以上ActiveAndroidやってきたけどさー、今の設計だとコレ以上パフォーマンス出ないんだよね。だから発想変えて別のO/Rマッパー作るわ!」とかぶっちゃけてて、今後の開発どうなるんだろう、と不安になるところです。 ただ、当のOllieとやらも数ヶ月更新が無いので、pardomさんが何かの拍子に我に返ったという可能性もあります。 (2015/1/19訂正:別ブランチで作業をしていただけなのか、全然活発に開発してらっしゃいました。)
後述のRealmと用途が被ってる部分もあるので、何と使い分けてるのかなという気持ちもあります。
とりあえず、O/Rマッパーとしての使い勝手や、クエリの発行しやすさで言えばORMLiteよりも楽な気がするので、良いライブラリだと思います(こなみ)
com.path:android-priority-jobqueue:1.1.2
今回初めて存在を知ったやつです。やたら動く(+)ボタンで一世を風靡したPathが公開しているライブラリなんですね。
順番に実行したいタスクをAsyncTaskとかLoaderとかServiceとかで実装するのは大変手間なので、良い感じに順次実行してくれる的なやつでしょうか。便利そうです。
com.jakewharton:butterknife:6.0.0
安定のJW。(広義で)Squareからの刺客その1。
アノテーションによるfindViewById
やsetOnClickListener
の簡素化といったどこかで聞いたことのある機能を提供してくれるライブラリですが、他のライブラリに比べると責務を絞ってあり軽量であるという印象があります。
今度弊社でも採用しようかなと思っているところです。
というかAndroidAnnotationsは重厚すぎて全力でロックインする覚悟がないと採用しづらいし、RoboGuiceはスーパークラスを汚染するしで他に選択肢がない
com.x5dev:chunk-templates:2.6
今回初めて知ったやつです。
Java向けのHTMLテンプレートエンジンらしいです。このへんを見ると分かりやすいでしょうか。WebViewに表示を任せている部分があるということだと思います。
de.greenrobot:eventbus:2.4.0
出た!死ぬほど便利なやつ!
従来はBroadcast Intent+BroadcastReceiverなどで実現していた「ある場所から別の場所へイベントを通知する」という目的を良い感じに果たしてくれるライブラリです。一説では、Fragment→Activityの通知や、Service⇔Activityの通信はもう全部これでいいんじゃないかという話もあります。
もちろん飛び道具の類なので、多用すると状態が増えすぎて死ぬ危険が増しますが、適切に使えば強い味方になってくれるはずです。
com.getbase:floatingactionbutton:1.3.0
チャットワークアプリの新UIの中で、一番おもしろかった部分です。
今回のリニューアルの目玉の1つがMaterial Designへの対応でしたが、その中でもFloating action buttonの実現にフォーカスしたライブラリがこちらになります。
他にも makovkastar/FloatingActionButton(★1024) や FaizMalkani/FloatingActionButton(★450) がある中で、このライブラリが選ばれたのは、ボタンが増えるアニメーションの面白さでしょうか。
実際、チャットワークアプリの新UIをひと通り触った時は、僕もこの(+)ボタンを連打してしまいました。楽しいです。
しかしこれ、近いうちにappcompat-v7でサポートされて、リプレイスするかどうかの選択に迫られそうだなあ。ActionBarSherlock(→ActionBar)やViewPagerIndicator(→PagerTabStrip)が通ってきた道ですね。
compile 'com.github.frankiesardo:icepick:2.3.6'
provided 'com.github.frankiesardo:icepick-processor:2.3.6'
SavedInstanceStateを扱うのをちょっと楽にしてくれるライブラリみたいです。Android 1.6くらいの時代に使われていたIcicleという言葉が使われていて、古参の琴線をフルスイングで殴ってくる感じのライブラリになっています。
AndroidAnnotationsにも@InstanceState
っていう似たようなアノテーションあるけど、たぶんIcepickのほうがいい。
joda-time:joda-time:2.6
java.util.Calendar
がアホみたいに使いづらいのを何とかしてくれる神ライブラリ。あまりにも神すぎて、JDK1.8ではJoda-Timeにインスパイアされた形で"Date and Time API"(JSR-310)というのが入ったりしました。
参考: http://acro-engineer.hatenablog.com/entry/20130213/1360691391
ちなみに内部のメソッド数が4611個とかある(当社調べ)ので、dexのメソッド数65536上限問題に立ち向かうときには少しお気をつけて。
言わずと知れたJavaScriptライブラリ界の巨人ですね。Chunkと組み合わせてWebViewに使っていると予想されます。
com.googlecode.json-simple:json-simple:1.1.1
公式のorg.json
をシンプルにしたやつらしい。
たまにorg.json.JSONObject
とorg.json.simple.JSONObject
が紛らわしくてアレなイメージしかないんだけど、動作が速かったりするんだろうか。
com.squareup.okhttp:okhttp:2.1.0
Squareからの刺客その2。お手軽な使い勝手のHTTPライブラリ。
現状、AndroidでSPDYプロトコルが使える、数少ないネットワークライブラリなので、近年いろいろなところで重宝されているようです。
com.squareup.picasso:picasso:2.4.0
Squareからの刺客その3。素晴らしい画像読み込みライブラリです。
URL, Drawableリソース, java.util.File
オブジェクトなど、様々な形で画像を指定すると、とりあえずロードしてきてImageViewに放り込んでくれる素敵なライブラリです。画像表示はこれがないとやっていられません。
内部でOkHttpを全力で使って、画像のキャッシュにも対応しています。
iOSのCoreDataやSQLiteを置き換えるために生み出されたという、C++製RDBMSライブラリですね。
@wasabeef_jpさんがたまに 言及しておられるような印象があります。
ActiveAndroid的なクエリ発行の使い勝手の良さも感じますし、速度が凄いとのことなのでちょっと興味はあるんですが、流石にプロダクトに使っていい品質ではないだろうなあと邪推して、今のところは手を出していません。
流石チャットワークアプリさん、チャレンジャーだぜ!
と思っていたんですが、チャットワークアプリver3.0.3ベースで本記事を書き始めた後、ver3.0.4でRealmがライセンス一覧から消えました。どうやらRealmを使うのをやめたようです。
やはり人類にはまだ早すぎたのでしょうか。
SharedPreferenceに保存するKey, Valueそれぞれを256-bit AESで暗号化してくれるやつだそうです。自分でやるよりは楽そうですね。
com.squareup:android-times-square:1.4.1@aar
Square最後の刺客。カレンダーライブラリです。
おしゃれ感ありますよね(小並感)
ちょいちょい攻めてる感じのライブラリ選定をしていてアツいなと思いました(既に1件思い直されていますが)。ただJSON周りはJsonPullParserとか使うと型安全にマッピングできていいんじゃないかなと思ったり(ステマ)
あとやっぱりSquare社とJWに足を向けて寝られないことになっているアプリって多そうだなと再認識したところであります。
その他、RoboGuiceやAndroidAnnotations重すぎてつらいということを再認識できました。
チャットワークさんは社内チャットとして大変お世話になっておりますので、今後とものご繁栄をお祈り申し上げます。改めまして、リニューアルおめでとうございました。
やっぱりクロスプラットフォーム系ツールは保守が大変だったのかなあ、と邪推してはいるものの、「だったら最初からJavaで作ればよかったのに」とは思っていません。
恐らく、初期のメンバーのスキルセットの範囲で、最も早く顧客に価値を届けうる選択肢がTitanium Mobileだったのでしょう。
サービス発足初期は、迅速にプロダクト(≒価値)をユーザーに届け、使ってもらいながらサービスのどの部分の価値を最大限に高めていくのか見極めるのも、また1つの戦術です。
「顧客に本来届けたいもの」が出来上がるまで顧客に価値を全く届けないことより、80%くらいの中核となる価値を真っ先に届けた上で、フィードバックを得ながら時間をかけて「本来届けたかったもの」を届ける。外部から見て、チャットワーク社はこれを実践したように思います。
というわけで、現代のサービスの立ち上げ方、育ち方として、良い事例が1つ生まれたなあと思う次第でございます。
チャットワークCTOの山本さんも、似たようなお話を講演されていました。既に公知の話題だったことを改めて書いた形になって恥ずかしい(´・ω・`)
TypeScript 1.0のリリースを機に、ちょっとJavaScript方面にも手を出してみようかということで、最近はわかめ本を読みながらチマチマとコードを書いております。
今日は技評さんのjQuery記事をTypeScriptで写経しながら読み進めていました。
もちろんjquery.d.tsを使って型チェックを利かせながらの写経です。メソッドがサジェストされるのもなかなか気持ちが良いですが、 ajax(settings: JQueryAjaxSettings)
への渡し値であるJQueryAjaxSettingsがしっかり定義されているため、キーがサジェスト&プロパティ存在チェックされるわ、値に型チェックが入るわで、超気持ちいい感じです。
しかし、こうも型で守られた中で写経していると、むしろ型が付いていないところが気になってしまいます。特に今回の写経では、ジェネリクスが利いている each<T>(collection: T[], callback: (indexInArray: number, valueOfElement: T) => any): any;
にany型のcollectionを渡してしまうのは、型の確定を心待ちにしているであろう valueOfElement
さんにあまりにも申し訳が立たないと感じました。
というわけで、自前でインターフェースによる型定義を行ってみることにしました。YouTubeのAPIから返ってくるJSONは、本来ならばそれなりに複雑ですが、今回の例に使う部分だけならば、下記のようなJSONを想定すれば充分でした。
{ "feed": { "entry": [ { "media$group": { "media$player": [{"url": "http://hogehoge"}], "media$thumbnail": [{"url": "http://fugafuga"}] } }, ... ] } }
で、実際に写経してみたのが以下になります。
YouTubeResponse
とFeed
までは真面目に書いていたのですが、途中から面倒くさくなってEntry
インターフェースではエイヤッと超適当に書いてみたら通って逆にびっくり。構造的部分型の真骨頂を垣間見たような気がします。
そんなわけで、success
に定義した関数は、JavaScript版と変わりなく書かれているように見えますが、
data.feed.entry
はEntry[]
型であり、item
はEntry
型である)group.media$player
は配列である)group.media$player[0]
はurl
というパラメータを持つ)のようなことがコンパイル時に行われています。タイポしたり、存在しないメソッドやパラメータを勝手に生やすと速攻で叱られるので、私のようなゆとりプログラマーでも安心してコードを書くことができますね。
構造的部分型を活用してインターフェースを定義すると大変捗る!!!
むりやり1つのインターフェースにまとめてみた。可読性はクソ悪い*1けど、TypeScriptの型システムとしては、これでもOK。
interface YouTubeResponse { feed: { entry: Array<{ media$group: { media$player: Array<{url: string;}>; media$thumbnail: Array<{url: string;}>; }; }>; }; }
*1:慣れるとそこまででもない?
どうも、nkzn.netの更新を忘れてて転売屋に取られた人です。
今日はAndroid Bazaar and Conference 2014 Springですね。僕は業務都合的なアレで今回のABCに参加できないため、夜の裏会だけ行きます。
ただ、全くなにもしないのも寂しいので、景気付けに1本記事を書かせてもらいました。Effective Androidトラックの発表内容とネタ被りしたらごめんな!!
たぶん@mhidakaとか@sys1yagiさんがこの記事より良いこと喋ってくれると思うので、みなさん秋葉原UDXで著者たちと握手!!(宣伝)
さて、ここ何ヶ月かで、「実際Android Studioどうなん」という質問を受ける機会が増えてきたので、ここらで一度、僕がAndroid Studioを常用していて嬉しいと感じていることを書きなぐってみました。
昨年11月から、業務で約4ヶ月使ってみての感想です。新人研修にも1ヶ月ほど使ってみています。
前半はどちらかというとAndroid Studioを使うことで利用可能になるGradleがいいよね的な話、後半はAndroid StudioというIDE自体の話です。
IntelliJ IDEA + Android Pluginでも同じようなことできると思うので、「IntelliJ IDEAを使うべき〜」に読み替えてもいいです。Android StudioをやめてIntelliJ IDEAを使うべき10の理由を書きたい人は是非お願いします!!!
※ここ4ヶ月、ほとんどEclipse+ADTの環境を触っていないので、「それEclipseでもできるよ!!!!」なことがあったらごめんなさい&お知らせください
この記事を書き始めたモチベーションはこれが8割です。でも書き終えてみたら愚痴ばかりであんまり面白くなかったので、読み飛ばして次へ行ったほうがいい気がします。
読み飛ばす方のための1行まとめ:Android Studioが標準対応しているGradleは、Androidアプリ向けのビルドツールとしてAntやMavenより柔軟で使いやすいので良いよ!!
Eclipse(というよりは、旧来のAndroid App Projectの構造)では、コマンドライン向けの標準ビルドツールがAntでした。で、Eclipseからならサクッとできる方法が、コマンドラインからだとクソ面倒くさかった印象があります。
ビルドプロセスやライブラリ依存性をもっと柔軟に管理したかった人々が次に手を出したのがMavenでした。MavenにはMaven Central Repositoryというライブラリ置き場があり、設定ファイルにライブラリ名とバージョンを記述することで、ライブラリをダウンロードしてきてプロジェクト内で利用できるという、バージョン管理システムに優しい感じの仕組みもあり、有望かと思われました。少なくとも、コマンドラインからビルドやテストが実行できるという点で、CIのしやすさという条件は満たしていました。
が、そもそもMavenの設定ファイルであるpom.xmlはちょっと闇が深い系のアレであったことや、公式ツールではないことによる不安定さ(環境を安定させるために熟練の業を要した)、環境構築の度にmaven-android-sdk-deployerを実行するのがダルい、などの理由により、使いやすいかと言われるととても頷けるものではなかったと思います。
そこに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で管理できるようになって嬉しかった。(私怨 && 小並感)
さて、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界隈で既に広く浸透している文化ですので、この仕組みによって得られる恩恵は計り知れないと言ってもいいでしょう。
ライブラリ導入のコストが滅茶苦茶下がりました。やったね!!!
AARはAndroid ARchiveの略らしいです。JARのAndroid版だという認識ですけどよくしらない。どうやらライブラリプロジェクトをビルドしたときに生まれる、ファイルとしての実体みたいですね。(そういう意味では、APKファイルに類する存在なのかも)
さて、この形式のライブラリプロジェクトは、作者が頑張ってくれている場合、gradleのdependenciesで取ってこれます。
詳しくはゆーいち先生の記事を御覧ください。
実際にこの形式で配布されているライブラリとしては、@sys1yagiさんのIndirectInjectorなどがあります。
社内向けデバッグ用、モニターユーザー向けリリース用、Playストア向け無料版リリース用、Playストア向け有料版リリース用、などの切り替えを、ビルド時にコマンドによって切り替えられる機能があります。Build TypeはDebugとReleaseの2種類ですが、Product Flavorは任意の数だけ用意できるので、色んなパターンのアプリを作らないといけない場合には便利な機能ですね。
下記の記事が詳しいです。
Build Variants によって別バージョンの Android アプリを同じプロジェクトからビルドする (Gradle 使用) - ひだまりソケットは壊れない
プロジェクトフォルダの構造が少し複雑になってきたりすると、ソースが入ったフォルダをビルドパスに追加し忘れる凡ミスにより、上手くビルドできなかったりした経験はないでしょうか。
Android Studio + Gradleの環境では、settings.gradleやbuild.gradleに記述した内容がAndroid Studioのプロジェクト設定に直接反映されるため、そういったミスが起きづらくなっています。
また、チーム開発時にも、IDEの初期設定に割く時間を減らせそうです。
Intellij IDEAみたいに Mark Directory As > Test Source Root
みたいな感じでIDEからソースフォルダを指定したくなるときもありますけどねー。
JavaやXMLで、drawableリソースの中身がエディタの左端に出てきます。
Javaのほうは式として成り立っていなくても出てきたので、判断基準が結構適当みたいです。
JavaやXMLで、colorリソースの色がエディタの左端に出てきます。
color.xmlはなかなか壮観ですね。
いまどんな色が画面に出ているのかコードを書きながらイメージしやすいのは、嬉しい時もあるのではないでしょうか。(実はあんまり嬉しい場面が思いついていないけど綺麗なので挙げた)
XMLファイルやJavaファイルの中で、dimenやstringで定義した要素の値が、一時的に置き換えて表示されます。実際のファイル上で指定した値が書き換わるわけではなく、あくまでも見た目だけで、マウスオーバーすると元の値を見ることができたりします。
実際には↓のようになっているファイルも・・・
こんなふうに見えます。
Javaの中でgetString(resId: int)
で呼ばれている値も同様に置き換えられます。
↑これが↓こうなる
これで、「あれ、このstringリソース、中に書いた日本語なんだったっけ?」とか「このdimen、実際には何dpだっけ?」なんて悩まずに済みますね!
レイアウトのXMLを編集すると、ほぼリアルタイムでプレビューに反映されます。Android Studio登場以前から、IntelliJ IDEAでAndroid開発をする際の魅力的な機能として挙げられていました。
何を置くとどんなふうに見えるのか、トライアンドエラーが大変捗るので、デザイナーさんやAndroid初心者なプログラマーの人にレイアウトXMLを勉強してもらう際にも、効果バツグンです。
Android StudioはJetBrains製のIDEであるIntelliJ IDEAをベースにしているので、ちゃんと設定すればKotlin言語を利用することができます。Androidで使えるベターJava言語を探している方にオススメです。
Null-safety機能すっげえいいよ!!!!
現状、僕がEclipseを使う理由は(業務上やむを得ないアレが無い限り)どこにもありません。*2
でも僕が魅力を感じているのはどちらかというとGradleのほうなので、ADTがGradleに対応したらそれはそれで触ってみたい気がします。
今回は「IntelliJ IDEAが元々持ってた良さ」みたいなものは基本的に挙げなかったので、他にもAndroid StudioやIDEAを敢えて使う利点はありそうです。そのへんは他の方が記事書いてくれてると思うので、探してみてください。
それでは、良いAndroidアプリ開発ライフを。