そば屋のつまみ-1杯目

Android13

外部アプリから発信されたアクションを指定するインテントが、宣言された <intent-filter> 要素と一致する場合にのみ、エクスポートされたコンポーネントに配信されるようになりました。

まず、注意すべきは、インテントを受け取るアプリが Android 13 以上をターゲットにしている場合にのみ、この強制機能が有効になることです。内部的に同じアプリに配信されるインテントには影響しません。

この変更は、Developer Preview 1 以降の Android 13 ビルドですでに有効になっています。

この変更は、開発者向けオプションの互換性フレームワークのUIを使用するか、ターミナルウィンドウで以下のADBコマンドを入力することで切り替えることができます。

この変更は、開発者が 13 をターゲットにする前から影響を受ける可能性があるため、外部アプリとの対話にインテントを使用している場合は、この変更を調査してすぐに更新を調整することが重要です。詳細については、インテントとインテント フィルタについて説明したドキュメントをご覧ください。

https://developer.android.com/guide/components/intents-filters

異なるコンポーザブルを切り替えて使用する場合、2つのコンポーザブル間の移行がスムーズに行われず、ユーザーが画面上で即座に変更を確認する際の違和感にお悩みですか？それなら、もう心配いりません。AnimatedContent (現在実験中) は、異なるコンポーザブル間をよりスムーズでカスタムなトランジション効果で移行できるようにするコンポーザブルです。デフォルトでは、AnimatedContentで変化するコンポーザブルを包むと、コンテンツがフェードし、スケールイン/アウトします。これにより、アプリのルック＆フィールに大きな変化を与えることができます。

AnimatedContentを使うとスムーズになる

https://gist.github.com/riggaroo/a20bf326c323ce8888c2be0e0bcee612#file-jetsurvey-kt

Animating question changes
戻る時の制御の話し？後で確認する

↑合ってた

下から来たり横からきたり、Z-Indexとかサイズ変更もアニメーションいける

• AnimatedContentは、コンポーザブル間の遷移をより楽しくするシンプルなAPIです。完全なコードサンプルを見るには、この変更を導入した Jetsurvey プルリクエストと、同じく AnimatedContent を導入した Crane プルリクエストを見てください。
• このAPIは実験的なものであり、我々は積極的にフィードバックを求めていることを述べておく。
• もし何かご質問があれば、Twitterの@riggarooまでご連絡ください。また、フィードバックやバグがあれば、Compose Animation Issue Trackerで報告してください。

アニメーションは、初期状態であるスタートフレーム、アニメーションが進行しているアニメーションフレーム、最終状態であるフィニッシュフレームが描画されることで進行します。

アニメーションフレームを追跡できるレイアウトは存在しませんでした。これを克服するために登場したのが、LookaheadLayoutと呼ばれるレイアウトです。

LookaheadLayoutは、開始-終了フレーム間に描画されるフレームをプレビューし、そのフレームに描画されると予想される情報（計測、配置）に基づき、開始-終了間の新しいレイアウトを描画するのに役立つ。

先読み段階で計算された情報をModifier.onPlacedで受け取り、Modifier.intermediateLayoutで実際に中間レイアウトを配置することができるのです。

Modifier.intermediateLayoutを使用して、ルックアヘッドステップで計算された情報を元に中間レイアウトを配置することができます。

kotlinx.coroutines 1.6では、新しいテスト用APIのセットが導入され、以前のテスト用APIは非推奨になりました。古いAPIを使用するとすぐにdeprecationエラーが発生し、2022年末頃に完全に削除される予定です。

移行の完全ガイドもあるよ
https://developer.android.com/kotlin/coroutines/test

こっちに究極完全体の移行ガイドもあるよ
https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-test/MIGRATION.md

これらをすべてトップレベルのrunTest関数の呼び出しに置き換えています。

https://gist.github.com/zsmb13/e353ba133a5d775bd836bcffc264203c#file-runtest-kt-diff

もし、まだ式本体（関数から直接runTestの結果を返す）を使っていないなら、この機会にその規約も採用しましょうまた、KotlinJSをターゲットとしたマルチプラットフォーム・プロジェクトでコルーチンテストAPIを使用する場合は、この規約が必要です。

高度なケースでは、まだ独自のTestScopeを作成したいかもしれませんが、ほとんどのテストは、それ自身でrunTestを呼び出すだけでよいでしょう。

Android UI スレッドはユニットテストでは利用できないので、Main ディスパッチャに依存しているテストは、テストの間、それを TestDispatcher の実装に置き換える必要があります。他のディスパッチャと同じようにインジェクトするか、 Dispatchers.setMain を使って置き換えます。setMain を使うと、静的な方法でディスパッチャを置き換えることができます。つまり、ハードコードされた Main ディスパッチャに依存している構造体 (たとえば viewModelScope など) をテスト内で使用することができます。

