Submit Search
Upload
失敗から学ぶAndroid設計話
•
7 likes
•
4,536 views
C
chigichan24
Follow
closedな勉強会で発表したものです.Androidの設計の話を中心に書いています.
Read less
Read more
Mobile
Report
Share
Report
Share
1 of 89
Download now
Download to read offline
Recommended
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
Jun-ichi Sakamoto
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
Kotlinアンチパターン
Kotlinアンチパターン
Recruit Lifestyle Co., Ltd.
Recommended
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
Jun-ichi Sakamoto
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
Kotlinアンチパターン
Kotlinアンチパターン
Recruit Lifestyle Co., Ltd.
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
Windowsフォームで大丈夫か?一番良いのを頼む。
Windowsフォームで大丈夫か?一番良いのを頼む。
Yuya Yamaki
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
脱 Excel設計書
脱 Excel設計書
rai
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
de:code 2017
2021-12-16 テストコードのないレガシーアプリケーションとの向き合い方
2021-12-16 テストコードのないレガシーアプリケーションとの向き合い方
naoto teshima
SpringBootTest入門
SpringBootTest入門
Yahoo!デベロッパーネットワーク
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
나의 이직 이야기
나의 이직 이야기
종립 이
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
いまさら学ぶMVVMパターン
いまさら学ぶMVVMパターン
Yuta Matsumura
Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」
Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」
Kazumi IWANAGA
GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境
GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境
Kazumi IWANAGA
More Related Content
What's hot
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
Windowsフォームで大丈夫か?一番良いのを頼む。
Windowsフォームで大丈夫か?一番良いのを頼む。
Yuya Yamaki
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
脱 Excel設計書
脱 Excel設計書
rai
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
de:code 2017
2021-12-16 テストコードのないレガシーアプリケーションとの向き合い方
2021-12-16 テストコードのないレガシーアプリケーションとの向き合い方
naoto teshima
SpringBootTest入門
SpringBootTest入門
Yahoo!デベロッパーネットワーク
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
나의 이직 이야기
나의 이직 이야기
종립 이
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
いまさら学ぶMVVMパターン
いまさら学ぶMVVMパターン
Yuta Matsumura
What's hot
(20)
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Windowsフォームで大丈夫か?一番良いのを頼む。
Windowsフォームで大丈夫か?一番良いのを頼む。
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
脱 Excel設計書
脱 Excel設計書
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
ユーザーストーリーの分割
ユーザーストーリーの分割
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
2021-12-16 テストコードのないレガシーアプリケーションとの向き合い方
2021-12-16 テストコードのないレガシーアプリケーションとの向き合い方
SpringBootTest入門
SpringBootTest入門
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
나의 이직 이야기
나의 이직 이야기
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
いまさら学ぶMVVMパターン
いまさら学ぶMVVMパターン
Similar to 失敗から学ぶAndroid設計話
Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」
Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」
Kazumi IWANAGA
GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境
GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境
Kazumi IWANAGA
勘違いだらけのAndroid UIデザイン
勘違いだらけのAndroid UIデザイン
Nobuya Sato
姫路IT系勉強会「ADB接続でかんたんフィジカルコンピューティング」
姫路IT系勉強会「ADB接続でかんたんフィジカルコンピューティング」
Kenichi Yoshida
SnapDishの事例
SnapDishの事例
Fumikazu Kiyota
ALMツールたべくらべ
ALMツールたべくらべ
Kaoru NAKAMURA
Inside Android N
Inside Android N
Shinobu Okano
Droidcon London2012 Speaker Experience
Droidcon London2012 Speaker Experience
Kenichi Kambara
Unity ゲーム開発
Unity ゲーム開発
Katsutoshi Makino
GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で!
GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で!
Kazumi IWANAGA
XamarinStudio勉強会 2014/09/08
XamarinStudio勉強会 2014/09/08
孝文 田村
Chromeでストレージ永続化を実現するには
Chromeでストレージ永続化を実現するには
goccy
オープン・ソースで構築するARMマイコン開発環境 ―― GCC,Eclipse,OpenOCDで統合開発環境,JTAGデバッグもできる!
オープン・ソースで構築するARMマイコン開発環境 ―― GCC,Eclipse,OpenOCDで統合開発環境,JTAGデバッグもできる!
Masaki Muranaka
うちの開発におけるXD利用法
うちの開発におけるXD利用法
Kazuma Sekiguchi
Azure Cosmos DB Emulator on Docker を GitHub Codespaces で動かす!
Azure Cosmos DB Emulator on Docker を GitHub Codespaces で動かす!
Kazumi IWANAGA
Google io2011報告
Google io2011報告
cat kaotaro
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
日本マイクロソフト株式会社
Php Conference 2012 concrete5
Php Conference 2012 concrete5
Hishikawa Takuro
Web制作者がandriodのcddを読んでみた version1.1
Web制作者がandriodのcddを読んでみた version1.1
Masakazu Muraoka
Unity/CSharp 1 - pptx
Unity/CSharp 1 - pptx
tagawakiyoshi
Similar to 失敗から学ぶAndroid設計話
(20)
Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」
Developers Summit 2023 9-D-1「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」
GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境
GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境
勘違いだらけのAndroid UIデザイン
勘違いだらけのAndroid UIデザイン
姫路IT系勉強会「ADB接続でかんたんフィジカルコンピューティング」
姫路IT系勉強会「ADB接続でかんたんフィジカルコンピューティング」
SnapDishの事例
SnapDishの事例
ALMツールたべくらべ
ALMツールたべくらべ
Inside Android N
Inside Android N
Droidcon London2012 Speaker Experience
Droidcon London2012 Speaker Experience
Unity ゲーム開発
Unity ゲーム開発
GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で!
GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で!
XamarinStudio勉強会 2014/09/08
XamarinStudio勉強会 2014/09/08
Chromeでストレージ永続化を実現するには
Chromeでストレージ永続化を実現するには
オープン・ソースで構築するARMマイコン開発環境 ―― GCC,Eclipse,OpenOCDで統合開発環境,JTAGデバッグもできる!
オープン・ソースで構築するARMマイコン開発環境 ―― GCC,Eclipse,OpenOCDで統合開発環境,JTAGデバッグもできる!
うちの開発におけるXD利用法
うちの開発におけるXD利用法
Azure Cosmos DB Emulator on Docker を GitHub Codespaces で動かす!
Azure Cosmos DB Emulator on Docker を GitHub Codespaces で動かす!
Google io2011報告
Google io2011報告
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
Php Conference 2012 concrete5
Php Conference 2012 concrete5
Web制作者がandriodのcddを読んでみた version1.1
Web制作者がandriodのcddを読んでみた version1.1
Unity/CSharp 1 - pptx
Unity/CSharp 1 - pptx
失敗から学ぶAndroid設計話
1.
失敗から学ぶ設計話 ~Android編~ chigichan24 Android ロボットは、Google が作成および提供している作品から複製または変更したものであり、 Creative
Commons 3.0 Attribution ライセンスに記載された条件に従って使用しています。
2.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
3.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
4.
今日の話 Android版 iOS版 https://github.com/cyder
5.
• 端的にいうと • 同じルームに入った人と動画を同期して再生する. •
動画を見ながらコメントすることができる. • 誰でも入れるルームの作成,人気ルームのサジェストなど. • Androidだけ先行でリリースしていた,iOSをリリース するタイミングでAndroidの技術的負債を一気に改修 (回収)したかった. • 機能追加が常にアドホックで命懸け(?)な状態から いつ不幸にもバズっても運用できるように.
6.
A lot of
Problems Copy and Paste No external Library Fat Activity Smart UI Null Pointer Exception Mysterious Bug No ViewModel No Architecture Broken naming convention Broken directory partition No Repository Java
7.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
8.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
9.
• ジェンガ論 • 地盤の段階(ジェンガの下の層)がゆるゆるだと,機能追加や 改修(ジェンガの上に新しく置く操作)はつらい.ジェンガが 崩れる可能性(プロジェクト終了のお知らせ)を秘めている. •
逆に基盤をしっかり作っていれば(下の層がきっちり積まれて いれば),機能追加が少々荒くなっても(上の層に繁雑にジェ ンガを置いても)しばらくは耐えられる. 一から書き直す必要があると判断
10.
どういう構成にしよう 🤔
11.
様々なアーキテクチャやライブラリ,思想論 いろいろありすぎ とても困った MVC MVP MVVM Flux Redux AAC The Clean Architecture DDD SOLID Jetpack Hexagonal Architecture Onion Architecture
12.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
13.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
14.
様々なアーキテクチャやライブラリ,思想論 いろいろありすぎ とても困った MVC MVP MVVM Flux Redux AAC The Clean Architecture DDD SOLID Jetpack Hexagonal Architecture Onion Architecture VIPER
15.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
16.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
17.
MVC • Model-View-Controller • rails,ios
projectとかがデフォルトで使ってるやつ. • アプリに実装しようとするといろいろ厄介. • 全体的に密結合になる.(Controllerの肥大化) • Androidに適用しようとするとActivityはControllerなの? Viewなの?あれれ...ってなる. View Controller Model
18.
MVP • Model-View-Presenter • 方向を単一方向にする. •
ViewとActivity,Fragmentが対応する. • PresenterではViewに依存する処理はinterfaceとしてもらう. • データの更新等の処理はModelに投げる. • ViewではPresenterのメソッドを呼ぶ. View Presenter Model
19.
MVPの雰囲気(iOS × Swift) protocol
HogeView: class { func updateLabel(text: String) } final class HogeViewController: UIViewController, HOGEView { @IBOutlet private weak var labels: UILabel! @IBOutlet private weak var button: UIButton! private lazy var presenter = HogePresenter() override func viewDidLoad() { super.viewDidLoad() button.addTarget(presenter, action: #selector(presenter.changeText), for: .touchUpInside) } func updateLabel(text: String) { label.text = text } }
20.
MVPの雰囲気(iOS × Swift) final
class HogePresenter { private weak var view: HogeView func changeText() { // ここからmodelをいじりに行く view.updateLabel() } } Presenterが生のViewへの参照を持つのは危なすぎるので, 適宜機能制限した BaseViewClassを継承するべき. MVPの問題点 Presenterがviewを持っていて何やらかされるか分からない.
21.
MVVM • Model-View-ViewModel • MVPと似た構造をしているが,ViewとViewModelは databindingで双方向につながっている. •
databindingとは? • protocolやinterfaceでcallback的に層を繋げず, 通知を流す仕組み.viewへの参照を持たない!!! • Android : databinding,ButterKnife,KotterKnife • ios : RxSwift,Bond • C# : WPFにおけるxamlとかの仕組み View ViewModel Model ↑ databinding
22.
Flux Action Dispatcher Store
View Action • Flux • MV *ではデータの流れに双方向性があって大変だった問題を 解決した.js由来. • 一方向にデータが流れ,Dispatcherで様々な振り分ける. • (現在FluxアーキテクチャでAndroidアプリ作ってるので作り 上げたら感想がわかりそう)
23.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
24.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
25.
アーキテクチャ思想のキモ • 変更への強さ • 層の数はそれぞれだが,達成したいことは変更に強いこと! •
層の分離はテスタビリティの向上 • 層で分離できる ≈ 層をmockにしてテストができる.
26.
変更への強さ 偉い人 旧アーキテクチャ編
27.
変更への強さ あのAPIのレスポンス ちょっと変えます 偉い人 旧アーキテクチャ編
28.
変更への強さ あのAPIのレスポンス ちょっと変えます 偉い人 え! UIと直接紐付いてるか ら変更は至難の業だ 旧アーキテクチャ編
29.
怖い話
30.
昔のアーキテクチャであった怖い話
31.
昔のアーキテクチャであった怖い話 • 1 画面1
API( 1 エンドポイント )しか叩けない • なぜそんな設計をしたのか... • ごりごり実装メインでやっていたらこうなった.
32.
昔のアーキテクチャであった怖い話 • 1 画面1
API( 1 エンドポイント )しか叩けない • なぜそんな設計をしたのか... • ごりごり実装メインでやっていたらこうなった. • 使い回しできそうなコードが全部コピペによって生成 されている. • 抽象化して... • 全部に対して変更があったらどうするの...
33.
昔のアーキテクチャであった怖い話 • 1 画面1
API( 1 エンドポイント )しか叩けない • なぜそんな設計をしたのか... • ごりごり実装メインでやっていたらこうなった. • 使い回しできそうなコードが全部コピペによって生成 されている. • 抽象化して... • 全部に対して変更があったらどうするの... • 謎のマジックナンバーによって管理されるfragment • それfragmentの表示順かえるのでも一苦労やで...
34.
The Clean Architecture
35.
Android10CoderのMVPによる解説
36.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
37.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
38.
設計原則 • このことばが正しいのかはちょっと怪しい. • 設計手法や実装していく上でのルールの話. •
DDDではドメインの世界観をきちんときめてそれを体 現するコードを書く. • SOLID原則はコード実装時のルール SyncPodという世界観を作っているもの(Entity)はなにか? Chatなの?,Roomなの?,Videoなの?,Userなの? これらの関係は?,なにがValueObjectなの? 取り入れた例 publicなmethod名とユビキタス言語を紐付ける. fun post_to_hoge( )とかはありえない.
39.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
40.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
41.
ごっちゃになってるので整理する 設計パターン MVC MVP MVVM Flux Redux AAC Jetpack ライブラリ群 DDD SOLID 設計原則 The Clean Architecture Hexagonal Architecture Onion Architecture アーキテクチャ思想
42.
さて,どういう構成にしよう 🤔
43.
MVVM + The
Clean Architecture • 超最新トレンドから一歩引いた感じに落ち着いた. • 使用技術としてやりたかったことはまだまだいろいろあった. • MVVMは実装コストや学習コストは高いが最も堅牢 • MVPにしてもよかったが,可能な限りviewの要素と 切り離したいという思い. • Clean Architectureに載せることで依存を解消 • レイヤー化の恩恵は大きい • 今後様々な変更があることを加味して変更に強く! • 適宜SOLIDやDDDの原則を適用(code reviewで共有) • エンジニア間で意識・アプリの世界観を共有.
44.
主な使用技術 with KotlinRxJava(RxAndroid,RxKotlin) Dagger2 DI Container
Jetpack
45.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
46.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
47.
構成図 例外的に 呼んでる時ある. View ViewModel Repository SyncPodApi SyncPodWsApi SharedPreference databinding I I
II I Interface(抽象)に依存するようにする … Interface Class method call method call stream stream … method call … stream
48.
MVVM的には View ViewModel Repository SyncPodApi SyncPodWsApi SharedPreference I I
II View ViewModel Model
49.
基本的には
50.
設計・実装時のポイント① • PresenterをViewModelとしてViewとbind • StreamはViewModelまで流れてそれより上はdatabinding •
UseCaseをなくした. • 設計時にUseCaseの存在の意味を見いだせなかった. • ViewModelが直接Repository参照して大丈夫でしょ(?) • 抽象に依存する. • 依存関係逆転の法則(DIP) • DI Containerのdagger2で解決 • ViewとViewModelは1対1で. • Viewでは基本的に何も操作しない(smartUIにならないように)
51.
設計・実装時のポイント② • Rxの型としてObservableは使わない. • 意味がわかりにくくなるので,Single,Compleatable, Flowableのみに. •
むやみにFlowable使ったら👊 • ViewModelで使うメソッド名はユーザー目線(ユビキタ ス言語で表現できるもの)に • websocketを扱う部分もなんとかstreamに. • そういうライブラリが存在しないので,websocketでのレス ポンス(listenerで取る形)を全部Rxのstreamに書き直す.
52.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
53.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
54.
良かった点👍 • 機能追加が楽
55.
怖い話
56.
リリース初日で機能追加決定
57.
リリース初日で機能追加決定 • コードをどう書くべきか はすぐに思いつく. • ちょっとデザイン考える のがしんどいかなー. •
一週間あれば確実に問題 ないし, ロジックは1時間くらい で実装できた. Android
58.
リリース初日で機能追加決定 • コードをどう書くべきか はすぐに思いつく. • ちょっとデザイン考える のがしんどいかなー. •
一週間あれば確実に問題 ないし, ロジックは1時間くらい で実装できた. • あああああああああああ あああああああああああ あああああああああああ あああああああああああ ああああ • もうどうせ汚いコードだ ししょうがないやろ(最悪 Android iOS
59.
良かった点👍 • 機能追加が楽
60.
良かった点👍 • 機能追加が楽 • 身をもって体感.
61.
良かった点👍 • 機能追加が楽 • 身をもって体感. •
新しいメンバーがjoinしやすい • ファイルごとの役割を明確にしているので どこに何を書くのかがはっきりしている.
62.
良かった点👍 • 機能追加が楽 • 身をもって体感. •
新しいメンバーがjoinしやすい • ファイルごとの役割を明確にしているので どこに何を書くのかがはっきりしている. • Kotlinで書いてるからJavaの呪いから開放されている.
63.
良かった点👍 • 機能追加が楽 • 身をもって体感. •
新しいメンバーがjoinしやすい • ファイルごとの役割を明確にしているので どこに何を書くのかがはっきりしている. • Kotlinで書いてるからJavaの呪いから開放されている. • 意味不明なバグも起きなくなった. • バグ数,クラッシュ数が明らかに減った!!!
64.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
65.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
66.
悪かった点👎 • UseCaseをやっぱり作るべきだった.
67.
設計・実装時のポイント① • PresenterをViewModelとしてViewとbind • StreamはViewModelまで流れてそれより上はdatabinding •
UseCaseをなくした. • 設計時にUseCaseの存在の意味を見いだせなかった. • ViewModelが直接Repository参照して大丈夫でしょ(?) • 抽象に依存する. • 依存関係逆転の法則(DIP) • DI Containerのdagger2で解決 • ViewとViewModelは1対1で. • Viewでは基本的に何も操作しない(smartUIにならないように)
68.
設計・実装時のポイント① • PresenterをViewModelとしてViewとbind • StreamはViewModelまで流れてそれより上はdatabinding •
UseCaseをなくした. • 設計時にUseCaseの存在の意味を見いだせなかった. • ViewModelが直接Repository参照して大丈夫でしょ(?) • 抽象に依存する. • 依存関係逆転の法則(DIP) • DI Containerのdagger2で解決 • ViewとViewModelは1対1で. • Viewでは基本的に何も操作しない(smartUIにならないように) 自分でやってるやん...
69.
UseCaseが無い問題 • Repositoryパターンの肥大化 &
やることが多い. • このパターンではそもそもデータのソースを考えず CQRS操作ができるようにするべき.
70.
UseCaseが無い問題 • Repositoryパターンの肥大化 &
やることが多い. • このパターンではそもそもデータのソースを考えず CQRS操作ができるようにするべき. Repository UseCase command,queryを投げる データソースを吸収して, → 上に流すだけ データを加工する. ビジネスロジックを委ねる.→ よしなにデータを取ってくる
71.
悪かった点👎 • UseCaseをやっぱり作るべきだった. • Clean
Architectureは正しいなあと痛感. • Repositoryは肥大化してしまっている.
72.
悪かった点👎 • UseCaseをやっぱり作るべきだった. • Clean
Architectureは正しいなあと痛感. • Repositoryは肥大化してしまっている. • ライブラリの選定をミスった.
73.
ライブラリ選定の話
74.
ライブラリ選定の話 リリース直後はAndroid 6.0未満の端末では動かなかった 😱
75.
ライブラリ選定の話 • websocketを扱うために使っていたライブラリの バグだと判明. • ライブラリは全然整備されていない. •
star 1で,一年近くなにも更新されていない.
76.
ライブラリ選定の話 • websocketを扱うために使っていたライブラリの バグだと判明. • ライブラリは全然整備されていない. •
star 1で,一年近くなにも更新されていない. ライブラリの選定はコミュニティの活発度を見よう!
77.
悪かった点👎 • UseCaseをやっぱり作るべきだった. • Clean
Architectureは正しいなあと痛感. • Repositoryは肥大化してしまっている. • ライブラリの選定をミスった. • 活発なものを選ぼう! • Androidバージョン違いで起きるバグを事前に検証しよう!
78.
悪かった点👎 • UseCaseをやっぱり作るべきだった. • Clean
Architectureは正しいなあと痛感. • Repositoryは肥大化してしまっている. • ライブラリの選定をミスった. • 活発なものを選ぼう! • Androidバージョン違いで起きるバグを事前に検証しよう! • DIコンテナで(dagger)で無理やり依存関係を作ってい る. • なるべく疎になるようにしよう.
79.
悪かった点👎 • UseCaseをやっぱり作るべきだった. • Clean
Architectureは正しいなあと痛感. • Repositoryは肥大化してしまっている. • ライブラリの選定をミスった. • 活発なものを選ぼう! • Androidバージョン違いで起きるバグを事前に検証しよう! • DIコンテナで(dagger)で無理やり依存関係を作ってい る. • なるべく疎になるようにしよう. • MVVMの限界を感じた
80.
MVVMの限界問題 • SnackBarやToast(下からポップアップで出るような通 知バー)は,本来viewmodelで作るべきだがこれらを作 るのにviewが必要. • callback的にやることで解決. ←設計のバイブル本でも むずいと言ってるので多分むずい
81.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
82.
Agenda • SyncPodについて • 改修の理由 •
様々なアーキテクチャの紹介 • 使用技術 • 構成について • 良かった点 • 悪かった点 • 最後に
83.
最後に
84.
最後に • いろんな事を考え成功・失敗したが大事なことはエン ジニア・プランナー・利用者のことを考えて設計する こと. • 無理に高尚なアーキテクチャを使ったからといっていい結果 になるとは限らない.
85.
最後に • いろんな事を考え成功・失敗したが大事なことはエン ジニア・プランナー・利用者のことを考えて設計する こと. • 無理に高尚なアーキテクチャを使ったからといっていい結果 になるとは限らない. •
ここで改善点を生かしてiOSを絶賛リファクタ中.
86.
最後に • いろんな事を考え成功・失敗したが大事なことはエン ジニア・プランナー・利用者のことを考えて設計する こと. • 無理に高尚なアーキテクチャを使ったからといっていい結果 になるとは限らない. •
ここで改善点を生かしてiOSを絶賛リファクタ中. • 開発にも活かせることをたくさん学んだ.
87.
最後に • いろんな事を考え成功・失敗したが大事なことはエン ジニア・プランナー・利用者のことを考えて設計する こと. • 無理に高尚なアーキテクチャを使ったからといっていい結果 になるとは限らない. •
ここで改善点を生かしてiOSを絶賛リファクタ中. • 開発にも活かせることをたくさん学んだ. • でも何より,動いているコードは偉い.リスペクトを.
88.
昨日 • 類似アプリが見つかって絶望してた
89.
ネイティブでの設計の知見を生かして インターンもまだまだがんばります! おわり
Download now