Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SwiftUI/Jetpack Composeを採用してよかったこと悪かったこと
Search
nekowen
April 21, 2022
Programming
2
1.4k
SwiftUI/Jetpack Composeを採用してよかったこと悪かったこと
2022/04/21 (木) に開催されたKyash Tech Talk #3の登壇資料です。
nekowen
April 21, 2022
Tweet
Share
More Decks by nekowen
See All by nekowen
健康第一!MetricKitで始めるアプリの健康診断 / App Health Checkups Starting with MetricKit
nekowen
5
4.9k
5分で理解するAccessorySetupKit / Understanding AccessorySetupKit in 5 minutes
nekowen
0
230
MetricKitで予期せぬ終了を検知する話 / Detect unexpected termination with MetricKit
nekowen
1
740
iOS13向けに位置情報周りを対応しようとしたら苦労した話
nekowen
1
450
Other Decks in Programming
See All in Programming
fs2-io を試してたらバグを見つけて直した話
chencmd
0
230
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
480
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
390
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
130
快速入門可觀測性
blueswen
0
360
Jakarta EE meets AI
ivargrimstad
0
250
ドメインイベント増えすぎ問題
h0r15h0
2
310
Mermaid x AST x 生成AI = コードとドキュメントの完全同期への道
shibuyamizuho
0
160
モバイルアプリにおける自動テストの導入戦略
ostk0069
0
110
暇に任せてProxmoxコンソール 作ってみました
karugamo
2
720
【re:Growth 2024】 Aurora DSQL をちゃんと話します!
maroon1st
0
780
Recoilを剥がしている話
kirik
5
6.7k
Featured
See All Featured
Thoughts on Productivity
jonyablonski
67
4.4k
Become a Pro
speakerdeck
PRO
26
5k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
A Tale of Four Properties
chriscoyier
157
23k
Designing for humans not robots
tammielis
250
25k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Unsuck your backbone
ammeep
669
57k
Done Done
chrislema
181
16k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
Transcript
Kyash TechTalk #3 Mobileチーム - KMM化、宣言的UI、Widget対応 2022/04/21 SwiftUI/Jetpack Composeを採用して よかったこと悪かったこと
2 2 iOS
自己紹介 • Ryoya Kobitsu (@nekowen) • iOS Engineer / Kyash
Inc. • Twitter: @n3k0w3n Kyash: @nekowen
4 4 01. SwiftUI導入までの経緯
5 • Kyashには20種類以上の履歴画面が存在していた ◦ Visa決済、QUIC Pay決済、Payeasy、クレジットカード 入金 etc… • 技術的負債となっていたのでリファクタリングを実施
• 以下の理由でSwiftUIを採用 ◦ レイアウト要素が単純で作り直しが容易 ◦ 要素の出し分けが多いためif文でレイアウトできた方が 好都合 • 以降、新規画面は原則、既存画面は順次SwiftUIへ きっかけは履歴画面のリファクタリング
6 Kyash iOS アプリの履歴画面を SwiftUI でリファクタリングした話 https://blog.kyash.co/entry/2021/07/21/100307
7 7 02. よかったこと
8 SwiftUI UIKit
9 • Storyboardを含むレビューはコストが高かった ◦ diffが大量に発生する ◦ コンフリクトが発生する頻度もそこそこあった ◦ レビュワーがローカルでチェックアウトして確認 ▪
スクリーンショットが貼ってあればスキップすることも • SwiftUIを採用して上記の課題を軽減 ◦ 変更箇所が明確なためレビューしやすい ◦ コンフリクトの発生頻度も減少 コードレビューの敷居が下がった
10 Kyashリワードの表示パターン 読み込み中 通信成功 通信失敗
11 • 通信が走る画面は ほぼこの共通Viewが使われて いる • 中ではDataSourceのstateを みて出し分けているためとて もシンプル Viewの切り替え処理が簡単
12 • cornerRadius, shadowといったModifierが用意されて いる ◦ UIKitでは扱いづらかったViewカスタマイズがや りやすい • アニメーション実装も簡単
◦ Shimmerのようなアニメーションも可能 ◦ iOS14以降はmodifierが用意されている ▪ .redacted(reason: .placeholder) Viewのカスタマイズも簡単
13 • SwiftUIコードを変更するとサイドのプレ ビュー画面にリアルタイムで反映 • Preview部分はSwiftでかけるので、画面 にサンプルデータを渡してプレビューす ることも可能 ◦ 長い文字列を渡してレイアウトが崩
れないか簡易的に確認することもで きる 強力なXcode Previews
14 • previewDeviceとpreviewDisplayNameを 活用すると、複数のデバイスでまとめて プレビューが可能 ◦ 開発中にレイアウト崩れがないか サッと確認できる ◦ 最小サイズであるiPhone
SE第一世 代と最大サイズであるiPhone 12 Pro Max両方同時にみれるので効率 が良い • previewDisplayNameはプレビュー端末の 上にタイトルとして表示される 強力なXcode Previews
15 15 03. 辛かったこと
16 • UITableViewのrefreshControlに相当する機能がない • iOS15からrefreshable(action:)が追加された ◦ iOS13-14はどうする…? • GeometryReaderとUIActivityIndicatorViewをラップしたView を組み合わせて実現
Pull to refreshが簡単にできない😭
17 • iOS13ではUICollectionViewに代わるコンポー ネントがない • iOS14以降ではLazyVGrid/LazyHGridが用意 された • iOS13のサポートを切るまではVStackと HStackで表現することに
Gridの実装が手間😭
18 • iOS13と14でコンポーネントにキーボードが被ったときの挙動が異なる ◦ iOS13だとそのまま ◦ iOS14だと自動的に位置を調整してくれる • iOS13はNotificationCenterを使うように分岐している キーボードの挙動が変わる😭
19 19 03. まとめ
20 まとめ • SwiftUI導入によって、チーム全体の生産性が向上した • OSバージョンごとにAPIの対応未対応の差が激しい ◦ これから導入する場合は、iOS14以降から利用することをオススメします。
21 21 Android
22 22 01. Jetpack Compose 導入までの経緯
23 • 決済や入出金を行うと履歴データが作られる。 ◦ 履歴の種類は20種類以上... • Fragmentとxmlがそれぞれ用意されていた ◦ 履歴を追加/改修するのが大変! ◦
QAコストも爆上がり • リファクタリングと同時にJetpack Composeに置き換える作戦に。 きっかけは履歴画面のリファクタリング
24 24 01. よかったこと
25 • 普段書いてるKotlinで書けるのでxml脳に切り替えなくて良い • 簡単に意味のあるグループに分割して、かつ名前が付けられる (xmlだとファイル分けて includeするしかなかった) ◦ レビューがしやすくなった Kotlinで書ける
26 xml Jetpack Compose
27 • リストの実装が非常に楽になった ◦ KyashはGroupieを使っていたが、セルの種類だけBindableItemを 継承したクラスを作る必要があった • themeのカスタマイズが定義に飛ぶだけで一覧を見れるので扱いやすい • すぐ調べられるようになった
◦ 以前はandroid codesearchとか使っていた • Webでも同じコードでUIが作れる ◦ Webで試したら普通に使えそうだった 扱いやすい
28 • View内に状態をもたないため自分でstateを管理する必要はあるが、想 定外なバグなどは出ない分安心できる • 冪等性最高 ◦ 副作用が分かれているので状態を意識しなくていい UIとロジックを分けられる
29 • めっちゃ生産性向上した • 新しくComposable作る際にある程度コストはかかるが、体感40%くら いは生産性向上してる • Compose最高! 結果
30 30 02. 辛かったこと
31 • Pager ◦ animateToScrollPageで最後のページから最初のペー ジに飛ぶ時にアニメーションしてくれない ◦ https://issuetracker.google.com/issues/198753 885 •
Placeholder ◦ 複数のplaceholderのImagePainter#Stateを監視す るとクラッシュする(Android6だけ) accompanist
32 MotionLayout
33 • 現状MotionSceneがjsonでしか書けない • そのうちKotlinで書けるらしい ◦ https://github.com/androidx/constraintlay out/wiki/Compose-MotionLayout-JSON-S yntax MotionLayout
34
35 • かなり生産性が上がるのでどんどん導入していきたい • もちろんまだまだ足りない機能はたくさんある • もっとComposeが便利になっていくのが楽しみ まとめ
Thank you 36