Android Testing CodelabはEspressoなどのテストツールの使い方を学べるサンプルです。

全篇Englishですが、大体雰囲気でわかるレベルだと思います。

このレッスンをやれば、アプリ開発におけるテストツールの使い方、

• JUnitを使ったユニットテスト（Andoridの端末を必要としないテスト）
• Espressoを使ったUIテスト（実機orエミュレータを必要とするテスト）

が学べます。

ちょっとお得だなと思ったのが、アプリがMVPパターンで作られていることです。テストツールの使い方の勉強のついでに、MVPパターンも学べるなんて一石二鳥だな、なんて思ったのでちょっとやってみました。

思っていたよりもざっくりとした解説なので、雰囲気をつかめるものくらいに考えるといいと思います。

それでもテストのやり方よく分かっていない私からすると、学びの多いレッスンでした。

このサンプルではパッケージをレイヤーごとではなく機能ごとに分けてありました。（機能ごとというよりはActivityごとに近い分け方だと思いましたが）

私はこれまでずっと、ModelはModelパッケージに、というレイヤーごとにパッケージを分けていましたが、「機能ごとに分けた方が見やすくていいだろ」と書かれていて目からうろこでした。

テストのためにモック用のクラスに差し替えるやり方の解説があります。

XMLのリソースファイル（strings.xmlなど）は異なるFlavorで同一のリソース名が存在した場合、Flavorのものが優先されmainで定義したリソースは上書きされます。

一方でJavaのクラスだと挙動が異なり、同一名のクラスが存在するとエラーになります。そのため、全てのFlavor共通で利用するクラスだけをmainに配置し、切り替えが必要なクラスはFlavorのディレクトリに配置するという工夫が必要になります。

Mockitoを使ったJUnit4のテストのやり方が勉強になりました。これは単純に私がMockitoの使い方がよく分かっていなかったからですが。

@Mockアノテーションに寄る初期化とか、ArgumentCaptorの使い方とか。

Espresso-IntentsによるIntentのモック方法、Espresso-Contribを使ったナビゲーションドロワーのUIテストなどが紹介されています。

Espressoテストの章になると、一部修正が必要な部分がありましたが、それもまた勉強になりました。（EditTextへ文字入力をエミュレートした後は、croseKeyboard()しないとエラーになるとか、上へボタンを参照する部分が英語以外の環境だとエラーになるとか）

Android StudioはビルドツールにGradleを使っているので、ライブラリはbuild.gradleのdependenciesに書くことで簡単に取り込むことが出来ます。

しかし、ライブラリによってはjarファイルで配布されているものもあります。（この例ではNiftyのMobile backend）

jarで配布されるライブラリを組み込む手順は簡単です。app/libsディレクトリにjarファイルを置くだけで完了です。

これはapp/build.gradleにて、libsディレクトリにあるjarファイルをビルド時にコンパイルするよう指定されているからです（compile fileTreeの部分）。

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:23.+'
    compile 'com.android.support:design:23.+'
}

libsディレクトリなんかない、という場合、プロジェクトビューがAndroidになっている可能性が考えられます（デフォルトではAndroidになっています）。この場合、Projectに表示を切り替えることでディレクトリ階層が表示されるようになるはずです。

それでも見つからなければappディレクトリの下にlibsディレクトリを作成し、app/build.gradleにcompile fileTree(dir: 'libs', include: ['*.jar'])を追加すれば組み込めると思います。

Udacityをご存知でしょうか。動画を見ながらAndroid開発（だけじゃありませんが）の勉強ができるサイトです。

入門的な内容から高度な内容（アプリのパフォーマンスを向上させるとか）まで幅広く学ぶことができます。しかも無料で。

私は今この講座を勉強中です。動画に日本語字幕がついているありがたいコースです。Udacity – Developing Android Apps

私がUdacityの動画で勉強している理由はいくつかあります。

• 無料で見れる（有料の講座もあるので注意）
• Googleが提供しているので品質が保証されている
• ちゃんとまとまった1つのコンテンツとして勉強したい
• ついでに英語の勉強にもなりそう