そのためによく使われるのが、Mainを置き換えるコードを再利用可能なJUnitのテストルール（JUnit 5の場合はテスト拡張）に入れる方法です。ioschedプロジェクトで、そのようなルールの例を見ることができます。古い API を使ってこのようなルールを作っている場合は、次のように更新してください。

https://gist.github.com/zsmb13/954caffc3309b3743ed2bb6fb93df0df#file-maindispatcherrule-kt-diff

しいコルーチンを開始することがよくあります。これらのテストは、新しいコルーチンがイーガーリーに開始されることに依存する傾向があり、フローが値を発行するときはいつでも、コレクターはすでにそれを処理する準備ができている。

テスト内でFlowを収集するコルーチンが再びイーガーリーに開始するようにするには、新しいUnconfinedTestDispatcherを作成し、収集コルーチンを作成するビルダーに渡します。

https://gist.github.com/zsmb13/c9f95d19cacbb04944ce16773e533a2d#file-collecting-kt-diff

また、明示的にcollectを呼び出すことがFlowを収集する唯一の方法ではないことを覚えておくとよい。Flow.toList()などの他のメソッドも、内部でFlowを収集する。このようなメソッドを使用する場合は、UnconfinedTestDispatcherで起動する新しいコルーチンの中で呼び出すこともできます。

しかし、サンプルの中には、Main dispatcher のコルーチンに対して遅延スケジューリングを必要とするものがありました。典型的な例としては、ViewModel のロードの中間状態を確認する必要があるテストが挙げられます。この場合、データロードのコルーチンを熱心に開始すると、テストは最終的なロード状態のみを確認することになってしまいます。古い API では、このようなテストでは pauseDispatcher を使用して、新しいコルーチンが早く実行されるのを防いでいました。

https://gist.github.com/zsmb13/2c11c0b1200a17f7fad15e02831d4172#file-dispatcherpausing-kt

私たちは後者の解決策を選びました。MainのTestDispatcherを新しいStandardTestDispatcherに置き換え、Mainで新しいコルーチンを遅延的に開始させることでテストを開始しました。そして、テストコードの後半で、古いAPIを使ってresumeDispatcherを呼び出すときに、advanceUntilIdleを使って、これらのコルーチンを進めることができます。

https://gist.github.com/zsmb13/de5c5b0c6c8aa6af951602fcc8df8ebb#file-standardtestdispatcher-kt

runTestは、テストコルーチンの子やTestDispatcher上で動作するコルーチンを含むすべての既知のコルーチンを自動的に待機させます。つまり、緩いコルーチンの完了を待つようなクリーンアップのコードを削除すればいいのです!

このプロジェクトはすぐに、Kotlin マルチプラットフォーム モバイル アプリの個人的な遊び場になりました。以前の記事で、満足のいく（少なくともその時点では）共有アプリ アーキテクチャに至るすべてのステップを日誌にしました。

入力チェックを簡単にやれるライブラリ

このクラスはShowkaseとPaparazziの統合の主要な部分です。

https://gist.github.com/davidvavra/225088f82727f870066b0e7f300a674b#file-showkasepaparazzi-kt

スクリーンショットと既存のスクリーンショットを比較します。もし同じであれば、チェックは緑になります。
異なる場合は、PRブランチに基づき、異なるスクリーンショットを別のブランチにプッシュします。
PR にコメントを投稿し、二つのブランチを比較するためのリンクを貼ります。GitHubは、画像の違いを示すのにかなり良い仕事をしています。
もしその変更が意図的なものであれば、単にそのブランチを PR ブランチにマージすればよいでしょう。そうでない場合は、リグレッションバグを修正しなければなりません。

• コンポーズは、コンポーザブルの各パラメータの安定性を判断し、再コンポジション時にスキップ可能かどうかを判断します。
• もし、コンポジットがスキップされず、パフォーマンスの問題を引き起こしていることに気づいたら、まず、varパラメータのような明らかに不安定な原因を確認する必要があります。
• コンパイラのレポートを利用して、クラスについて推論される安定性を判断することができます。
• List、Set、Mapなどのコレクションクラスは、immutableであることが保証されていないため、常に不安定であると判断されます。Kotlinxのimmutableなコレクションを使うか、クラスに@Immutableや@Stableのアノテーションをつけるとよいでしょう。
• Composeコンパイラが実行されていないモジュールのクラスは、常に不安定と判断されます。Compose ランタイムへの依存を追加し、あなたのモジュールで安定とマークするか、必要であれば UI モデルクラスでクラスをラップしてください。
• すべてのコンポーザブルはスキップ可能であるべき？いいえ。

"再コンポジション "とは、入力が変化したときに、コンポーザブルな関数を再度呼び出すことである。これは、関数の入力が変更されたときに起こります。Composeは新しい入力に基づいて再コンポジションを行う際、変更された可能性のある関数またはラムダのみを呼び出し、それ以外はスキップします。パラメータが変更されていない関数やラムダをすべてスキップすることで、Composeは効率的に再コンポーズすることができます。"