この記事は SHIROBAKO ADVENT CALENDAR 2020 10 日目の記事です。
とにかく劇場版 SHIROBAKO のエンディングが素敵なのだ。多分にネタバレを含むので、まだ劇場版を見ていない方はいますぐ U-NEXT にサインアップして見てほしい。何ならテレビ放送の分まで配信されているので、それをみてから劇場版を見てほしい。今なら初月無料（劇場版 SHIROBAKO は課金が必要だけど 1 週間見放題）だし（一応申し添えておくと、自分は U-NEXT の回し者でもなんでもない）。
続きを読むコロナ禍のなかで検証用の Android 端末をどう調達・管理するのかという話題を DroidKaigi.fm #4 でしてきました。その会話の中で、自分の場合は検証端末を全部自宅に持っていて、STF を使ってつないでいるという話をしたのでそのあたりを少し掘り下げてみようと思います。
Smartphone Test Farm という OSS ソフトウェアで、これをつかうことで Web ブラウザから STF サーバにつながっている Android 端末を操作できるようになります。adb による接続もできるので、端末を自分の PC に USB ケーブルでつなぐことなくアプリのデバッグが可能です。
本来は社内ネットワーク内などで STF サーバを立てておき、社内から誰でもブラウザで端末を使えるようにするようなユースケースで使うものですが、自分の場合は自分で会社の検証端末の管理もすることになったので、半ばファイルサーバにしかなっていなかった Mac mini に STF サーバを立て、これを中心に検証端末の管理をしつつ、いつでも使いたい端末をケーブルの抜き差しの手間なく使えるようにしました。
STF の README にある通りの手順で STF サーバを立てます。事前に Requirements にあるものを準備しておきますが、Node.js が 8.x であることに注意する (これより新しいバージョンでは動かないものがあるよう) 以外は、Installation の手順通りでよいはずです。
開発者オプションの USB デバッグが ON になっていれば、USB ケーブルで STF サーバにつなぐだけで STF が自動で端末を認識してブラウザから使えるようにしてくれます。
一方で、端末を管理するうえで問題になるのは、端末を繋ぎっぱなしにしておくとバッテリーの寿命が早まってしまうことです。とくに検証端末はいつでも使えるようにしておきたいので、STF サーバに繋ぎっぱなしにしておきたいところですが、そうするとずっと充電状態となってしまいます。USB ハブのなかには、電源タップのように ON/OFF スイッチのついたものがあり、これをつかって適度に ON/OFF を切り替えてできる限りバッテリーに負担のないようにしたいところですが、USB の口すべてにスイッチが付いているのは面倒です。そこで自宅ではできる限りたくさん USB の口を確保しつつ、ON/OFF スイッチは1つで全体をコントロールするものとしてこの USB ハブを使っています。
1台や2台程度ならどうということもないですが、5台以上になってくると、そのへんに積んでおくわけにはいかなくなってきます。今回は東急ハンズで仕入れた木材を適当に加工して簡単なスマホラックを作りました。
ひとつのラックで3台ほど格納できるように木材をあわせます。下からケーブルを通して差し込めるようにしてあります。
これを4個並べて運用しています。
以前に kotest を使ったテストに Robolectric をあわせるときの注意点を書きましたが、このときはまだ Experimental な状態だった Robolectric Extension が 4.3.0 から安定版となりました。
安定版となったことで次にあげるマイグレーション作業が必要になります。
RobolectricExtension および @RobolectricTest のパッケージが変わっています。
- import io.kotest.experimental.robolectric.RobolectricExtension + import io.kotest.extensions.robolectric.RobolectricExtension
- import io.kotest.experimental.robolectric.RobolectricExtension + import io.kotest.extensions.robolectric.RobolectricExtension
@RobolectricTest と通常のテストの共存以前は同一モジュールで RobolectricExtension を有効化すると、そのモジュール内のすべてのテストで @RobolectricTest が必要でした。安定版では必要なテストクラスのみに @RobolectricTest を付与し、@RobolectricTest の有無に関わらずすべてのテストが正常に実行できるようになりました。
以前と変わらず、Robolectric の初期化が二重に走ってしまいテストがコケます。
以前と変わらず、InstancePerLeaf 以外では Looper の初期化が二重に走ってしまいテストがコケます。
Build Variant ごとに Deep Link (App Links) の host を変えたいとき、Navigation Component の navigation graph の定義をどうするかを示します。
<deepLink> では String Resources が使えないnavigation graph も XML で記述したリソースだと考えると、次のような定義は一見正しそうですが、生成される AndroidManifest を見ると全く予期しない結果になります。
<navigation> <fragment> <deepLink app:uri="@string/deep_link_uri" /> </fragment> </navigation>
{build_variant}/res/values/strings.xml に deep_link_uri を定義すれば、Build Variant ごとに Deep Link の URI が切り替えられそうですよね。上記の navigation graph から生成される AndroidManifest の intent-filter は次のとおりです。
<intent-filter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="http" /> <data android:scheme="https" /> <data android:host="string" /> <data android:path="/deep_link_uri" /> </intent-filter>
String Resource への参照そのものが URI だと解釈され、string という host で /deep_link_uri という path の URI で Deep Link を設定してしまっています。
Issue Tracker にこの問題の報告がありますが、どうやら <deepLink> での String Resource への参照はサポートしていないようです。代わりに、Manifest Placeholder のような仕組みを導入する予定があるようです。
仕方がないので navigation graph の XML を Build Variant ごとに定義するしかありません。
navigation graph が十分にシンプルで小さいなら navigation graph 全体を Build Variant ごとに配置してもよいかもしれませんが、Deep Link の設定を切り分けるのであれば、Deep Link を持つ <fragment> だけを切り出した navigation graph を Build Variant ごとに用意し、それを main source set にある navigation graph から <include> するほうが良さそうです。
以前は Kotlintest と呼ばれたテストフレームワークが Kotest と名前を変えて開発が進められています。
このテストフレームワークは非常に多様なテストの記述方法をサポートしており、テストケースのスタイルからアサーションメソッド、パラメトライズドテストのサポートまでテストに必要な幅広い関心をカバーしています。 マルチプラットフォームでの動作をサポートしたテストフレームワークとなっていて、自分で拡張を導入するための構造も持っています。公式にも様々な拡張が提供されていて、Robolectric と一緒にテストを動作させるための拡張も用意されています。 ただし2020年10月現在 Robolectric の拡張は experimental であり、うまく動作しないパターンが多々あります。この記事では、次に示す各ライブラリのバージョンを組み合わせて kotest を Android アプリプロジェクトに導入する方法を紹介します。
build.gradle に下記の記述を加え、kotest および Robolectric を導入します。
android{
testOptions {
unitTests.all {
useJUnitPlatform()
}
}
}
dependencies {
// kotest
testImplementation 'io.kotest:kotest-runner-junit5:4.2.5'
testImplementation 'io.kotest:kotest-assertions-core:4.2.5'
testImplementation 'io.kotest:kotest-property:4.2.5'
testImplementation 'io.kotest:kotest-extensions-robolectric-jvm:4.0.1'
// robolectric
testImplementation 'org.robolectric:robolectric:4.4'
}
必要に応じて、テストの source directory 配下に resources ディレクトリを掘って、robolectric.properties ファイルを作ります。
sdk=28 application=your.app.pkg.YourApp
テストの source directory の好きなパッケージに ProjectConfig オブジェクトを作ります。
ProjectConfig オブジェクトは様々な extension を追加したり、テストの並列数を制御したりするためのオブジェクトです。 Robolectric を kotest で動作できるようにするには、extensions で RobolectricExtension を含むリストを返します。
また、Robolectric を使う場合の制約として、IsolationMode を InstancePerLeaf にしておく必要があります。IsolationMode はテストケースのインスタンスをどの単位でもつかを制御するパラメータで、InstancePerLeaf がもっとも細かい単位でインスタンスを作ります。現状の kotest robolectric extension による Robolectric の初期化処理では、モジュール内に複数のテストを記述したファイルがある場合、Looper の初期化処理が複数回呼ばれてしまい例外が投げられることがあります。IDE では個別にテストを実行するため気付きにくいですが、CLI で一気にテストを実行するとこのエラーに遭遇します。InstancePerLeaf ではテストケースのインスタンスごとに Robolectric の設定も異なる扱いをうけるためか、この初期化処理の重複による失敗を回避できます。
object ProjectConfig : AbstractProjectConfig() { override val isolationMode: IsolationMode = InstancePerLeaf override fun extensions(): List<Extension> = listOf(RobolectricExtension()) }
ちなみに、筆者が試した限り Robolectric を有効化したモジュールで ProjectConfig の parallelism を 2 以上にした場合も Robolectric の内部状態が不正になりテストが実行できなくなりました。
kotest-robolectric-extension で Robolectric を有効化したモジュールでは、自分が確認した限り次のテストスタイルが利用可能です。これら以外を使用すると Robolectric の初期化処理が複数回呼ばれてテストが失敗します（とくに BehaviorSpec や DescribeSpec、FeatureSpec）。
StringSpecWordSpecFunSpecRobolectric を利用するテストには @RobolectricTest アノテーションを付けます。
が、現状の kotest-robolectric-extension では同じモジュール内で Robolectric を利用しなくてもよいテストを記述している場合でも、@RobolectricTest アノテーションを付けておかないとテストが実行できない（テストケースがひとつも実行されず正常終了する）ため、Robolectric が不要なテストにも @RobolectricTest アノテーションを付与することになります。
@RobolectricTest class SomeTest : StringSpec() { init { "something" { // Given: Values val a = 0 val b = 1 // When: Subtract val subtracted = a - b // Then: subtracted value should be -1 subtracted.shouldBe(-1) } } }
先に紹介した ProjectConfig はモジュールごとに定義します。マルチモジュールな状況では kotest を使うすべてのモジュールで ProjectConfig オブジェクトを作る必要があります。少々面倒ではありますが、これにより、Robolectric を使うモジュールとそうでないモジュールを切り分けることができるため、Robolectric が必要なモジュールでは StringSpec を用い、そうでないモジュールでは BehaviorSpec を用いるなどのスタイルの使い分けがしやすくなります。
Peaks さんで「チームで育てる Android アプリ設計」と題した執筆プロジェクトに @kgmyshinさんと取り組むことになりました。この記事はこのプロジェクトが発足するまでの経緯や、執筆する本に込めた思いを伝えられればと言うことで書いています。
これまでの様々なアーキテクチャのあるべき論から少し離れてみて、どうやったらうまくチームでアーキテクチャを扱えるようになるかを、釘宮さんと自分のそれぞれで得た経験をベースに話していく書籍が「チームで育てる Android アプリ設計」です。 アーキテクチャは一度整えればそれで終わるわけではなく、プロダクトの成長やチームの成長とともに少しずつ形を変えていくものであるという考えのもとで、新規開発チームでの事例と、走り始めたあとの規模の大きなチームでの事例を紹介していく予定です。
この書籍のタイトルに込めた思いとして、チーム全員の目線を合わせてアーキテクチャを考えていきたいという思いがあります。
当初よりチームとアーキテクチャを両輪でうまくまわしていくための書籍を書きたいという思いからこのプロジェクトが始まりました。そこから、プロダクトが成長していくごとにアーキテクチャに求められるものも変化し、その時々に応じて少しずつアーキテクチャも微妙に形を変えていくはずだよね、という議論があり、さらにチームそのものもその変化に合わせて成長をしていくといいよね、というところから、このタイトルへと落ち着いていきました。
本当はチームがアーキテクチャを育てるだけでなく、アーキテクチャの変化がチームを育てることもあり、そこからさらにチームがアーキテクチャを進化させていくようなループが作れると理想で、そのことをうまくタイトルで表現できると良かったのですが、ひとまずはチーム一丸となってアーキテクチャを形づくり継続的に整えていくことを伝えるために「チームで育てる Android アプリ設計」という名前になりました。 そしてこのチームが一丸となってアーキテクチャの形を作り続けていくという姿が「都市計画」のようなイメージを彷彿とさせたことから、表紙のイメージはまるでシムシティで都市を発展させていったときの様子を写したようなイメージにしています。
この書籍では、特定のパターンのアーキテクチャがよいという話ではなく、チームやプロダクトの状況からうまくアーキテクチャを整え、ともに成長していくことにフォーカスした内容に仕上げていく予定です。 個人的にはテストしたいところがテストしやすければアーキテクチャはなんでもよいと思っているのですが、数多あるパターンの中からうまく時流や要求にあった形にで落とし込めそうなものを模索してきた経緯を文章にできれば、きっと他のいろいろなプロジェクト・チームでも役に立つだろうと思っています。 ぜひ、応援をよろしくおねがいします。
チームで育てる Android アプリ設計と題して新しいクラウドファンディングプロジェクトをやっていきます！ https://t.co/wmhPqtOt6g
— KeithYokoma (@KeithYokoma) 2020年9月7日
よろしくおねがいします！
Podcast を配信するにあたって、Apple Podcast や Google Podcast に登録しておくと、iPhone や Android のアプリから気軽に Podcast を聴けるようになります。各プラットフォーム向けに配信の設定をしておくと、アプリで Podcast の未読管理や前回からの視聴の再開、Chrome Cast での視聴などができて便利です。
この記事では Apple Podcast と Google Podcast で Podcast を配信をする手順をまとめておきます。前提として、Podcast の RSS フィードを何らかの方法で生成しておいてください（r7kamura/yattecastで静的に生成するなど）。RSS フィードには必須のタグと推奨のタグがそれぞれあり、Google のサポートページ を参考にしてください。必須のタグが欠けていたり、RSS フィードが誰でもアクセスできる場所にないとうまく登録できないことがあります。
Apple Podcast はちょっと前まで iTunes に統合されていたもので、今は Podcast アプリとして独立しています。配信するには iTunes Connect アカウントが必要です。
iTunes Connect: https://itunesconnect.apple.com/
ログイン後、Podcasts Connect を選択すると RSS フィードを登録する画面が出てくるので、配信したい Podcast の RSS フィードの URL を入力し、必要なデータを入れ登録を申請します。 1日ほど審査に時間がかかりますが、審査が通るとすぐに審査完了のお知らせが iTunes Connect アカウントのメールアドレスに届きます。お知らせには Apple Podcast で登録した Podcast 専用の URL も記述してあるので、それを自分の Podcast のウェブサイトにリンクとして貼って使えます。
Google Podcast は Google Play Music に統合されていたもので、今は Google Podcast への移行が推奨されています。ちょっと前までは Google Play Music 向けに Podcast の登録ができましたが、今は Google Podcast Manager を使う必要があります。
Google Podcast Manager: https://podcastsmanager.google.com/
Google Podcast では、Podcast の RSS フィード URL を登録後、更にいくつかのステップを踏まなければなりません。RSS フィードを登録すると、RSS フィードに含まれるポッドキャストの Author のメールアドレス宛に、RSS フィードが Google Podcast に登録されたことを通知するメールが届きます。
ここで Podcast の登録が意図したものかどうかの確認をします。メールには確認コードが含まれるため、このコードを入力すると Google Podcast に Podcast が登録されます。ただし登録が終わってもすぐには Google Podcast には反映されません。RSS フィードがインデックスに登録されるまでに2〜3日かかるので、気長に待ちましょう。
Spotify で Podcast を配信できます。
Spotify for Podcasters: https://podcasters.spotify.com/
アカウント登録後、RSS フィードを登録すると、RSS フィードのオーナー情報などに記載されているメールアドレスに確認コードが送られます。そのコードを入力したら、諸々配信者の情報を入力したり、ポッドキャストのカテゴリやサブカテゴリを選んだりしたら登録が完了します。 最後のステップで Spotify での配信 URL が表示されるので、時間を開けてアクセスすると聴けるようになっています。
Apple Podcast も Google Podcast も、Podcast がどれくらい聴かれているかの統計データが閲覧できます。それぞれ iTunes Connect や Google Podcast Manager で閲覧できるようになっているので、配信側としても簡単に統計データを取れて便利です。