すでにAndroid Development for BeginnerやMaterial Desgin for Android Developersなどを受講しましたが、「そういうふうにやるんだ」という新たな発見もあって面白いです。（そんなん知っとるわ、ということもまた多いですけど）

動画で「こんなふうにやるんだよ」と教えるだけでなく、GitHubにあるサンプルコードを元に自分でAndroid Studio使いながら実践する内容もあるので、無料といえどかなり本格的です。

Udacityのコンテンツは全て英語です。ですが扱っている内容はプログラミングなので、雰囲気でなんとか進めていくことはできると思います。言ってることはよく分からなくても、コードを見ればなんとなく理解できると思います。

英語の勉強になりそうというのも意外とバカにできない重要な要素だと思います。少なくとも私は、Udacityで勉強するようになってからというものの、英語に対する苦手意識が薄らいできたように思います。おかげでAndroid Developersの情報を原文で読むのが自分の中で普通になってきたりしてます。

ただし抵抗感が薄らいだだけであって、英語ができるようになっているわけではありませんけどね。しかしそれだけのことでも、こと英語に関しては充分な進歩だと思います。英語も勉強したいなぁなんていう人には、Udacityを利用するのがついでにAndroidの勉強もできるおすすめな方法じゃないかなと思います。

Android Studioは常に最新を追いかけるんだ、なんてやっていた私ですが、最近ではそれもやや保守的になりつつあります。その理由の一つに、アップデートでプラグインを入れなおさないといけないというのがあります。

例えば1.4から1.5にバージョンを上げると、今まで使っていたAndroid Studioのプラグインは入れなおしになります。設定項目は引き継いでくれるのに、なぜプラグインは引き継いでくれないのか不思議です。マイナーバージョンアップによってプラグインが誤動作する可能性を考慮して、プラグインだけは引き継がないようにしてるのでしょうか？

GoogleのMaterial Design Iconをプロジェクトに取り込むのに便利なプラグインです。

ちなみに余談ですが、Android Studio 1.4からVector Assetなる機能が追加されています。Vector Assetを使うとMaterial Design Iconを取り込むことができるのですが、これを使うためには条件があります。minSDKを21以上にするか、それができない場合はgradleのandroid pluginのバージョンを1.4以上にする必要があります。SDK21未満だとvectorを扱うことができないので、これをpngファイルとして書き出してやる必要があるのですが、それをするためにはandroid plugin 1.4以上が必要なのです。ちなみにgradleのandroid plugin1.4以上（これを書いてる時点では最新が1.5）はbeta版であり、気軽には導入できません。

結局Material Designのアイコンを取り込もうと思うと、こちらのプラグインを利用するのが楽なのです。

とりあえず入れてる系プラグイン。そもそも私自身がDashを使いこなせていないのが問題。

Crashlyticsを導入するのに使っているというか、それ以外の使い方をよく知りません。発生したcrashなどを確認するのに便利なんでしょう、たぶん。

私の場合、アプリを作ったらそのまま放置してしまっているので、いかんなぁ、改善せんとなぁと考えているところです。たぶん、今後お世話になる機会が増えていくプラグインだと思います。

Android StudioからGenymotion使ったエミュレータを起動するのに使うプラグインです。

しかし最近は実機でデバッグすることが多いので出番があまりありません。動作の軽快なエミュレータといえど、貧弱な私の開発環境では実機で確認した方が早いんですよね。久しぶりに起動したらGenymotionがちゃんと動かないという状態になっていて、余計に出番が遠のいてしまいました。

Android StudioでVimキーバインドを有効にするプラグインで、私の中でなくてはならないプラグインの1つです。

Java8から使えるようになったラムダ式はAndroidではそのままでは使えません。Android Studioが「ラムダ式で書いたらこうなる」と見た目だけ表示してくれたりしますが、実際にラムダ式でコードが記述されているわけではありません。

例えば、このようなボタンにクリックリスナーを設定するコードがあったとして、

mButton.setOnClickListener(new View.OnClickListener(){
    @Override
    public void onClick(View v){
        Log.d(TAG, "Click!!");
    }
});

Android Studioがラムダ式スタイルで見た目をすっきりさせてくれるわけです。

