Submit Search
Upload
iOSやAndroidアプリ開発のGoodPractice
•
62 likes
•
12,441 views
Ken Morishita
Follow
iOS/Androidアプリ開発のGoodPracticeのようなものです。
Read less
Read more
Technology
Report
Share
Report
Share
1 of 46
Download now
Download to read offline
Recommended
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
IOS/Androidアプリの3つの大事な設計方針
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
Ken Morishita
失敗から学ぶAndroid設計話
失敗から学ぶAndroid設計話
chigichan24
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
MVC の Model を考える
MVC の Model を考える
tomo_masakura
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
ドキュメントを作りたくなってしまう魔法のツールSphinx
ドキュメントを作りたくなってしまう魔法のツールSphinx
Takayuki Shimizukawa
Recommended
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
IOS/Androidアプリの3つの大事な設計方針
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
Ken Morishita
失敗から学ぶAndroid設計話
失敗から学ぶAndroid設計話
chigichan24
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
MVC の Model を考える
MVC の Model を考える
tomo_masakura
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
ドキュメントを作りたくなってしまう魔法のツールSphinx
ドキュメントを作りたくなってしまう魔法のツールSphinx
Takayuki Shimizukawa
継承やめろマジやめろ。 なぜイケないのか 解説する
継承やめろマジやめろ。 なぜイケないのか 解説する
TaishiYamada1
Unityでパフォーマンスの良いUIを作る為のTips
Unityでパフォーマンスの良いUIを作る為のTips
Unity Technologies Japan K.K.
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入.pdf
信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入.pdf
株式会社MonotaRO Tech Team
JenkinsとDockerって何が良いの? 〜言うてるオレもわからんわ〜 #jenkinsstudy
JenkinsとDockerって何が良いの? 〜言うてるオレもわからんわ〜 #jenkinsstudy
Kazuhito Miura
Androidの新ビルドシステム
Androidの新ビルドシステム
l_b__
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
alwei
Iocコンテナについて
Iocコンテナについて
Akio Terayama
20分くらいでわかった気分になれるC++20コルーチン
20分くらいでわかった気分になれるC++20コルーチン
yohhoy
サポートスペシャリストが語るXenDesktop / XenApp環境での最速トラブルシューティング
サポートスペシャリストが語るXenDesktop / XenApp環境での最速トラブルシューティング
Citrix Systems Japan
知らないと損するアプリ開発におけるStateMachineの活用法(15分版)
知らないと損するアプリ開発におけるStateMachineの活用法(15分版)
Ken Morishita
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
Unity In App Purchase (IAP)の使い方
Unity In App Purchase (IAP)の使い方
Makoto Ito
Java開発の強力な相棒として今すぐ使えるGroovy
Java開発の強力な相棒として今すぐ使えるGroovy
Yasuharu Nakano
ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用
ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用
Sugimoto Chizuru
世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン
Atsushi Nakamura
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
Riverpodでテストを書こう
Riverpodでテストを書こう
Shinnosuke Tokuda
テストを書こう、Unity編
テストを書こう、Unity編
Hiroto Imoto
OpenRTM-aist入門
OpenRTM-aist入門
Yuki Suga
Model View Presenter for Android
Model View Presenter for Android
shinnosuke kugimiya
さらに上を目指すための iOS アプリ設計
さらに上を目指すための iOS アプリ設計
Taketo Sano
More Related Content
What's hot
継承やめろマジやめろ。 なぜイケないのか 解説する
継承やめろマジやめろ。 なぜイケないのか 解説する
TaishiYamada1
Unityでパフォーマンスの良いUIを作る為のTips
Unityでパフォーマンスの良いUIを作る為のTips
Unity Technologies Japan K.K.
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入.pdf
信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入.pdf
株式会社MonotaRO Tech Team
JenkinsとDockerって何が良いの? 〜言うてるオレもわからんわ〜 #jenkinsstudy
JenkinsとDockerって何が良いの? 〜言うてるオレもわからんわ〜 #jenkinsstudy
Kazuhito Miura
Androidの新ビルドシステム
Androidの新ビルドシステム
l_b__
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
alwei
Iocコンテナについて
Iocコンテナについて
Akio Terayama
20分くらいでわかった気分になれるC++20コルーチン
20分くらいでわかった気分になれるC++20コルーチン
yohhoy
サポートスペシャリストが語るXenDesktop / XenApp環境での最速トラブルシューティング
サポートスペシャリストが語るXenDesktop / XenApp環境での最速トラブルシューティング
Citrix Systems Japan
知らないと損するアプリ開発におけるStateMachineの活用法(15分版)
知らないと損するアプリ開発におけるStateMachineの活用法(15分版)
Ken Morishita
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
Unity In App Purchase (IAP)の使い方
Unity In App Purchase (IAP)の使い方
Makoto Ito
Java開発の強力な相棒として今すぐ使えるGroovy
Java開発の強力な相棒として今すぐ使えるGroovy
Yasuharu Nakano
ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用
ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用
Sugimoto Chizuru
世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン
Atsushi Nakamura
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
Riverpodでテストを書こう
Riverpodでテストを書こう
Shinnosuke Tokuda
テストを書こう、Unity編
テストを書こう、Unity編
Hiroto Imoto
OpenRTM-aist入門
OpenRTM-aist入門
Yuki Suga
What's hot
(20)
継承やめろマジやめろ。 なぜイケないのか 解説する
継承やめろマジやめろ。 なぜイケないのか 解説する
Unityでパフォーマンスの良いUIを作る為のTips
Unityでパフォーマンスの良いUIを作る為のTips
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入.pdf
信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入.pdf
JenkinsとDockerって何が良いの? 〜言うてるオレもわからんわ〜 #jenkinsstudy
JenkinsとDockerって何が良いの? 〜言うてるオレもわからんわ〜 #jenkinsstudy
Androidの新ビルドシステム
Androidの新ビルドシステム
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
Iocコンテナについて
Iocコンテナについて
20分くらいでわかった気分になれるC++20コルーチン
20分くらいでわかった気分になれるC++20コルーチン
サポートスペシャリストが語るXenDesktop / XenApp環境での最速トラブルシューティング
サポートスペシャリストが語るXenDesktop / XenApp環境での最速トラブルシューティング
知らないと損するアプリ開発におけるStateMachineの活用法(15分版)
知らないと損するアプリ開発におけるStateMachineの活用法(15分版)
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Unity In App Purchase (IAP)の使い方
Unity In App Purchase (IAP)の使い方
Java開発の強力な相棒として今すぐ使えるGroovy
Java開発の強力な相棒として今すぐ使えるGroovy
ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用
ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用
世界一わかりやすいClean Architecture - DroidKaigiバージョン
世界一わかりやすいClean Architecture - DroidKaigiバージョン
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
Riverpodでテストを書こう
Riverpodでテストを書こう
テストを書こう、Unity編
テストを書こう、Unity編
OpenRTM-aist入門
OpenRTM-aist入門
Viewers also liked
Model View Presenter for Android
Model View Presenter for Android
shinnosuke kugimiya
さらに上を目指すための iOS アプリ設計
さらに上を目指すための iOS アプリ設計
Taketo Sano
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
U-dai Yokoyama
BigQuery勉強会 Standard SQL Dialect
BigQuery勉強会 Standard SQL Dialect
Ken Morishita
Docker勉強会2017 実践編 スライド
Docker勉強会2017 実践編 スライド
Shiojiri Ohhara
Fighting history of CGFloat in Swift
Fighting history of CGFloat in Swift
Hirohito Kato
A4でまとめるClean architecture概要
A4でまとめるClean architecture概要
Hirohito Kato
プログラミングで言いたい聞きたいこと集
プログラミングで言いたい聞きたいこと集
tecopark
Visual studioとそのライバル
Visual studioとそのライバル
Tadahiro Ishisaka
Digitization-software is eating the world
Digitization-software is eating the world
Kenji Hiranabe
160625 cloud samurai_adds_migration_160625
160625 cloud samurai_adds_migration_160625
wintechq
Rdra in 東京
Rdra in 東京
Zenji Kanzaki
デザイン・制作をはじめる前に 取り組む事
デザイン・制作をはじめる前に 取り組む事
kenji goto
HTML5 Conference 2013 HybridCast
HTML5 Conference 2013 HybridCast
Satoshi Shoda
メガネ型デバイスの未来について考える
メガネ型デバイスの未来について考える
Sho Okada
新規ビジネスデザイン研修 DYA2 テキスト<サンプル版>
新規ビジネスデザイン研修 DYA2 テキスト<サンプル版>
Satoru Itabashi
Jenkins実践入門 第二版 What's New
Jenkins実践入門 第二版 What's New
Masanori Satoh
開発者の方向けの Sql server(db) t sql 振り返り
開発者の方向けの Sql server(db) t sql 振り返り
Oda Shinsuke
KPTAふりかえり体験研修のご紹介
KPTAふりかえり体験研修のご紹介
ESM SEC
Rdra4越境アジャイル
Rdra4越境アジャイル
Zenji Kanzaki
Viewers also liked
(20)
Model View Presenter for Android
Model View Presenter for Android
さらに上を目指すための iOS アプリ設計
さらに上を目指すための iOS アプリ設計
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
MVPパターンによる設計アプローチ「あなたのアプリ報連相できてますか」
BigQuery勉強会 Standard SQL Dialect
BigQuery勉強会 Standard SQL Dialect
Docker勉強会2017 実践編 スライド
Docker勉強会2017 実践編 スライド
Fighting history of CGFloat in Swift
Fighting history of CGFloat in Swift
A4でまとめるClean architecture概要
A4でまとめるClean architecture概要
プログラミングで言いたい聞きたいこと集
プログラミングで言いたい聞きたいこと集
Visual studioとそのライバル
Visual studioとそのライバル
Digitization-software is eating the world
Digitization-software is eating the world
160625 cloud samurai_adds_migration_160625
160625 cloud samurai_adds_migration_160625
Rdra in 東京
Rdra in 東京
デザイン・制作をはじめる前に 取り組む事
デザイン・制作をはじめる前に 取り組む事
HTML5 Conference 2013 HybridCast
HTML5 Conference 2013 HybridCast
メガネ型デバイスの未来について考える
メガネ型デバイスの未来について考える
新規ビジネスデザイン研修 DYA2 テキスト<サンプル版>
新規ビジネスデザイン研修 DYA2 テキスト<サンプル版>
Jenkins実践入門 第二版 What's New
Jenkins実践入門 第二版 What's New
開発者の方向けの Sql server(db) t sql 振り返り
開発者の方向けの Sql server(db) t sql 振り返り
KPTAふりかえり体験研修のご紹介
KPTAふりかえり体験研修のご紹介
Rdra4越境アジャイル
Rdra4越境アジャイル
Similar to iOSやAndroidアプリ開発のGoodPractice
Intalio japan special cloud workshop
Intalio japan special cloud workshop
Daisuke Sugai
2012 05-19第44回cocoa勉強会発表資料
2012 05-19第44回cocoa勉強会発表資料
OCHI Shuji
MVVM入門
MVVM入門
Kazutoshi Urabe
今から始める、Windows 10&新.NETへの移行戦略
今から始める、Windows 10&新.NETへの移行戦略
信之 岩永
Ignite UI 2012 最新情報 jQuery Mobile 編
Ignite UI 2012 最新情報 jQuery Mobile 編
インフラジスティックス・ジャパン株式会社
OpenSpan_PreMarketing
OpenSpan_PreMarketing
motani_kamakura
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
Daisuke Nishino
20130316 mix cpp-yuo
20130316 mix cpp-yuo
OKUBO_Yusuke
New Integration "X" 新インテグレーションソリューション
New Integration "X" 新インテグレーションソリューション
motani_kamakura
Angularreflex20141210
Angularreflex20141210
Shinichiro Takezaki
中規模Androidアプリ開発の過程に生じた問題と対策の紹介
中規模Androidアプリ開発の過程に生じた問題と対策の紹介
NilOne Ltd.
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Daizen Ikehara
Force.com開発基礎
Force.com開発基礎
Salesforce Developers Japan
デブサミ2013【15-D-4】Opsから挑むDevOps
デブサミ2013【15-D-4】Opsから挑むDevOps
Developers Summit
2011年マイクロソフト テクノロジー振り返り~開発編~
2011年マイクロソフト テクノロジー振り返り~開発編~
Takeshi Shinmura
DSL駆動によるクラウド・アプリケーション開発
DSL駆動によるクラウド・アプリケーション開発
Tomoharu ASAMI
Scalable Generator: Using Scala in SIer Business (ScalaMatsuri)
Scalable Generator: Using Scala in SIer Business (ScalaMatsuri)
TIS Inc.
設計/コンポーネント設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第22回】
設計/コンポーネント設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第22回】
Tomoharu ASAMI
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
Yusuke Suzuki
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Ken Azuma
Similar to iOSやAndroidアプリ開発のGoodPractice
(20)
Intalio japan special cloud workshop
Intalio japan special cloud workshop
2012 05-19第44回cocoa勉強会発表資料
2012 05-19第44回cocoa勉強会発表資料
MVVM入門
MVVM入門
今から始める、Windows 10&新.NETへの移行戦略
今から始める、Windows 10&新.NETへの移行戦略
Ignite UI 2012 最新情報 jQuery Mobile 編
Ignite UI 2012 最新情報 jQuery Mobile 編
OpenSpan_PreMarketing
OpenSpan_PreMarketing
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
20130316 mix cpp-yuo
20130316 mix cpp-yuo
New Integration "X" 新インテグレーションソリューション
New Integration "X" 新インテグレーションソリューション
Angularreflex20141210
Angularreflex20141210
中規模Androidアプリ開発の過程に生じた問題と対策の紹介
中規模Androidアプリ開発の過程に生じた問題と対策の紹介
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Force.com開発基礎
Force.com開発基礎
デブサミ2013【15-D-4】Opsから挑むDevOps
デブサミ2013【15-D-4】Opsから挑むDevOps
2011年マイクロソフト テクノロジー振り返り~開発編~
2011年マイクロソフト テクノロジー振り返り~開発編~
DSL駆動によるクラウド・アプリケーション開発
DSL駆動によるクラウド・アプリケーション開発
Scalable Generator: Using Scala in SIer Business (ScalaMatsuri)
Scalable Generator: Using Scala in SIer Business (ScalaMatsuri)
設計/コンポーネント設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第22回】
設計/コンポーネント設計(3) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第22回】
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Recently uploaded
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
sn679259
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
WSO2
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Hiroshi Tomioka
Recently uploaded
(12)
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
iOSやAndroidアプリ開発のGoodPractice
1.
iOS/Androidアプリ開発の Good Practice 2015年7月 ゆめみ 森下 1
2.
はじめに • ゆめみ内でのiOS/Androidアプリ開発におけるPractice(実践・慣習)を まとめたものです • 書きかけなので随時更新していきます 2
3.
用語の整理 基本的な単語や、ゆめみ内で使う特殊な単語の定義もあるので整理しておきます 3
4.
プラットフォーム別の用語とこの資料の表記 iOSのclass, protocol Androidのclass,
interface この資料の表記 AppDelegate/UIApplication Application Application -‐ Activity Activity UIViewController Fragment ViewController (略してVC) NSUserDefaults Preference Preference 4
5.
同期/非同期 な呼び出し-‐リターン • 「同期的な呼び出し-‐リターン」 •
呼び出し終了時に戻り値が戻ってくるタイプ • 構造上同期的であることが強制されている • 「非同期的な呼び出し-‐リターン/通知」 • callbackや通知などで制御が戻ってくるタイプ • その制御がいつ戻ってくるかは実はわからない • 呼び出し終了前に呼ばれるケースも有り得ることには注意 5
6.
非同期の「Callback的」「通知的」 の違い 6
7.
非同期の「Callback的」「通知的」 の違い 7
8.
非同期の「Callback的」「通知的」 の違い • 「通知的」な方には、
add/remove というような 明示的な通知の「受け取り開始」「受け取り解除」がある • 「callback的」な方では、「解除」は難しい • ライフサイクルが短いInstanceは「通知」を使うのが基本になる • そうしないと、自分が無効な状態なのにcallbackを受け取ってしまう • 例) Fragment-‐>Model, ViewController-‐>Model • ライフサイクルが必ず長いInstanceはCallbackでもOK • 例) Model -‐> API, Service -‐> API, Model -‐> Data系 8
9.
必須Practice 9
10.
必須Practice • Gitによるバージョン管理 • Crashレポートツールの導入 •
Debug/Release や 環境別のビルドの切換をコードを書き換えないで 行うこと 10
11.
Gitによるバージョン管理 • ソースコードのバージョン管理にはGitを使っています • ブランチの切りやすさや、大規模でも高速である、など利点が大きい •
基本ルール • 少なくともリリースしたプロダクトは過去の任意のバージョンを再現可能なこと • 自動生成されるものはCommitしない • .gitignore をちゃんと設定する • *.class や ビルドされたバイナリ等 • ビルドに必要な画像はOK、動画は・・・仕方ないときもある • Androidだと R.java などもコミット不要 • Git-‐Flow的なブランチ運用にする • master: リリースしたソースコードのブランチ (リリースしたらTAGを打つこと) • develop: 次期リリースするソースコードが合流するブランチ • feature/*: 特定の機能開発ブランチ。コミット単位でなるべく意味を持たせること。 11
12.
Crashレポートツールの導入 • リリース後の不具合を早急に発見するために必ず導入しましょう • ゆめみでは
Crashlytics を標準的に使っています • https://try.crashlytics.com/ 12
13.
Debug/Release や 環境別のビルドの切換を コードを書き換えないで行うこと •
例えば、通信先host名, API Key, Log出力などの切換です ■標準的な実現方法 • Android • Gradle+BuildConfig+(環境変数) • iOS • #ifdef DEBUG + #defineなどのプリプロセッサ+定数定義 • 場合によっては、 *.h ファイルの動的な生成 13
14.
推奨Practice 14
15.
推奨Practice • 内部の基本アーキテクチャはMVPパターンに近いものにする • アプリケーションのアーキテクチャは徐々に発展させていく •
理想の開発に占める労力の割合は「View 80%」「その他 20%」 • 定数は「環境情報」「Configuration情報」「内部定数」に分ける 15
16.
ViewController 内部の基本アーキテクチャはMVPパターン Application Activity View View Entity Model Container (for DI) APIPreference ViewController Model DB/NoSQL プレゼンテーション層 ビジネス層 データ層 PresenterVCとPresenterはわ けない場合もある StateMachine StateMachine 通知的IF File/Cache set 複数のVCに跨る時がある 各種Container (for
DI) 16
17.
MVPパターン? • MVCパターンみたいなものだけど、ViewがModelを直接参照しない で、PresenterがModelの値をViewにセットする(ようなイメージ) • http://tech.recruit-‐mp.co.jp/mobile/android-‐architecture/ •
普通はViewがModelを直接参照しないので、この形式といえばこの 形式になっているはず • 大事なこと • 「Model」が存在すること • 「ViewController」は肥大化するので、Presenterの機能を分離する設計があ るということを知っておくこと 17
18.
MVPパターン、と言っても全体構成としては 色々あります http://tech.recruit-‐mp.co.jp/mobile/android-‐architecture/ より 18
19.
Modelってなんだ? • とりあえずこれを読んでみて欲しい • 「iOS/Androidアプリエンジニアが理解すべきModelの振る舞い」 •
http://www.slideshare.net/mokemokechicken/iosandroidmodel • 「プレゼンテーション層」から見れば、 • データのCRUDや処理を依頼できる「サーバ」みたいなレイヤー • 非同期のリターンは「通知」でもらう • Modelは非常に長命でContainerのようなDI機能からもらうイメージ • データや状態は公開されているが、カプセル化・抽象化されている • 安全な操作、状態の矛盾を防げるようにする 19※実際の名前はどうでも良い
20.
具体例 • Presentation層のAPI callback実装
→ Model通知実装 への書き換え • Android • https://github.com/mokemokechicken/android_refactor_training/blob/master/doc/exa mple_1.md 20
21.
アプリケーションのアーキテク チャは徐々に発展させていく 21
22.
アプリケーションのアーキテクチャは徐々に 発展させていく • アプリ開発においては次のようなライフサイクルを持つことが多い • 最初はViewだけのMockを作る •
次第に通信部分と連携するようになる • 徐々に仕様変更(View遷移、通信周り、キャッシュ周り)や微調整を行う 22
23.
最初はViewだけのMockを作る ViewController Application Activity View ViewViewControllerプレゼンテーション層 +(ダミーデータ) +(なんちゃってロジック) この時は、ビジネス層なんて要らない コアな画面を1つ2つちゃんと作って、 他はパワポの画像を貼っておく、とかで良い 標準パーツとか使わない方が 完成品とのイメージの差がなくてむしろ良い 機能ではなく、見た目のゴールを再現する 空いた時間でアーキテクチャの基本を試行錯誤しておく アーキテクチャのプロトタイプを内部で考える 23
24.
次第に通信部分と連携するようになる ViewController Application Activity View ViewViewControllerプレゼンテーション層 +(ダミーデータ) +(なんちゃってロジック) API通信機能 データ共有機能 データ操作機能 このまま拡張してはダメ、絶対。 ここで建て付けは整理すること。 ☓ ☓ ☓ ビジネスロジック☓ が、ここで注意 24
25.
次第に通信部分と連携するようになる ViewController Application Activity View View Entity Model Container (for DI) API ViewController Model プレゼンテーション層 ビジネス層 データ層 通知的IF +(なんちゃってロジック) API通信機能 データ共有・操作機能 +(ダミーデータ) VCをなるべく軽くする ダミーなどは残ることもある 機能単位にModelを作る set ビジネスロジック 25
26.
徐々に仕様変更や微調整を行う • 最初に(自分たちが)描いた図に近づいていくことになる • 「全部盛り」になったときのクラス構成をイメージして、開発者同士が共有 しておく •
そうすれば「もうここは次の設計ステージに移行した方がいいね」と一言で通じる • そうでないとなかなか議論がまとまらない • この辺りからReviewしたコードのみMerge OK、などのルールにすると良い かもしれない • 最初からそうでも良いですが • 人員に余裕がないと辛いですが 26
27.
理想の開発に占める労力の割合 27
28.
ViewController 理想の開発に占める労力の割合 Application Activity View View Entity Model Container (for DI) APIPreference ViewController Model DB/NoSQL プレゼンテーション層 ビジネス層 データ層 PresenterVCとPresenterはわ けない場合もある StateMachine StateMachine 通知的IF File/Cache set 80% 20% アピールポイント パターン化が難しい よく変更がある 自動化やパターン化容易 決まれば変更は少ない 28
29.
• 危険信号 • 簡単な遷移やUIの変更が難しい •
WiFiだと快適に動くのに3G回線だとすぐ固まる、落ちる • 画面がちらちらする。レイアウトが乱れている • よくある原因 • 画面ベースで開発しているため、画面の遷移や構成要素が変わると対応できない • 開発時はWifiで無計画に作っているので、非同期の問題に気がつかない • 要件や仕様を最低限満たすことに集中していて画面を見ていない。システム都合 で画面がおまけになっている • 解決する3つの手順 • 通信と表示制御を分離して整理する • これによりシステム都合で画面が制限されることが少なくなる • 画面単位でファイルを作るのではなく、機能単位になるように切り口を変え、パーツ に分解する • 隠れフラグ(static変数類、ローカルストレージ、ViewのIDや状態)を排除して、状態 管理をまとめる 29
30.
定数の管理 30
31.
定数は「環境情報」「Configuration情報」「内 部定数」に分ける • 環境情報: デプロイ先などで変わる値 •
dev1, staging1, staging2…, production などの環境 • 通信先URLなどのEndpoint • ID/PASS, SNSや外部サービスのAPI-‐Key • 署名の鍵 • Configuration情報: Release/Debugなどで変わる値 • Log Levelなどの値 • Debug機能のOn/Offなど • 内部の定数: 単純に内部で使っている定数 31
32.
環境情報 • 環境情報はビルドやデプロイのタイミングで注入できるのがベスト • 事前に数種類(dev用,
内部staging用, staging用, production用)定義してお いて、ビルド時に選択できるというのでも良い • Android • Gradle+ buildConfigField (+ 環境変数)などが便利 • iOS • config_dev.h, config_production.h などを事前に定義して、ifdefでimportを分ける • もしくは、 ビルド時に動的に.hを生成する 32
33.
Configuration情報 • 下記のような仕組みをまとめられるようなものを準備する • Android •
例えば、BuildConfig.DEBUGによって異なる値が返るような何かを作る • iOS • 例えば、#ifdef DEBUG などで異なる値が定義・returnされる何かを作る 33
34.
内部定数 • Android • static
public final で定数にするか、 getterで提供する • iOS • #define などで定義する 34
35.
具体例 • 環境情報・Configuration情報の書き方 • Android:
https://github.com/mokemokechicken/android_refactor_training/blob/maste r/doc/example_2.md 35
36.
実装が難しいので注意する点 36
37.
アプリケーションの起動時の処理 37 アプリの起動シーケンスは複雑になりやすい。 「初回起動時(ID取得・PushToken取得)」「2回目起動時」 「Homeから復帰」「Push通知やIntent/URL Schemaからの起動」 での分岐や、 初期データを入力しているか(誕生日とか)どうかで画面を分岐 データがDLされているか分岐 などがあり得る。 これらが非同期での処理になるので、実装が少しむずかしい。 → StateMachineを使うとかなり改善する →
気合で実装することもあるが、このロジックをActivityに持たせない方が良い
38.
ViewControllerの状態は複雑になりやすい 38 一つの画面(ViewController/Presenter)で 多数の非同期イベント(通信、UIイベント、Observeイベント)を制御するので。 → これもStateMachineを使うと簡潔になる
39.
アンチパターン よく見かけるものたち・・・ 39
40.
「Application/Activity/Fragment」や「AppDelegate/ViewController」に 他のObjectから参照されるような値・状態を持っている。 • static publicな何かになることが多い •
ViewControllerをsingletonにしてしまう人もいる ■ アンチパターン: 「いつも便利Global変数」 ■ 問題点 ■ 解決方法 何がいつ更新するかが発散していくので、保守性が著しく下がる。 厳密な状態管理が難しいので、不整合が起こりやすい。 ViewControllerはsingletonにしてはいけない! 「Model」を作る Viewの状態を共有したいなら、状態を「Presenter」に管理させ、Presenterを共有させる 40
41.
Application, BaseActivity, BaseViewControllerがどんどん多機能になっていく。 通信機能やデータ保存機能などが実装されている。 ■
アンチパターン: 「万能Baseクラス」「Frameworkクラス肥大化」 ■ 問題点 ■ 解決方法 ActivityやViewControllerは、そういう役割を持つべきではない。 通信機能を利用するために、 他のObjectから ViewControllerの参照が欲しくなり、 依存関係が破綻していく 余分な機能をApplicationやVCに持たせない。 他のレイヤーのClass(Model, API, DB)に実装する。 41
42.
1Methodが200行を超える。 (2000行を超えるものを見たことがある・・・) ■ アンチパターン: 「大作書きおろしメソッド」 ■
問題点 ■ 解決方法 非常に可読性や保守性が下がる。 単体テストをまず書くことができない。 設計を見なおして、分割する。 42
43.
同じ switch (mode/type/state)
{ case ... } が至る所にできる ■ アンチパターン: 「増殖switch」 ■ 問題点 ■ 解決方法 可読性、保守性がすごい速度で下がっていく。 mode/type/stateの追加・変更が難しい。 全てを把握しないとコードが読めなくなる。 「いつも便利Global変数」と合わさると絶大な破壊力になる。 modeやtypeなら: Object指向的な解法 stateなら: StateMachineの導入 43
44.
Activityがたくさんある Activityが消えることを考慮していない ■ Androidアンチパターン ■ 問題点 ■
解決方法 不具合が起こりやすい。 画面のViewはFragmentで管理する。(画面毎にActivityを作らない)。 端末のDeveloper Modeで Homeボタンを押したら Activityが必ず消えるOptionをOnに設定して開発する。 44
45.
他:警告・チェックポイント 45
46.
警告・チェックポイント • Viewの状態で、Presenterなどの処理がわかれている • If
(view.isEnable()) とか… • ViewController, Presenter から直接APIやPreferenceを参照している • 設計思想に反している • GAタグなどで(遷移元、遷移先)を記録するのは大変である • 仕様を調整してもらって、GAタグ(表示画面) にしてもらうのが吉 • そうでない場合は、かなり大きくその工数を見積もる必要がある ※良い方法があると良いですが 46
Download now