DroidKaigi 2023 memo
code:md
# droidkaigi 2023
## day 1
### deep dive into size configuration changes by Chiko Shimizu
- configuration changes で悲しいことになった事例がいろいろあったので共有します
- アプリ作成の前提が変わっている
- window size に関する config changes
- 画面回転
- multi window mode
- large screen, not "tablet"
- chromebook
- window として表示される
- window size が任意の形・サイズに調整される
- touch だけではなくキーボード・マウス・スタイラスでの操作
- window size の話
- foldable
- phone と tablet はカテゴリが分かれていない、どっちも phone
- カテゴリは phone と tv っすね
- configuration changes
- システム設定の変更とか
- 言語とかね
- 画面回転
- サイズの configuration
- smallestScreenWidthDp?
- screenWidthDp と一致しない?
- inset ぶん引かれてる
- system UI (navi bar, noti bar), task bar とか
- inset 動的に変化する
- nav bar の種類で変わったり
- tablet の task bar が出たり消えたりで変化する
- 楽しいぞ!
- galaxy fold~~~~~~~~~~
- 正方形に近い aspect ratio
- portrait なのに height の方が低くなる!!!!!
- inset に食われてるため
- orientation
- multi window の時
- 使用できる領域によって orientation が決まる
physical device の向きは land なのに領域が狭い window は port になる、みたいな
- どうする?
- Jetpack Window Manager を使おう
- inset に関する様々な面倒を隠蔽して window size を取得できる
- スクリーンサイズを取得できるぞ
- configuration のことは忘れろ!!!!!!!!
- Compose の場合
- 同じ
- config changes の発生を知る
- 基本的に Activity の再起動が起こる
- API level 24 は「大幅なサイズ変更」という概念が導入される
- 大幅なサイズ変更でない場合、 config change は発生するが Activity の再起動はしない (?????)
- 大幅なサイズ変更
- ある閾値を超えたサイズに関する構成変更
- Activity の再起動だけでは config changes の検知には足りない
- 軽微なサイズ変更
- activity.onConfigurationChanged
- デフォルトでは 23 では N/A 30 以降では呼ばれない
- Activity の再構成を抑止した場合でも 31, 32 では呼ばれない (???????)
- 34 からはデフォルトでも呼ばれるよ、よかったね! (????????????)
- view.onConfigurationChanged
- デフォルトでも抑止していても全部呼ばれる
- Compose
- LocalConfiguration.current を監視して変更を検知する
- 検知実装
- view based
- Activity の中に空の view を add して onConfigurationChanged を override する
- compose
- LocalConfiguration.current
- WindowSizeClass というライブラリがこれをやってくれているのでそれを使いましょう
- まとめ
- 現代では Window は任意の形状・サイズに変更されるものとして考える
- acpect ratio が壊れやすい
- 写真の preview など画像の表示の時の aspect 調整がかなりセンシティブになる
- app の window size の計測
- androidx.window の WindowMetrisCalculator を使う
- config changes の検知
- View.onConfigurationChanged
- LocalConfiguration.current
## day 2
### share by Yu-ichi Araki
- share by ACTION_SEND intent
- API level 1 から send/receive どちらもかわらない
- Intent.createChooser
- topic
- text 以外も様々なデータを共有できる
- direct share
- sharesheet
- note
- sender / receiver の区別
- 様々なデータを送る
- sender
- "text/plain", EXTRA_TEXT
- ShareCompat.IntentBuilder
- receiver
- intent-filter -> action.SEND
- category.DEFAULT -> implicit intent を受け取れる
- category.BROWSABLE -> webshare intent を受け取れる (誰が使ってるの? www)
- ShareCompat.IntentReceiver
- 画像
- sender
- URI を指定する (setStream)
- content URI (content://...)
- ContentProvider で送って ContentResolver で取得
- androidx.core.content.FileProvider 使えば OK
- file path の xml を定義しておくとそこにある画像を読めるようにしてくれる
- recerver
- contentResolver で uri を読む
- permission
- send intent に flag を立てる FLAG_GRANT_READ_IMAGE_URI ?
- ShareCompat 使っていれば気にしなくてOK
- 画像編集
- extension が変わる可能性があるよ
- png のサポートを持っとくと良い
- wildcard (image/*) もできる -> 何でも受け取れる時
- 制限があるなら全部並べる
- text も一緒に渡せる
- 複数画像の送信 -> action.SEND_MULTIPLE
- 直接共有
- receiver
- 連絡先・アカウントに直接共有を投げられる
- shortcuts
- dynamic shortcuts の方
- xml/sharing_shortcuts.xml
- 受け取る intent に EXTRA_SHORTCUT_ID が追加される
- いつ、どうつくるか?
- メッセージを出す時、メッセージを受け取った時
- addCapabilityBinding -> SEND_MESSAGE, RECEIVE_MESSAGE
- ShortcutManagerCompat
- push / remove だけ考えておけばまあ OK
- たくさんやると制限かかったりするけどあまり気にしなくてよい
- sharesheet
- motivation
- カスタムの共有シートを使わないでほしい
- Chrome もやってるんでね...強くは言えない 移行中
- 大体やりたいことはできるはず!
- custom action
- api 34+
- intent で表現できる action なら何でも設定できる
- 初期 intent
- EXTRA_INITIAL_INTENTS
- 標準でない追加の引数を渡せる
- 共有先の除外
- main usecase: 自分自身を候補に出さない
- EXTRA_EXCLUDE_COMPONENTS
- 共有先を知る
- for analytics
- pending intent に broadcastreceiver を指定する
- 使ってフィードバックしてくれ!
### we've stopped using material 3 by Yuki Anzai
- good-bye material 3 design system
- why?
- instead of...
- おさらい
- design tokens
- デザインに関する値をハードコードせずに名前を与えて定義、アプリ全体に適用できるようにする
- token 自体は platform から独立した概念として定義できるもの
- ref token -> 値を参照する、 context によらず固定の値
- sys token -> ref token や sys token を参照、 context で参照が変わる
- comp token -> 要素の属性に対する token, sys/ref token を参照する
- sys token for m3
- color
- typo
- shape
- color scheme
- 24 + 5 color roles
- typography
- 5 roles * 3 scales
- shape
- 7 levels
- つらぽよ
- 色!!!!!
- tonal palette から色が pick される
- 入れたソースとなる色に対して role に割り当てられる色が変わってしまう
- マニュアルで割り当てられるけど全体の調整をするのがとてもつらい
- dynamic color との調和をさせるのは無理では...?
- dark mode -> isLight が m3 で消滅, カスタムでは良い感じに対応できない
- isSystemInDarkTheme() -> 完全な互換にならない
- ブランドカラーにもとづいた色使いをするなら m3 の design system をやめよう
- 独自の design system
- comp token を使わないようにした
- design token は platform independent なのに comp token は platform 依存なものがある
- 参照が深い
- この色は何? を辿るが長い
- 直接 sys token を参照する
- ref token と sys token を定義する
- sys token をまず定義しよう
- デザイナさんいる?
- いる、協力できる -> 一緒に token を洗い出して実装する
- いない -> 段階的に構築していきましょう
- つくる
- color
- bg
- contents, text color
- primary
- typo
- bodyLarge
- bodyMid
- optional
- dim
- spacing
- design-system module を作る
- m3 依存をもつ
- compose 導入状況によって app の依存を調整