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.3k
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で予期せぬ終了を検知する話 / Detect unexpected termination with MetricKit
nekowen
1
200
iOS13向けに位置情報周りを対応しようとしたら苦労した話
nekowen
1
420
Other Decks in Programming
See All in Programming
Sheets API使ってみた
toshi0383
2
180
CREってこういうこと? 体験入社 - 提案資料 - / what-is-cre-trial-employment
shinden
1
620
哲学史とモデリング
tanakahisateru
2
420
RaaP
ksss
0
160
Slackワークフローで感謝を伝える機能/WiFi 自動接続/Figma to React Component/障害レポート君 Team3@NOT A HOTEL
nakaohiroshi
0
100
Timeline エディター拡張入門
yucchiy
0
450
Escolhendo (ou não) o melhor ORM para o seu projeto
andreiacsilva
1
160
戦略的DDDは重いのか? / Is strategic DDD heavy?
pictiny
3
2.1k
An adventure of Happy Eyeballs
coe401_
1
140
Ruby on Fails - effective error handling with Rails conventions
talyssonoc
0
300
最近コードレビューで指摘したこと
forrep
3
110
Using "modern" Ruby to build a better, faster Homebrew
mikemcquaid
2
260
Featured
See All Featured
Facilitating Awesome Meetings
lara
43
5.6k
The Power of CSS Pseudo Elements
geoffreycrofte
62
5k
Faster Mobile Websites
deanohume
300
30k
Web Components: a chance to create the future
zenorocha
306
41k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Robots, Beer and Maslow
schacon
PRO
155
8k
Rails Girls Zürich Keynote
gr2m
91
13k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
1
130
Design by the Numbers
sachag
274
18k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
228
16k
Optimising Largest Contentful Paint
csswizardry
13
2.4k
Thoughts on Productivity
jonyablonski
60
3.9k
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