AndroidのFirebase Installations version 16.2.0で追加されたlintチェックがAndroid Gradle plugin 3.6と互換性がなくてビルドできない

Firebase OSSのこちらのIssueで報告されているように、Android Gradle plugin 3.6（Android Studio 3.6）以上のプロジェクトでFirebase Installations version 16.2.0が依存性に入るとlintでビルドが失敗するようになります。

追加されたlintというのはこちら:

https://firebase.google.com/support/release-notes/android?hl=ja#installations_v16-2-0

Added a lint check to the compile process that prevents parallel usage of Firebase installations and incompatible versions of the Firebase Instance ID SDK that are older than firebase-iid:20.1.0. Firebase installations creates FIDs as Firebase client identifiers. Versions of the Firebase Instance ID SDK before v20.1.0 created different Firebase client identifiers: Instance IDs. This check prevents problems for Firebase targeting that might be caused by conflicting Firebase client identifiers.

数時間前にはこの問題を修正するPRがマージされたので、近々修正されたバージョンがリリースされるはずです。しばらく待ちましょう。

待てずにすぐFirebaseの各種バージョンを上げたい場合は、Issueにあるように該当のlintを無効にすることでひとまず回避することができます。

android {
    lintOptions {
        disable "IncompatibleIidVersion"
    }
}

Swift 5.2

iOS 13.4とXcode 11.4と共にSwift 5.2がリリースされましたね。

Swift.org - Swift 5.2 Released!

• SE-0249 Key Path Expressions as Functions
  • 関数・クロージャが要求される箇所でKeyPathリテラルを書くとKeyPath型ではなく関数・クロージャを返してくれるようになった
• SE-0253 Callable values of user-defined nominal types
  • SE-0216の@dynamicCallableに対してstatic callableとも呼ばれた機能。callAsFunctionというメソッドを定義することで、型や値を直接関数のように実行することができる。
• Improved Compiler Diagnostics
  • コンパイルエラーのメッセージの改善
• Code Completion Improvements
  • コード補完の改善
• Improved Build Algorithms
  • 主にインクリメンタルビルドの速度の改善
• Debugger Improvements
• Swift Package Manager
  • 依存パッケージがSwift 5.2のパッケージ定義を使っている場合、その依存パッケージのテストターゲットでしか使われていない孫依存パッケージは利用元のプロジェクトでは解決されなくなる（不要なtransitive dependencies：推移的依存性がなくなる）
• SwiftSyntax Updates
  • ノード階層がprotocolベースからstructベースになったことによる速度改善
• Language Server Protocol Updates
  • sourcekit-lspというLSPのランゲージサーバーがXcodeとCommand Line Toolsに同梱されるようになった
    • Visual Studio CodeなどでSwiftを書くのが捗るようになりそう
  • FixItsとLocal Refactoringのサポート追加

というラインナップになっています。今日から早速どんどん活用していきましょう！ ⚡️

OkHttp 4.xと3.xでのバイナリ非互換の事例

Kotlinで書き直されたOkHttp 4.xはJavaで書かれた3.xと基本的にソース互換性・バイナリ互換性が保たれているが、バイナリ非互換でクラッシュするケースに遭遇した。https://t.co/ZE0VV1Gkwm

— Sho Ikeda (@ikesyo) 2020年2月17日

具体的には、「OkHttp 3.xのJavaNetCookieJarを使っているライブラリ」を使うアプリでOkHttp 4.xを使おうとすると、Util.delimiterOffsetというstaticメソッドがString.delimiterOffsetという拡張関数に変わっており、前者のメソッドが存在しなくて死んでしまう。

— Sho Ikeda (@ikesyo) 2020年2月17日

• 4.xの String.delimiterOffset: https://github.com/square/okhttp/blob/4bb66bcf5e1b11bd13f088cc78188c2bdc075c6f/okhttp/src/main/java/okhttp3/internal/Util.kt#L207-L227
• 3.xの Util.delimiterOffset: https://github.com/square/okhttp/blob/parent-3.14.6/okhttp/src/main/java/okhttp3/internal/Util.java#L363-L383

GitHub Actionsのcheckoutアクションがv2でいろいろ変わって便利になっていた

GitHub Actionsをそこそこ使っている今日この頃です。さて、Actionsといえば普遍的に使う、リポジトリをチェックアウトする actions/checkout がありますが、このアクションがv2になり、色々と挙動が変更・改善されてい便利そうなのでいくつかご紹介。

• https://github.com/actions/checkout/releases/tag/v2.0.0
• https://github.com/actions/checkout#whats-new

---

