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
KMPナニモワカラナイ
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
sobaya
January 22, 2024
Programming
430
1
Share
KMPナニモワカラナイ
sobaya
January 22, 2024
More Decks by sobaya
See All by sobaya
会社紹介20251001
spbaya0141
0
31
会社説明20250704
spbaya0141
0
43
酒飲んでたらテックリードになった話
spbaya0141
0
510
とある大喜利会社の戦略
spbaya0141
0
240
そば屋のひとりごと(KMP関連の雑な話し)
spbaya0141
0
650
JetpackSecurityを今さら学んでみた
spbaya0141
0
470
日本三大何をしているか分からない企業の育児制度
spbaya0141
0
1.1k
僕が考えた超最強のKMMアプリの作り方
spbaya0141
0
610
lazy grid layout
spbaya0141
1
610
Other Decks in Programming
See All in Programming
不変条件と整合性境界—ビジネスが決める設計判断と実現パターン / Invariants and Consistency Boundaries
nrslib
13
3.3k
GitHub Copilot CLIのいいところ
htkym
2
1.2k
権限チェックの一貫性を型で守る TypeScript による多層防御
mnch
4
1.1k
AI 時代のソフトウェア設計の学び方
masuda220
PRO
29
12k
Oxlintのカスタムルールの現況
syumai
5
980
メソッドのジェネリクスでGoの夢は広がるか? / Kyoto.go #65
utgwkk
3
430
並列実装の現場、2ヶ月間実務でAIを使い倒したAIもPCも私も限界が近い
ming_ayami
0
100
軽量Java基盤の設計 DIコンテナに頼らない、長期保守と1秒起動の実現 JJUG CCC 2026 Spring
macha64
0
430
LLM本来の能力を解き放つサンドボックス技術とAI民主化への適用
yukukotani
3
2.2k
脅威をエンジニアリングの糧にして――現場編 / Turning Threats into Engineering Fuel — Field Edition
nrslib
0
240
決定論的オーケストレーションの設計と実装 / Design and Implementation of Deterministic Orchestration
nrslib
3
750
OCRを使ってゲームのアイテムをデータ化する
kishikawakatsumi
0
130
Featured
See All Featured
Evolving SEO for Evolving Search Engines
ryanjones
0
210
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
430
A Soul's Torment
seathinner
6
2.9k
Code Reviewing Like a Champion
maltzj
528
40k
Optimising Largest Contentful Paint
csswizardry
37
3.7k
New Earth Scene 8
popppiees
3
2.3k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
200
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.4k
The World Runs on Bad Software
bkeepers
PRO
72
12k
What does AI have to do with Human Rights?
axbom
PRO
1
2.2k
Automating Front-end Workflow
addyosmani
1370
210k
Documentation Writing (for coders)
carmenintech
77
5.4k
Transcript
KMPナニモワカラナイ
KMP ナニモワカラナイ 〜2024 年には完全に理解できるか!?〜 そば屋
まずは2023 年を振り返る
KMP のお仕事を2 個経験
一つ目のお仕事紹介 UI のState までKMP で管理しアプリ側は基本的にUI だけを用意すれ ばいい設計 DI 周りはアプリにお任せしているのでclass が用意されているだ
け Repository はAndroid,iOS,KMP の3 個用意しKMP は好きなバージョン を取り込めるようになっている開発環境
一つ目のお仕事紹介 詳しいことはDroidKaigi 2023 で発表 したので、気になる方はそちらを ご覧ください
二つ目のお仕事紹介 共通化するのはRepository かUseCase までとし、UI のState 管理も アプリで行う方式 DI はKoin を使用してKMP
内で完結できる部分は完結させている 開発環境も1 つのRepository で行っている
いったんまとめる
共通化 Compose Multiplatform を使ってUI も含めて共通化( 未経験) UIState まで共通化 Repository,UseCase まで共通化(
一部Util なども提供)
DI Koin などKMP 対応のライブラリを使いKMP 内で可能な限り対応 Hilt がいいからDI はアプリ側で行う
Repository それぞれ別で用意する 一本で行く
Domain まで共通化 UI ステートも共通化 UI も共通化 アプリでDI KMP でDI 別Repository
共通Repository 経験済みの組み合わせ
上ルート
上ルート 今回の仕事ではRepository 周りが複雑なので、 工数の削減になりそう( 手厚くテストも書きやすい) 同一のソースコードなのでAndroid,iOS で違う人が実装したことに よる仕様の勘違いでの違う動作は防げる
上ルート ただ、それほどRepository やUseCase がそれほど複雑な事が多いの か?→工数的なメリットは一般的に得にくい気がする 同じコードを使えるので同じ動作が担保されることについてはメリ ットになると思う
下ルート
下ルート Android の開発者目線だと同じKotlin だしUI だけ書けばだいたい想定通 り動作してくれたので楽な部分もあった
下ルート KMP とは別要因も絡み以下の問題が出た UIState を作った人とアプリの実装者が別だからコミュニケーシ ョンコストが異常に高くなった UIState まで用意するとiOS での取り回しが辛かったらしくiOS は
KMP の実装を使わないことも発生した
KMP 実装 下ルート Repository を分けていたことで急ぎの対応が遅くなった。 KMP レビュー KMP 配布 KMP
取り込み アプリ実装
現時点での確定情報 ※ 明日には言ってる事が変わる可能性があります
共通化はDomain まで State まで手を出すとiOS が使えないことも出てきてしまい共通化 でなくなる あと、iOS の人がめっちゃ怒ってたからやめた方がいい( 魚肉ソー セージ渡して納得してもらった)
Repository は1 本 KMP の取り込み作業がなくなるし、毎回Android,iOS のビルドが通 ることが確認できるので安心感がある( 取り込み時に問題発覚が 無い) ただ、変更されたコードを確認して、Android,iOS
必要なビルドだ け走る設定はした方がいい
何が分からないか把握して 2024 年を生きる
移行 新規の立ち上げはしたけど、KMP への移行は未経験 Android,iOS 共にアプリがあるけどKMP にする Android しかなくてiOS も作りたいからKMP 使う
iOS しかなくてAndroid も作りたいからKMP 使う Flutter などからの移行
Android,iOS 共にアプリがあ るけどKMP にする どんな目的があるか知りたい。 工数削減を目的とされると厳しいと思っているので、その他何かメ リットがあれば説明できるようになりたい。 移行と追加開発のバランスなども知りたい
Android しかなくてiOS も作 りたいからKMP 使う Retrofit をKtorfit に置き換え( たぶん簡単) は想像がつく
UseCase もShare モジュールにすればいいだけだと思う DI どうするか?既存があるならHilt を使ってる確率が高そう Repository が分かれてたら取り込み作業で面倒が起きる可能性あるけ ど、1 本なら大きな問題ないのでは?
iOS しかなくてAndroid も作 りたいからKMP 使う iOS もUI 以外は使いまわせない気がするからメリットあるのか学びた い そもそもiOS
何も知らないからそこからスタート
Flutter などからの移行 Flutter 何それ美味しいの? この移行が発生するのは最新な機能を使いたいとかUI 周りをめっち ゃこだわりたいだと思い込んでる 完全に作り直すことになるのとFlutter に比べたら工数増えるし本当 にメリットがあるパターンがあるのか知りたい
※Flutter 以外だとしても
2024 年なにやるの?
まずは移行の知識を得よう 仕事はいつどんな要件の物がもらえるか分からないので、 Now in Android をKMP に移行してみるチャレンジをやってみよう と思ってる iOS の開発知識も一緒に得られるメリットも!!
どんな要望があるのか聞きたい KMP 移行してみたいかもとか気になると言う会社さん!! お話ししてください!!求めている物とか体制とかを聞けるだ けで知識になるのでお願いします。 これまでの経験ベースでオススメ度合いや構成・ライブラリな どお話しできます。 ※ ゆめみにお仕事くれたら嬉しいですが、くれなくてもいいのでお話しできたら嬉しいで す(
お話し後に営業的な連絡をガンガンするとかはしないので)
2024 年も一番大切にしたい事
働かないで! 働かないで! 5000 兆円欲しい! 5000 兆円欲しい!