Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
2App, 1Repository
Search
n-seki
February 15, 2026
Programming
52
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
2App, 1Repository
n-seki
February 15, 2026
More Decks by n-seki
See All by n-seki
10年もののバグを退治した話
n_seki
0
270
永続化、なに使おう?
n_seki
0
340
OS間でBluetooth処理を(一部)共通化している話
n_seki
0
110
やってみようMaven!
n_seki
0
390
Try Android Health Connect
n_seki
0
100
Other Decks in Programming
See All in Programming
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
200
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
290
XHTMLが残したもの
yosuke_furukawa
PRO
2
820
そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す
myus4a
0
150
JRuby: Past, Present, and Future
headius
0
120
変化を抱擁するドキュメントの作り方 - ビジネスルール駆動開発がもたらす、コードとの新しい関係
ioki
2
220
Heart of Swift Concurrency
koher
0
910
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
280
市販E-Readerを乗っ取れ 〜Embedded Swiftで電子ペーパーガジェットを制御する〜
trickart
0
190
モジュールの視点からSwiftを読み解く #iosdc
s_shimotori
0
180
海上で動くGoサーバー: goroutineとchannelでさばく航行データストリーム
atsuki_seo
0
730
[GoCon2026] When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go
takehaya
6
2.3k
Featured
See All Featured
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.6k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
430
Code Review Best Practice
trishagee
74
20k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
870
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.3k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
WENDY [Excerpt]
tessaabrams
14
39k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.8k
Six Lessons from altMBA
skipperchong
29
4.5k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
410
Transcript
STORES 株式会社 ~ 設計と実装の振り返り ~ 2025.12.09 Ebisu mobile #12 Naoto
Uwaseki 2つのアプリ、1つのリポジトリ
自己紹介 2 • Naoto Uwaseki ◦ n-seki • 決済一筋8年目 ✌
• アイコンはモルモットです→
これまでの決済Androidアプリ 3 • 普通のAndroidアプリ ◦ Google Play で配信中! • 機能
◦ 決済、返金、決済履歴、入金 ◦ スタッフ管理、お知らせ...etc • 外部機器との接続 ◦ 決済端末(Bluetooth接続) ◦ プリンター(Bluetooth接続) • Phone/Tablet向けのUI実装
これまでの決済Androidアプリ 4 • Gradleマルチモジュール構成 • appモジュールをビルドすること で.apkが得られる • 決済SDKとの共通モジュールが あったり
• View/Compose + ViewModel + UseCase + Repository . ├── app // 決済アプリ ├── core ├── hoge └── huga
• 決済端末2もAndroid! • 技術検証によって、既存アプ リと同じところ/違うところ が見えてきた......! • 要件検討も本格化し、どのよ うな機能が必要そうか見えて きた......!
決済端末2 で動作する決済アプリを作る......! 5
既存アプリと専用アプリの共通点 6 1. どちらもAndroidアプリである! → ☺☺☺ 2. 決済端末との接続処理の流れや決済処理のフローにはほとんど 差分がない! →
決済のコアな処理には決済端末も深く関わっており、アプ リと決済端末でデータのやり取りが必要です。 コネクションの確立、決済処理などのプロトコルについて、 決済端末と決済端末2では(ほぼ)違いがない、ということ。
既存アプリと専用アプリの共通点 7 3. サポートする決済手段も同じ! 4. 決済以外の機能にも大きな差分はなし! a. 既存アプリにある機能のいくつかを落とした形になりそう
• 決済端末2のディスプレイは小さい!(480 x 800) ◦ 既存アプリのUI/UXそのままでは使いにくい画面も ◦ デバイスのカラーに合わせたデザインを取り入れたい → UIは新しく実装してあげる必要がありそう
😼 既存アプリと専用アプリの相違点 8
• 接続方式が異なる! ◦ 既存アプリはBluetoothで決済端末と接続している ◦ 決済端末2上で動作するアプリはローカルソケット通信で カードリーダーとやり取りする • GMSが利用できない......! ◦
(さきほどの発表の通り) 既存アプリと専用アプリの相違点 9
共通点と相違点 10 共通点 相違点 • Androidアプリ • コアなロジック • 決済手段
• 決済以外の機能 • ディスプレイサイズ • 決済端末との通信方式 • GMS
考えられる戦略 11 1. 新規で0からアプリを作成する a. 既存アプリとは完全分離 2. 既存アプリの資産を最大限活かす a. うまいこと処理を抽象化すればできそう......?
考えられる戦略 12 1. 新規で0からアプリを作成する a. 既存アプリとは完全分離 2. 既存アプリの資産を最大限活かす a. うまいこと処理を抽象化すればできそう......?
→ 技術検証を重ね、 「既存アプリの資産を活かして開発する」ことに 🔥
2つのアプリ、1つのリポジトリ 13 • 既存の資産を活用した方が、品質が高いアプリをより短期間で 実装できそう • どのレイヤーを既存アプリと共通化するかも併せて検討
2つのアプリ、1つのリポジトリ 14 • 本格実装前のリファクタリング ◦ Bluetooth/ローカルソケットの接続方式を抽象化 ◦ 既存アプリと共通して利用したいコードたちを、新しい Gradleモジュールにお引越し ▪
Daggerが壊れたりしたので修正...... 😌 ◦ 2024/12 前後くらい • GMSが使えないので実装を変更 ◦ (さきほどの発表の通り)
2つのアプリ、1つのリポジトリ 15 • 既存のViewModel/UiStateを利用する形で Full Composeでアプリ実装 ◦ 必要があればリファクタリング . ├──
app // 既存アプリ ├── appCommon // 既存アプリとの共通モジュール ├── core ├── hoge ├── huga └── stores-payments-2-app // 決済端末2向けアプリ sp2-app app appCommon core
良かったこと/改善できそうなこと 16 • 👍 既存コードの多くを共通化できた ◦ 開発スピード、品質に寄与 • 👍 0からUI実装できた(Full
Compose) • ✊ 共通コードの中に既存アプリ or 決済端末2 の分岐が生まれ てしまった • ✊ 既存設計に引っ張られてしまう場合があった ◦ ロジックが複雑になってしまったり ◦ 既存アプリと同じロジックだと問題があることが後々判明 したり
まとめ 17 • 改善の余地はありつつ、当初の設計どおりに実装できて、年内 リリースが完遂できたことは素直に喜ばしい • これから運用していく中でも課題がでてくると思うので、適宜 見直しをしながらコードベースを育てていきたい