mButton.setOnClickListener((v) -> { Log.d(TAG, "Click!!"); });

これはエディタ上で折りたたまれて表示されているだけで、実際に記述されているコードは上のものです（マウスカーソルを上に持って行くと表示されます）。

で、これを本当にラムダ式で記述できるようにするライブラリとしてretrolambdaというものがあります。あるんですが、その前に、そもそも私はラムダ式自体がよく分かっていません。そこでまずは、ラムダ式とはなんぞやというところから調べることにしました。

ざっくりした書き方で、私の中のイメージを書き連ねたのでわかりにくいところがあると思います。間違ってるところもあると思いますが、その際はご指摘いただけるとうれしいです。（長い前置き終わり）

ラムダ式はアロー演算子を利用して(引数) -> {処理}という書き方ができるものです。この書き方ができるのは一定の条件下においてですが、引数にOnClickListenerのような抽象メソッドが1つだけのinterfaceを取る場合と考えておけばいいと思います。

OnClickListenerは以下のように、onClickという抽象メソッドが1つだけ定義されたインターフェースです。

    public interface OnClickListener {
        /**
         * Called when a view has been clicked.
         *
         * @param v The view that was clicked.
         */
        void onClick(View v);
    }

これをsetOnClickListener()する際に、無名クラスとして定義して使っているわけですが、その無名クラスの定義をすっ飛ばして、直接抽象メソッドへの引数と処理だけを書くことができるのです。

なぜ省略して書けるかというと、まずsetOnClickListener()というメソッドは、引数にOnClickListenerというインターフェースをとります。そしてJavaのinterfaceという仕組みによって、onClick()というメソッドが必ず実装されていることが保障されます。すなわち、この中では少なくともonClick()というメソッドが呼ばれることがわかっているわけです。だから省略できるのです。

ラムダ式の左辺については、引数が1つであれば()を省略できたり、型を省略することができます。型を省略できる理由は、インターフェースの定義で型が決められているため、省略されても分かるからです。

右辺の{}はメソッドの中身が1文ですむ場合に省略可能です。また、return文だけですむ場合も同様で、さらにreturn句も省略できます。なぜならソッドの戻り値がインターフェースの定義で決められており、右辺の処理が戻り値を表していると自明だからです。

あくまでこれらは「省略できる」であって、別に省略せずに書いても問題ありません。（もっともわざわざラムダ式を使う目的を考えれば、省略できるところは省略すべきでしょうが）

省略して書けることは分かったけど、やっぱりラムダ式よく分からない。そんな人は、「そもそもなぜメソッド1つだけが定義されたinterfaceを用意して使っているのか」が分かっていないことが原因かもしれません（私はそうでした）。

ラムダ式が適用できるパターンが全てそうかは知りませんが、少なくともOnClickListenerについてはObserverパターンによる実装です。なぜメソッド1つだけのinterfaceを定義して使うかというと、「クリックされた」というイベントを監視するのに便利だからです。

AppBar（Toolbar、ActionBar）の部分が大きめの画像になっていて、コンテンツをスクロールするとそれに合わせて画像が縮んでいき、最終的にToolbarだけが残る（もしくは全部隠れる）みたいなデザインがありますよね。あれを実装しようと思って試行錯誤してみました。

試行錯誤になってしまった原因は、スクロール可能なコンテンツ部分を横着してListViewで作ってしまったからでした。見かけるサンプルはだいたいRecyclerViewを使っていたのですが、使ったことがないため使い慣れているListViewでやろうとしたのが間違いでした。

ListViewで実装すると、ListViewをスクロールしてもAppBarは連動して動いてくれません。AppBarの部分をスクロールすると伸縮してはくれますが、巷にあふれるパララックスAppBarはこんな残念な動きはしていません。

コードで何か手を加えないといけないのだろうかと調べるうちに、なぜListViewではAppBarが連動して動かないのか原因が分かりました。今回はそのお話です。

Patterns– Scrolling techniques

基本的にパララックスなAppBarを実装するには、レイアウトXMLの記述のみで実装できます。

サンプルコード – GitHub

