こんにちは。TimeTreeのAndroidエンジニアの笠松です。
弊社はビジネスネーム制を採用しており、社内ではRingと呼ばれています。
TimeTreeは、2024年9月11日(水)から9月13(金)に開催される「DroidKaigi 2024」にサポータースポンサーとして協賛しました。
私は9/12, 9/13のDroidKaigi 2024に参加しました。
この記事では各発表の概要や感想を書いていきます。
オフライン・ファーストなアプリの実例：ガーナの農家アプリ（Arief Rahman, Takuya Kodama）
タイトルの通り、オフラインファーストアプリの実例紹介でした。
読み込みと書き込みに分けて実装方針をわかりやすく説明されていました。
アプリでの書き込み処理は以下の方法で行われています：
- サーバーに送信する前に、ドラフトとしてDBにデータを保存
-
CoroutineWorkerを用いて、保存処理をバックグラウンドで実行 - 保存完了後、ドラフトDBから正式版DBにデータを移行
読み込み時は、正式版DBとドラフトDBのレコードを連結し、重複を排除してDBの値を表示しています。
開発時に直面した課題の中で、特に遅延読み込み対象の画像の取り扱いと位置情報の取得方針が面白かったです。
画像処理では、ダウンロードタスクをキューに登録し、オンライン時にCoilを使用してローカルにダウンロードする方法を採用していました。Coilを用いたローカルへのダウンロードする方法を知らなかったので、試してみたいと思いました。
位置情報取得に関しては、通常はFusedLocationProviderを使用しますが、オフライン利用と屋外条件を考慮し、LocationManagerを用いてGPSから直接位置情報を取得する方針を採用していました。
KSPの導入・移行を前向きに検討しよう！(shxun6934)
このセッションでは、Kapt（Kotlin Annotation Processing Tool）とKSP（Kotlin Symbol Processing）の特徴、導入や移行の方法についての話でした。
KaptはKotlinでアノテーションを使用するためのツールです。このツールではKotlinコードを直接扱えないため、一度Javaのアノテーションに変換する処理を行います。
一方、KSPはアノテーション処理に限らず、コンパイラプラグインとしてコードの解析や生成を行います。KSPはKotlinを直接分析し、コードを生成するためより効率的です。
KaptがJavaに変換するのに対し、KSPがKotlinを直接解析するという違いが、KSPがKaptよりも高速である主な理由です。
現在、Kaptはメンテナンスモードに入っており、新規機能開発は行われていません。一方、KSPは今後も積極的に開発が進められ、K2 Compilerにも統合される予定です。
また、KaptとKSPのビルド速度の比較結果の話もありました。KaptとKSPを混在させると、Kaptのみの場合よりもビルド速度が遅くなるとのことです。モジュール単位で移行を行えば、パフォーマンスの低下を避けられるそうです。移行作業時にはこの知見を活かそうと思います。
仕組みから理解する！Composeプレビューを様々なバリエーションでスクリーンショットテストしよう(Sumio Toyama)
Preview関数の収集、スクリーンショットの取得、バリエーションに応じたテストの生成に分けて、Composeプレビュのスクリーンショットテストの説明でした。
Preview関数の収集ではShowkaseとComposablePreviewScannerを紹介いただきました。
スクリーンショットの取得はroborazziを使用した方法です。
バリエーションを設定方法としてはComposeのCompositionLocalProviderによる指定、Robolectricは@Configです。
ライブラリの比較やはまりどころなどとても手厚い発表でした。
Google提供のスクリーンショットテスト機能についても説明もありました。screenshotTest配下にComopseのPreviewを置くだけで画像回帰テストできるので、とてもシンプルで便利です。
単純なスクリーンショットテストで画像回帰テストを行う場合、Google提供のスクリーンショットテスト機能を使用するのが良さそうでした。まだalpha版なので、stableが待ち遠しいです。
アニメーション終了後など、より複雑な条件で画像回帰テストしたい場合、roborazzi等を使用する方が良さそうとのことでした。
Google Sign-inの移行から始めるCredential Manager活用(clockvoid)
Google Sign-inのための既存のAPIが2025年に削除予定のため、Credential Managerに移行しようという話でした。
Credential Managerを用いると、複数の認証方式を一つのUIで扱うことができます。
実体はAndroid 14以上ではNative APIが呼ばれ、Android 13以下ではJetpackのcredentials-play-services-authが裏で呼ばれるとのことでした。裏側が違うため、対応できる機能もAndroid14以上とAndroid13以下で分かれます。
実装方法もわかりやすく解説されていました。TimeTreeでも実装してみたい気持ちになりました。
分析に裏打ちされたアプリウィジェット開発 - Jetpack Glanceとともに(Miyabi Gouji, Yuri Ogura)
Jetpack Glanceを用いたウィジェット開発の実例紹介の話でした。
Android12以降の改善やJetpack Glance 1.1.0のリリースなどJetpack Glanceの機運が高まっている話、既存のウィジェットのデータ分析の話、Jetpack Glanceで実装する際のコツの話の3本立てでした。
ウィジェット導入でアプリ スタンバイ バケットが低優先になることを回避できる話とRemoteViewsからJetpack Glanceへの置き換え手順が特に勉強になりました。
実装のTipsを参考にしながら、RemoteViewsを置き換えていきたいと思いました。
使って知る CustomLayout vs DailyScheduler(Saiki Iijima)
Composeは「Composition -> Layout -> Draw」の3フェーズに分かれていて、Layoutフェーズを操作することでより柔軟なUIを実現できる話でした。
以下の４つの操作方法と実際にレイアウトフェーズを操作してデイリーのUIを実装する方法を説明いただきました。
-
Layout()- 要素のレイアウトを行う
- 複数の小要素をハドルする
- 配置するサイズを変更できない
- 親を参照
- 複数の要素と位置をカスタマイズする場合に応用できる
-
Modifier.layout()- content全体がlayoutとして入ってくる
- ただ一つの要素をレイアウトしたいときに使う
- 親のconstraintsを参照できる
- 単一の要素と位置をカスタマイズする場合に応用できる
-
SubcomposeLayout()-
Layout()でできることはできる - 加えて、レイアウトフェーズで動的に配置する内容を変える
-
-
BoxWithConstraints()- 親の制約を参照できるBox
今までRow, Column, Boxで作っていたので、とても勉強になりました。TimeTreeも複雑なレイアウトが多いので、活用できる場面が多そうです。
タッチイベントの仕組みを理解してジェスチャーを使いこなそう(usuiat)
このセッションはジェスチャーAPIの仕組みに焦点を当てていました。ジェスチャーAPIの種類と特徴、タッチ状態の保持方法、そして画面上の指の動きの追跡方法について詳しく説明しました。
発表者はZoomableというライブラリの開発者でもあり、ライブラリで発生した問題も取り入れ、入れ子になった場合の親子Compose間のイベント伝播や操作についても解説しました。
日常的な開発では主にModifier.〜ableAPIを使用しますが、このセッションを通じてタッチイベントの仕組みをより深く理解できました。各概念が分かりやすく説明されており、技術的な内容だけでなく、プレゼンテーションの観点からも学ぶところが多いセッションでした。
TimeTreeの採用情報🌟
お読みいただいて、ありがとうございました。
TimeTreeでは、ミッションに向かって一緒に挑戦してくれる仲間を探しています。
弊社のAndroidチームのメンバがインタビューを受けた記事が CodeZine にて掲載されています。Androidチームの様子も知ることができますので、ご覧ください。
TimeTreeで働くことに興味がある方はぜひ、以下の採用情報や会社情報をご覧ください！
TimeTreeのエンジニアによる記事です。メンバーのインタビューはこちらで発信中！ note.com/timetree_inc/m/m4735531db852
Discussion