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
2App, 1Repository
Search
n-seki
February 15, 2026
Programming
0
11
2App, 1Repository
n-seki
February 15, 2026
Tweet
Share
More Decks by n-seki
See All by n-seki
10年もののバグを退治した話
n_seki
0
240
永続化、なに使おう?
n_seki
0
320
OS間でBluetooth処理を(一部)共通化している話
n_seki
0
110
やってみようMaven!
n_seki
0
370
Try Android Health Connect
n_seki
0
96
Other Decks in Programming
See All in Programming
SourceGeneratorのマーカー属性問題について
htkym
0
190
20260313 - Grafana & Friends Taipei #1 - Kubernetes v1.36 的開發雜記:那些困在 Alpha 加護病房太久的 Metrics
tico88612
0
160
「抽象に依存せよ」が分からなかった新卒1年目の私が Goのインターフェースと和解するまで
kurogenki
0
110
S3ストレージクラスの「見える」「ある」「使える」は全部違う ─ 体験から見た、仕様の深淵を覗く
ya_ma23
0
370
オブザーバビリティ駆動開発って実際どうなの?
yohfee
3
830
Codexに役割を持たせる 他のAIエージェントと組み合わせる実務Tips
o8n
4
1.3k
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
190
LangChain4jとは一味違うLangChain4j-CDI
kazumura
1
170
米国のサイバーセキュリティタイムラインと見る Goの暗号パッケージの進化
tomtwinkle
2
560
CSC307 Lecture 13
javiergs
PRO
0
320
野球解説AI Agentを開発してみた - 2026/02/27 LayerX社内LT会資料
shinyorke
PRO
0
210
nilとは何か 〜interfaceの構造とnil!=nilから理解する〜
kuro_kurorrr
3
1.9k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.4k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
410
Bash Introduction
62gerente
615
210k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
2.4k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
980
Odyssey Design
rkendrick25
PRO
2
540
Tell your own story through comics
letsgokoyo
1
840
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
0
170
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
55k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Mind Mapping
helmedeiros
PRO
1
120
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 • 改善の余地はありつつ、当初の設計どおりに実装できて、年内 リリースが完遂できたことは素直に喜ばしい • これから運用していく中でも課題がでてくると思うので、適宜 見直しをしながらコードベースを育てていきたい