このMaterial Design（Android desgin support library）による階層構造を初めて見ると、なんだかややこしく感じてしまいますが、1つずつ紐解いていけばそう難しい構造ではありません。

正確にはandroid.support.design.widget.〜とFQCN（パッケージ名を含めたクラス指定）になりますが、ここでは長くなるので省略しています。

CoordinatorLayout
├AppBarLayout
│└CollapsingToolbarLayout
│　├ImageView
│　└Toolbar
├ListView（などスクロール可能なコンテンツ）
└FABなどお好みで

基本的にXML上でちゃんと必要な指定さえ行えば動きます。コードは不要です。

今回の例ではListViewのスクロールにあわせてAppBarLayoutを伸縮させるために存在しています（FABをToolbarとListViewの中間に配置する役割も担っていますが）。このCoordinatorLayout自体は内包したView同士を連携させたりする単なる入れ物です。全然「単なる」ではないですけど。

AppBar部分のLayoutを管理するコンテナで、AppBarの部分に表示するViewをこの中に入れてやります。Blank Activityを作成すると、この中にはToolbarだけが入っていると思います。

ここではAppBarの高さを指定してやります。android:layout_height="192dp"。

折りたためるToolbarのための入れ物です。スクロールによるAppBarの動き方を指定することができます。ここではapp:layout_scrollFlags="scroll|exitUntilCollapsed"と指定しています。

AppBarが全開のときに表示されるイメージ画像です。コンテンツのスクロールに合わせて縮み、最終的にToolbarだけが残ります。ここではapp:layout_collapseMode="parallax"を指定しています。

Toolbarです。ここではapp:layout_collapseMode="pin"を指定しています。この指定でToolbar自体は隠れずに残ります。

app/build.gradleのdependenciesにさり気なく書いてあるサポートライブラリ。

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.2.1'
}

appcompat-v7:22.2.1のこの22.2.1の部分。自分で指定しようと思うと、バージョンいくつが存在しているのかが分からず、どうやって確認すればいいのかも分かりません。とりあえず最新のものが当たればいいやと、+を使ってごまかしたりしてきましたが、最新のものが当たるとそれはそれでうまくいかないことがあったりします（23が出てるんだけど、とりあえずはtargetSDKを22で作ってる今とか）。

要するに、1つ前のバージョンを指定したいのだけど、その1つ前のバージョンというのはいったいいくつなんだというのが困ります。結論から言うと22.2.1なんですけど、じゃあそれをどうやって調べたらいいのかという話です。

Support Library – Android Developersで確認できます。

また、パソコンにインストールしているAndroid SDKのディレクトリを潜って行くことでも調べることはできます。

（Android SDKのインストールディレクトリ）/extras/android/m2repository/com/android/support/appcompat-v7

このディレクトリに、バージョンごとのフォルダがあるのでそこでも確認可能です。

そもそも指定できるバージョンの候補を出してくれると楽なんですけどね。

ゲーム開発エンジン使ってアプリを作ってみたいなとは以前から考えていましたが、今回cocos2d-xの勉強をしてみました。

他にもUnityがあって、しかもそちらの方が情報量も書籍の数も多いです。にも関わらず、なぜcocos2d-xを選んだかというと、私には3次元がややこしかったからです。UnityはLive2Dと連携させるのにちょっと触りましたが、私には合いそうもないというのが第一印象でした。cocos2d-xなら2次元だから比較的入りやすいんじゃないかなと思ったのです。

実際にやってみたら、cocosは情報が少ないという意味でハードルが高くて困っていますけどね。もっとも、Unityもハウツー本使って勉強してみると意外と簡単にできるかもしれません。いずれやってみようと思います。

今回勉強するにあたって利用した本はこちらです。

cocos2d-xではじめるスマートフォンゲーム開発 [cocos2d-x Ver.3対応] for iOS/Android

posted with ヨメレバ

三木 康暉 技術評論社 2014-12-27

Amazon

Kindle

楽天ブックス

紀伊國屋書店

Android Studioでcocosのプロジェクトを開くにはどうしたらいいかという問題ですが、cocos2d-xのバージョン3.7からAndroid Studio用のプロジェクトが作成されるようになっています。ですので、3.7を使えば解決されます。さよならEclipse。