• fetchのdepthがデフォルトで1になり、フェッチが速くなった
• チェックアウトの際に使用されたActions発行のトークンがgitのconfigに永続化され、リモートへのpushなどの操作が設定要らずでできるようになった
• ブランチのチェックアウト時にはローカルブランチを作るようになった（detached HEADにならない）
• チェックアウト先のパスを指定する path設定が絶対パスではなく $GITHUB_WORKSPACE 基準の相対パスになった

特に1〜3つ目は細かい困りごと・面倒ポイントを潰してくれていて好印象です。アクションの新バージョンには気づきにくいですが、どんどんアップデートして便利に使っていきたいですね。

追記

submoduleのチェックアウトが逆にv2では現在サポートされていないということなので、手でやる必要があり要注意です。この手段もSSHでは動かないとかもあり、submoduleを使っている方はしばらくv1の方がいいかもしれません。

https://github.com/actions/checkout#checkout-submodules

- uses: actions/checkout@v2
- name: Checkout submodules
  shell: bash
  run: |
    auth_header="$(git config --local --get http.https://github.com/.extraheader)"
    git submodule sync --recursive
    git -c "http.extraheader=$auth_header" -c protocol.version=2 submodule update --init --force --recursive --depth=1

• Checkout with submodules? · Issue #81 · actions/checkout
• submodule support removed in v2 · Issue #133 · actions/checkout

和暦と改元とうるう年が組み合わさったバグの思い出

あけましておめでとうございます。新年一発目の投稿は2019年の思い出です。

そういえば去年面白かったバグで、とある有効期限チェックで、2019年8月から半年後の月末が2020年2月末、つまり閏年なので2月29日になるのだけど、よくある和暦バグと組み合わさって令和2020年2月29日と解釈しようとして、令和2020年は閏年ではないのでパースに失敗する、ということがありました。

— Sho Ikeda (@ikesyo) 2020年1月1日

これ、改元があったことも絶妙に影響していて、仮に平成のままだったとしたら平成2020年（西暦4008年）は閏年なので問題なかったのである。

— Sho Ikeda (@ikesyo) 2020年1月1日

ということで本年もよろしくお願いします 🙏

2019年のSwiftモック事情

こんにちは、id:ikesyoです。これは はてなエンジニア Advent Calendar 2019 17日目のエントリーです。

---

昨日12月16日（月）に行われた 年末だよ Android/iOS Test Night - 2019 にて、『2019年のSwiftモック事情』という発表をしました。

Swiftでテストのためのモックを用意するとなると、リフレクションでめちゃくちゃするということができないので、素朴に手で書くか、コード生成をすることになります。今回の発表ではコード生成に主眼を置き、以下の4つの選択肢を紹介しました。

• SourceryのAutoMockable
• SwiftyMocky
• Cuckoo
• Mockolo

それぞれの機能や違いなど詳しい内容は、ぜひ発表のスライドを見てみてください。

Swiftでのモック事情については、今年4月の Mobile Act KYOTO #1 でも発表をしていました。

しかしこの後の8ヶ月で意外と状況が変わっており、その差分を今回の発表に入れ込んでいます。

• SwiftyMockyの設定ファイルとコマンドが変わった
  • Before: 設定ファイルはmocky.yml、コマンドはsourceryを直接利用
  • After: 設定ファイルはMockfile、コマンドはswiftymockyという専用のものが用意された（Sourceryの存在をラップ・隠蔽）
• Cuckooの機能追加
  • 5月にリリースされた1.0.0でジェネリクスに対応した
• Mockoloの発表とリリース
  • Uber製のモックジェネレーターで、コード生成が高速であるのが売り
  • 5月に開催されたUIKonf 2019での発表で公表され、OSSとしてリリース予定とされていた
  • 9月に1.0.0がリリースされた

Mockoloについては、UIKonfのセッション動画が公開されており、開発者自ら独自のジェネレーターを作るに至った背景や、高速化のためにやったことを丁寧に説明してくれています。こちらもぜひ見ましょう！

ということで、2019年末時点でのSwiftのモック事情をご紹介しました。どのツールを使うかは、

• 機能
• APIの好み
• チームメンバーの規模や習熟度
• プロジェクト（コードベース）の規模

など複数の要素に影響されると思います。ぜひ自分たちに適した選択肢を導入してみて、Swiftのテストライフを豊かなものにしていきましょう！ 🤖

---

あわせて読みたい

Android公式のDagger導入ドキュメント

Android Dev Summit 2019の文脈でAndroid公式のDaggerに関するドキュメントやCodelabが出てきて取っ付きやすくなった感じがします。いいですね。

• Dagger basics  |  Android Developers
• Using Dagger in Android apps  |  Android Developers
• Using Dagger in multi-module apps  |  Android Developers

Codelab

Dev Summitの動画