といっても、あくまでプロジェクトが開けるというだけで、Android Studioだけを使ってC++のコーディングなども含めて開発していけるわけではありません（多分）。素直にMacならXcode使ってiOS用に作っていく、WindowsならVisual Studio使ってWindows Phone向けで作っていくのがいいと思います。（両者であればプロジェクトを開く→実行する→ちゃんと動くので）

Android Studio使って進めていきたかったのですが、今回はcocos2d-xの勉強を優先することにしました。

基本的には本に書いてある内容は、バージョン3.6でもそのまま動きます。

ただ1点だけ、5章のP204ページにあるコードは修正しないと動きませんでした。

auto properties = _tiledMap->getPropertiesForGID(gid).asValueMap();

このasValueMap()のところの型チェックでプログラムが止まってしまいます。これはcocos2d-xのバージョンによる問題ではなく、Tiled Map Editorのバージョンが違うせいで動かなかったのかもしれません（本のTiled Map Editorのバージョンは0.9.1、私が使ったのは0.12.3）。

auto property = _tiledMap->getPropertiesForGID(gid);
if (property.isNull() || property.getType() != Value::Type::MAP) {
    return nullptr;
}
auto properties = property.asValueMap();

一部、本の通りにやっても画面にうまく表示されない箇所があるにはあるのですが、これはcocos2d-xのバージョンによる問題なのかは分かりません。

これは本のせいではありませんが、第6章のCocos Studioを使うあたりの話はそのまま利用できませんでした。というのも、本で使っているCocos Studio1.6が手に入らなかったからです。

開発者オプションチェッカーという名前ですが、現在のところ「アクティビティを保持しない」をONにしてるかどうかをチェックするだけのアプリです。

名前の通りAndroidアプリ開発者以外の人には無用の長物です。もしかしたら、私以外に欲しいと思っている人はいないかもしれません。

アピールポイントは、設定値の監視を行う割に、特別なパーミッションを要求しないという潔さがあるところです。

「アクティビティを保持しない」は、画面回転でアプリが突然の死を迎えないかチェックするのに重宝します。

一方で、これを有効にした状態だとActivityの通常のライフサイクルが確認できなくなります。普通ならホーム画面を出すと、ActivityはonStopで止まりますが、有効にしていると必ずonDestroyまでいって破棄されてしまいます。この状態では、例えばLoaderのレジューム処理が確認できなくなります。（というかこれが開発のきっかけでした）

「アクティビティを保持しない」を有効にしているかどうかは、渡しの場合だと通知領域を2回スワイプ→設定を表示→開発者オプションを表示→アクティビティを保持しないの状態を確認という操作を経ないと確認できませんでした。これがものすごく面倒くさい。

だったら通知などで「アクティビティを保持しない」の状態が分かれば便利なんじゃないかなと思って作りました。

本当は、アプリから「アクティビティを保持しない」の設定を切り替えられたら良かったのですが、設定値をアプリから切り替えることは不可能でした。設定値を書き換えるには特殊なパーミッションが必要であり、そのパーミッションを有効にできるのはシステムアプリのみという制限があったからです。

そのためこのアプリでは、「アクティビティを保持しない」の設定値を読み取ることしかできません。

このアプリでService,AlarmManager,Widgetを初めて利用しました。ちょっとした思いつきの割に、いろいろ勉強になったなぁと思います。

もっとも、ウィジェットの更新時に一旦ボイスレコーダーのアイコンが表示されて、パッと更新されないのがよく分からないところです。

アクティビティを保持しないが有効になってるかどうかを知ることができる、ただそれだけです。

仕組みとしては、Serviceを常駐させて設定値の変更を監視させています。設定が変更されれば通知を表示させたりウィジェットを更新させたりしているだけです。

アプリを立ち上げれば現在の設定値を常に確認できるのですが、それではアプリを立ち上げなければ有効かどうかを確認することが出来ません。それはそれで手間です。

それを実現するには、私の頭ではServiceを常駐させる以外に手段が思いつきませんでした。

Serviceの常駐は、端末のリソースを専有し続けるためバッテリーへの影響がある、何をしているか分からないなどから、あまり気持ちのいいものではないと思います。そこで、常駐しないようにするオプションも設けました。

「アクティビティを保持しない」を有効にしているかどうかを知りたい頻度というのは人によって違うと思います。1日おきくらいで構わないという人もいれば、常に最新の状態で知っておきたいという人もいるかもしれません。

Serviceを常駐させていれば、「アクティビティを保持しない」の設定値を切り替えた瞬間に、その設定値が通知されるようになっています。これを無効にした場合、設定値を切り替えてもすぐには通知されなくなりますし、ウィジェットや通知で表示されている設定値と、今現在の「アクティビティを保持しない」の設定値が異なる場合があります。

Serviceを無効化すると、設定値の変更が検出できません。そのため一定間隔で設定値を確認するしか方法が思いつきませんでした。ウィジェットであれば、「アクティビティを保持しない」の設定値を切り替えてウィジェットの更新時間が来るまでの間は、古い状態が表示されてしまうことになります。

この辺り、何かしらうまい手段があればいいのになぁと思うのですが、何かいい方法があるのでしょうか。（設定値の変更がBroadcastされてればよかったのにとは思いました）

もっとも、Broadcastがシステムによって行われていたとしても、そのBroadcastを受け取るにはServiceなりを立ち上げてBroadcastReceiverを動かしていないと受け取れないのですけどね。

現在バージョン0.1です。開発者オプションチェッカーという名前の割に、「アクティビティを保持しない」しかチェックしないからというのがその理由です。

他の開発者オプションは、そもそも利用していないか、有効にしていたら画面の表示で有効であることが丸わかりなものが多いので、とりあえずはこれだけでいいかとリリースしました。

「こういう設定値もチェックしたい」という要望があればコメント貰えると嬉しいなと思います。

そもそも需要があるのかどうかすら謎ですが・・・。

Android Studioのコード補完機能を過信しすぎてはよくないというお話です。

例えば、AndroidManifest.xmlにpermissionを追加するときのことです。<uses-permission android:name="android.permission.INTERNET"/>を追加しようとしたさいに、Android Studioのコード補完に任せると<uses-permission android:name="ANDROID.PERMISSION.INTERNET"/>となることはないでしょうか。しかもAndroid Studioで補完された文字列だから、大文字のままでも問題ないのかなと放置していないでしょうか。

実はこれが全部大文字になっているとうまく動きません。android.permissionの部分は小文字でなければなりません。

これはコード補完で候補を絞り込む際に、INTERNETの部分を大文字でタイピングしたときに起こります。最初の1文字目を大文字でタイピングすることで、選んだ選択候補の文字列がすべて大文字で入力されてしまうようです。

この対策は実はとても簡単なことで、internetと小文字でタイピングして絞り込むことです。

INTERNETの部分が大文字だから大文字で入力しなければならないと思い込んでいないでしょうか。私は思い込んでました。なぜなら、コード補完で絞り込む対象が定数である場合、少なくとも最初の1文字目は大文字でタイピングしないと絞り込めなかったからです。だからpermissionでも同じなのだろうと思ってました。

しかし、このpermissionの場合は小文字でタイピングしても絞り込めます。そして、小文字で絞り込んだ場合だと正しくandroid.permission.INTERNETと入力されます。

これはAndroid Studioの設定によるものです。デフォルト設定がどうなのかはよく知らないので、人によって違うかもしれません。

Android Studioのコード補完機能の設定で、大文字・小文字を区別する設定があります（Preference > Editor > General > Code Completion）。私の場合はここが「First letter」になっています。そのため補完候補の最初の1文字目だけは大文字・小文字が区別されてしまうのです。

そのため定数（例えばREQUEST_CODEといったもの）の場合、少なくとも最初のRだけは大文字で入力しなければ候補に残りません。一方でandroid.permission.INTERNETの場合は最初の1文字目が小文字であるため、INTERNETの部分で絞込をする場合に入力する文字は小文字でも問題ないのです。

今のところ私が遭遇して実際に影響を受けたのはAndroidManifest.xml上でだけですが、他の部分でも影響があるのかもしれません。