Suche senden
Hochladen
さらに上を目指すための iOS アプリ設計
•
238 gefällt mir
•
30,947 views
Taketo Sano
Folgen
2015/05/13 ヤフー社内「中級 iOS アプリ開発者」向けに行った講義の資料。
Weniger lesen
Mehr lesen
Software
Melden
Teilen
Melden
Teilen
1 von 51
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
IOS/Androidアプリの3つの大事な設計方針
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計
Yuichi Adachi
Kakao agile 2nd story
Kakao agile 2nd story
호정 이
効果が出る「仕事の教え方」
効果が出る「仕事の教え方」
Mariko Hayashi
GitHub ActionsでiOSのCIを実現しよう
GitHub ActionsでiOSのCIを実現しよう
Shinya Nakajima
5分でわかる Unity点群
5分でわかる Unity点群
UnityTechnologiesJapan002
애자일 S/W 개발
애자일 S/W 개발
영기 김
Empfohlen
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
IOS/Androidアプリの3つの大事な設計方針
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計
Yuichi Adachi
Kakao agile 2nd story
Kakao agile 2nd story
호정 이
効果が出る「仕事の教え方」
効果が出る「仕事の教え方」
Mariko Hayashi
GitHub ActionsでiOSのCIを実現しよう
GitHub ActionsでiOSのCIを実現しよう
Shinya Nakajima
5分でわかる Unity点群
5分でわかる Unity点群
UnityTechnologiesJapan002
애자일 S/W 개발
애자일 S/W 개발
영기 김
iOSでMVVM入門
iOSでMVVM入門
ishikawa akira
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入
ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入
keysh2
slackに箇条書きにしたタスクを、Notionに登録してくれるbotを作った話
slackに箇条書きにしたタスクを、Notionに登録してくれるbotを作った話
ssuserfb543d1
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)
masanori kataoka
これで怖くない!?コードリーディングで学ぶSpring Security #中央線Meetup
これで怖くない!?コードリーディングで学ぶSpring Security #中央線Meetup
Masatoshi Tada
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
Hironori Washizaki
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
Shinya Nakajima
SQLアンチパターン - ジェイウォーク
SQLアンチパターン - ジェイウォーク
ke-m kamekoopa
20221116_テスト自動化プラットフォーム mabl はいいぞ!
20221116_テスト自動化プラットフォーム mabl はいいぞ!
Shohei Oda
B07_業務の自動化を多角的に実現する Power Automate の世界 [Microsoft Japan Digital Days]
B07_業務の自動化を多角的に実現する Power Automate の世界 [Microsoft Japan Digital Days]
日本マイクロソフト株式会社
[Gpg2권 박민근] 3.2 게임 객체 ai를 위한 마이크로 스레드
[Gpg2권 박민근] 3.2 게임 객체 ai를 위한 마이크로 스레드
MinGeun Park
덤프 파일을 통한 사후 디버깅 실용 테크닉 NDC2012
덤프 파일을 통한 사후 디버깅 실용 테크닉 NDC2012
Esun Kim
Objective-C のキャストと Swift の型変換を比べてみる #akibaswift
Objective-C のキャストと Swift の型変換を比べてみる #akibaswift
Tomohiro Kumagai
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
C# コーディングガイドライン 2013/02/26
C# コーディングガイドライン 2013/02/26
Yoshihisa Ozaki
MicrometerとPrometheusによる LINEファミリーアプリのモニタリング
MicrometerとPrometheusによる LINEファミリーアプリのモニタリング
LINE Corporation
TDD のこころ
TDD のこころ
Takuto Wada
2015/11/15 Javaでwebアプリケーション入門
2015/11/15 Javaでwebアプリケーション入門
Asami Abe
iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方
kakegawa-atsushi
BaseViewControllerは作りたくない
BaseViewControllerは作りたくない
今城 善矩
Weitere ähnliche Inhalte
Was ist angesagt?
iOSでMVVM入門
iOSでMVVM入門
ishikawa akira
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入
ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入
keysh2
slackに箇条書きにしたタスクを、Notionに登録してくれるbotを作った話
slackに箇条書きにしたタスクを、Notionに登録してくれるbotを作った話
ssuserfb543d1
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)
masanori kataoka
これで怖くない!?コードリーディングで学ぶSpring Security #中央線Meetup
これで怖くない!?コードリーディングで学ぶSpring Security #中央線Meetup
Masatoshi Tada
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
Hironori Washizaki
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
Shinya Nakajima
SQLアンチパターン - ジェイウォーク
SQLアンチパターン - ジェイウォーク
ke-m kamekoopa
20221116_テスト自動化プラットフォーム mabl はいいぞ!
20221116_テスト自動化プラットフォーム mabl はいいぞ!
Shohei Oda
B07_業務の自動化を多角的に実現する Power Automate の世界 [Microsoft Japan Digital Days]
B07_業務の自動化を多角的に実現する Power Automate の世界 [Microsoft Japan Digital Days]
日本マイクロソフト株式会社
[Gpg2권 박민근] 3.2 게임 객체 ai를 위한 마이크로 스레드
[Gpg2권 박민근] 3.2 게임 객체 ai를 위한 마이크로 스레드
MinGeun Park
덤프 파일을 통한 사후 디버깅 실용 테크닉 NDC2012
덤프 파일을 통한 사후 디버깅 실용 테크닉 NDC2012
Esun Kim
Objective-C のキャストと Swift の型変換を比べてみる #akibaswift
Objective-C のキャストと Swift の型変換を比べてみる #akibaswift
Tomohiro Kumagai
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
C# コーディングガイドライン 2013/02/26
C# コーディングガイドライン 2013/02/26
Yoshihisa Ozaki
MicrometerとPrometheusによる LINEファミリーアプリのモニタリング
MicrometerとPrometheusによる LINEファミリーアプリのモニタリング
LINE Corporation
TDD のこころ
TDD のこころ
Takuto Wada
2015/11/15 Javaでwebアプリケーション入門
2015/11/15 Javaでwebアプリケーション入門
Asami Abe
Was ist angesagt?
(20)
iOSでMVVM入門
iOSでMVVM入門
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入
ぼんやりした要件とテストケースから出てくる地獄のようなゲームテスト自動化導入
slackに箇条書きにしたタスクを、Notionに登録してくれるbotを作った話
slackに箇条書きにしたタスクを、Notionに登録してくれるbotを作った話
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)
これで怖くない!?コードリーディングで学ぶSpring Security #中央線Meetup
これで怖くない!?コードリーディングで学ぶSpring Security #中央線Meetup
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
SQLアンチパターン - ジェイウォーク
SQLアンチパターン - ジェイウォーク
20221116_テスト自動化プラットフォーム mabl はいいぞ!
20221116_テスト自動化プラットフォーム mabl はいいぞ!
B07_業務の自動化を多角的に実現する Power Automate の世界 [Microsoft Japan Digital Days]
B07_業務の自動化を多角的に実現する Power Automate の世界 [Microsoft Japan Digital Days]
[Gpg2권 박민근] 3.2 게임 객체 ai를 위한 마이크로 스레드
[Gpg2권 박민근] 3.2 게임 객체 ai를 위한 마이크로 스레드
덤프 파일을 통한 사후 디버깅 실용 테크닉 NDC2012
덤프 파일을 통한 사후 디버깅 실용 테크닉 NDC2012
Objective-C のキャストと Swift の型変換を比べてみる #akibaswift
Objective-C のキャストと Swift の型変換を比べてみる #akibaswift
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
C# コーディングガイドライン 2013/02/26
C# コーディングガイドライン 2013/02/26
MicrometerとPrometheusによる LINEファミリーアプリのモニタリング
MicrometerとPrometheusによる LINEファミリーアプリのモニタリング
TDD のこころ
TDD のこころ
2015/11/15 Javaでwebアプリケーション入門
2015/11/15 Javaでwebアプリケーション入門
Andere mochten auch
iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方
kakegawa-atsushi
BaseViewControllerは作りたくない
BaseViewControllerは作りたくない
今城 善矩
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
Taketo Sano
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
Ken Morishita
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Masaru Gushiken
プログラマのための線形代数再入門
プログラマのための線形代数再入門
Taketo Sano
何もないところから数を作る
何もないところから数を作る
Taketo Sano
3 auto layout tips
3 auto layout tips
Tomoki Hasegawa
プロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswift
Tomohiro Kumagai
NS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバ
Tomohiro Kumagai
Swift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposium
Tomohiro Kumagai
AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話
Tomohiro Kumagai
objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望)
Taketo Sano
デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発
Kenta Ohsugi
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
Taketo Sano
基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先
Taketo Sano
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
Ken Morishita
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
Taketo Sano
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
Kenji Tanaka
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
Ken'ichi Matsui
Andere mochten auch
(20)
iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方
BaseViewControllerは作りたくない
BaseViewControllerは作りたくない
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
プログラマのための線形代数再入門
プログラマのための線形代数再入門
何もないところから数を作る
何もないところから数を作る
3 auto layout tips
3 auto layout tips
プロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswift
NS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバ
Swift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposium
AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話
objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望)
デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
Ähnlich wie さらに上を目指すための iOS アプリ設計
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
DevLOVE iPhoneアプリ勉強会
DevLOVE iPhoneアプリ勉強会
Toshimitsu Takahashi
e-Learning Design for Teacher
e-Learning Design for Teacher
Sunami Hokuto
Itca yammer提案110615
Itca yammer提案110615
伸夫 森本
チームで開発するための環境を整える
チームで開発するための環境を整える
onozaty
2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向
keki3
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣
loftwork
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort
loftwork
DSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイル
陽平 山口
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
131207 NECTJ Workshop 2
131207 NECTJ Workshop 2
NECTJ
タブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデア
Naoya Sangu
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
masashi takehara
iQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナー
Imamura Masayuki
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について
TomomitsuKusaba
Project Management
Project Management
Kazuto Omori
#MSIgnite x Japan Microsoft MVP/RD - Learning story
#MSIgnite x Japan Microsoft MVP/RD - Learning story
Rie Moriguchi
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
Webpla LLC.
社内 DDD 勉強会第1回
社内 DDD 勉強会第1回
shingo suzuki
2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料
TENTO_slide
Ähnlich wie さらに上を目指すための iOS アプリ設計
(20)
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
DevLOVE iPhoneアプリ勉強会
DevLOVE iPhoneアプリ勉強会
e-Learning Design for Teacher
e-Learning Design for Teacher
Itca yammer提案110615
Itca yammer提案110615
チームで開発するための環境を整える
チームで開発するための環境を整える
2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort
DSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイル
アジャイルマネジメントとは?
アジャイルマネジメントとは?
131207 NECTJ Workshop 2
131207 NECTJ Workshop 2
タブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデア
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
iQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナー
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について
Project Management
Project Management
#MSIgnite x Japan Microsoft MVP/RD - Learning story
#MSIgnite x Japan Microsoft MVP/RD - Learning story
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
社内 DDD 勉強会第1回
社内 DDD 勉強会第1回
2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料
Mehr von Taketo Sano
Divisibility of Lee’s class and its relation with Rasmussen’s invariant / 201...
Divisibility of Lee’s class and its relation with Rasmussen’s invariant / 201...
Taketo Sano
トポロジーと圏論の夜明け
トポロジーと圏論の夜明け
Taketo Sano
Swift で数学研究のススメ
Swift で数学研究のススメ
Taketo Sano
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
Taketo Sano
特性類の気持ち
特性類の気持ち
Taketo Sano
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Taketo Sano
山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門
Taketo Sano
何もないところから数を作る
何もないところから数を作る
Taketo Sano
情報幾何学 #2.4
情報幾何学 #2.4
Taketo Sano
情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16
Taketo Sano
objc2swift (自動変換の野望)
objc2swift (自動変換の野望)
Taketo Sano
2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertible
Taketo Sano
let UIWebView as WKWebView
let UIWebView as WKWebView
Taketo Sano
コードを書けば複素数がわかる
コードを書けば複素数がわかる
Taketo Sano
虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数
Taketo Sano
ひろ子 in Objective-C
ひろ子 in Objective-C
Taketo Sano
Objective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & Hack
Taketo Sano
Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作
Taketo Sano
下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズム
Taketo Sano
Mehr von Taketo Sano
(19)
Divisibility of Lee’s class and its relation with Rasmussen’s invariant / 201...
Divisibility of Lee’s class and its relation with Rasmussen’s invariant / 201...
トポロジーと圏論の夜明け
トポロジーと圏論の夜明け
Swift で数学研究のススメ
Swift で数学研究のススメ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
特性類の気持ち
特性類の気持ち
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門
何もないところから数を作る
何もないところから数を作る
情報幾何学 #2.4
情報幾何学 #2.4
情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16
objc2swift (自動変換の野望)
objc2swift (自動変換の野望)
2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertible
let UIWebView as WKWebView
let UIWebView as WKWebView
コードを書けば複素数がわかる
コードを書けば複素数がわかる
虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数
ひろ子 in Objective-C
ひろ子 in Objective-C
Objective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & Hack
Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作
下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズム
さらに上を目指すための iOS アプリ設計
1.
さらに上を目指すための iOS アプリ設計 @taketo1024
2.
(このスライドはヤフー社内で「中級者iOSアプリ開発者」向けに行った講義の資料です)
3.
本講座の目的 • iOSアプリ開発者がより高い視点からアプリの設計 を考えられるようになること。 • デザインパターンなどのお堅い話ではなく、「いい 設計」を感覚的に納得できるようにしたい。 •
「いい設計」を意識できるようになり、プロダクト の品質と開発スピードが上がれば嬉しいです。
4.
Agenda 1. アプリ開発における「いい設計」とは? 2. Storyboard
/ xib / コードの住み分け 3. delegate / callback / notification の使い分け 4. インターフェース ∼ 晒すものと隠すもの 5. 肥大化したクラスをスリム化する 6. 通信処理のカプセル化と使い捨て 7. 外部ライブラリの使用を判断するポイント 8. おまけ:これからの Swift 対応のために
5.
1. アプリ開発における「いい設計」とは?
6.
やってはいけないこと 最初から「神殿のような設計」を求めない方がいい。
7.
アプリ開発において受け入れるべき 「3つの変化」 1) OS/デバイス/開発言語/フレームワークの進化 • 最新のものでも1年後には当たり前のように陳腐化している。 •
ARC がなかった時代、block がなかった時代とでは「最適な設計」は当然違う。 2) ユーザニーズ/トレンドの変化 •「最適な設計」が完成する頃にはもうそれ自体不要になっていたりする。 • アプリ全体に影響を与えるようなフレームワークの採用には注意(例:Three20)。 3) チーム/メンバーの変化 • 人材流動化の時代。いつでもメンバーは入ったり抜けたりする。 • サービスやチームの規模も大きくなれば、設計のあるべき形も当然変わる。
8.
変化に対応できる「いい設計」の要件 1) 柔軟性 • プロダクトの要件や仕様の変更にすぐ対応できる。 •
特定のライブラリやフレームワークにできるだけ依存しない。 2) 拡張可能性 • 一極集中せず、機能を並列的に付け足していける。 • 逆に不要になったものは簡単に取り外せる。 3) 安定性 • 何かをちょっと変えただけで落ちまくるようになっては困る。
9.
参考:「メタボリズム」 建築には空間的な制約があるが、ソフトウェアは真にメタボリックな設計が実現可能。 メタボリズムは、1959年に黒川紀章や菊竹清訓ら日本の若手建築家・都市 計画家グループが開始した建築運動。新陳代謝(メタボリズム)からグルー プの名をとり、社会の変化や人口の成長に合わせて有機的に成長する都市 や建築を提案した。 彼らの構想した将来の都市は、高度経済成長という当時の日本の人口増加 圧力と都市の急速な更新、膨張に応えるものであった。 彼らは、従来の固定した形態や機能を支える「機械の原理」はもはや有効 的でないと考え、空間や機能が変化する「生命の原理」が将来の社会や文 化を支えると信じた。 … 引用:Wikipedia中銀カプセルタワービル 黒川紀章
10.
僕はこう思うッス 慣れない内はまずはスピード優先で作っていい。開発速度 が鈍ってきたらリファクタリングを検討しよう。そのとき にちゃんと時間を取らせてもらえるようにマネージャとの 信頼関係を築いておくことも大事です。
11.
2. Storyboard /
xib / コード の住み分け
12.
あかんパターンその1. 激重スパゲッティストーリーボード • 画面数が多くなると重く、可視性も悪くなる。 • チーム作業だとコンフリクトしまくってやばい。
13.
あかんパターンその2. 全部コードで書いてる • UI の微調整が大変になる。 •
チーム作業の場合つらい。デザイナとの分業もできない。 - (void)viewDidLoad { [super viewDidLoad]; UITextField *textField = [[UITextField alloc] initWithFrame:CGRectMake(10, 200, 300, 40)]; textField.borderStyle = UITextBorderStyleRoundedRect; textField.font = [UIFont systemFontOfSize:15]; textField.placeholder = @"Message"; textField.autocorrectionType = UITextAutocorrectionTypeNo; textField.keyboardType = UIKeyboardTypeDefault; textField.returnKeyType = UIReturnKeyDone; textField.clearButtonMode = UITextFieldViewModeWhileEditing; textField.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter; textField.delegate = self; [self.view addSubview:textField]; … }
14.
なかなか最適解がない • Storyboard のいいところ •
アプリの画面構成・遷移が一望できる。 • 簡単な遷移ならコードを書かなくてもいい。 • UI をグラフィカルに構成していける(デザイナと分業できる)。 • もどかしいところ • 画面遷移も構成も一個のファイルに詰め込んだら当然重くなる。 • 文字列の ID でコードと紐付けなきゃいけない。 • 遷移間の処理は prepareForSegue:sender: で分岐しなきゃいけない。
15.
僕のオススメのやり方 • Storyboard は画面遷移を定義するためだけに使う。 •
各コントローラの UI 構成は xib で作る。 • 画面の遷移処理は performSegueWithID: でやる。
16.
Storyboard で画面遷移、xib で画面構成 Viewを外しておく + 対応するファイル名の
xib が自動で読み込まれる!
17.
これで全体の画面遷移と各々の画面構成が分離できる + … Storyboard で画面遷移、xib で画面構成
18.
Storyboard 非対応な外部ライブラリもこの方法で行ける #import "XYZStoryboardSegue.h" @implementation
XYZStoryboardSegue - (void)perform { // 具体的な処理 } @end 独自 UIStoryboardSegue を作れば、どんな遷移も繋げる
19.
performSegueWithId: で遷移処理 - (void)cellTapped:(XYZTableViewCell
*)cell { XYZWebEntity *entity = cell.entity; [self performSegueWithIdentifier:@"Browser" preparation:^(UIStoryboardSegue *segue) { XYZWebViewController *vc = segue.destinationViewController; vc.title = entity.title; vc.URL = entity.linkURL; }]; } • prepareForSegue: に遷移処理をまとめて分岐させるのは嫌なので、遷移時にブロッ クを渡せるように拡張した(method-swizzling によるちょい裏技)。 • StoryboardID を別ファイルにしたり、遷移処理をメソッド化してカテゴリと切り 出したりすれば、各 ViewController では Storyboard のこと意識せずに済む。
20.
• このやり方の難点 • xib
だと navigationItem を指定したりできない(Outlet で繋いでおい てコードから指定することはできる) • 画面遷移処理は全てコードで記述しなきゃいけない。 • その他のやり方 • xib を使わず 画面遷移用の Storyboard と各画面別の Storyboard を 分ける。 • Segue は使わず、 instantiateViewControllerWithIdentifier: によって コードで VC を生成して画面遷移。
21.
僕はこう思うッス 現状最適なソリューションはないので、画面の数やチーム人数に応 じて上手くやってける方法を探っていきましょう。
22.
3. delegate /
callback / notification の 使い分け
23.
原則:相互参照は良くない • 特殊なケースを除いて、オブジェクトが相互に参照しあってメッセージを送り合うの は密結合になってよくない。 • アプリは基本的に木構造になっているので、子が親を参照したり、子同士で参照しあっ たりしないように気をつけたい。 •
オブジェクト間の依存関係を必要最小限に制限しながら通信する方法としてある delegate / callback / notification の3パターンを解説します。 親 子 親 子 子
24.
A) delegate パターン •
UITextFieldDelegate, UITableViewDelegate, UIImagePickerControllerDelegate など。 • 子(委譲する側 = delegater)は親(委譲される側 = delegate)の詳細については知らず、必要に応じて問い合わ せ/丸投げする。 • TableViewController(親)が TableView(子)を持つよう な、親が子を管理していてその存在期間中に密なやり取りが ある場合に有効。 • 1対N には不向き(親のメソッド内で分岐が必要になる) • VC 間の通信も delegate パターンになっていることが多い。 親 (delegate) 子 (delegater) 子は無責任に問い続ける
25.
B) callback パターン •
UIAlertControllerAction, …WithCompletionHandler: など。 • 親が子に対してやっておいて欲しい処理を予め指定しておく。 • 子への命令とコールバックをまとめて書けるのが利点。 • 通信などの単発の命令の完了処理や、処理中に密なやり取りを する場合に有効。 • AlertView / ActionSheet が callback パターンになったのは 必然。 親 子 子 用が済んだらサイナラ
26.
C) notification パターン •
UIApplicationWillEnterForegroundNotification, UIKeyboardWillShowNotification など。 • 通知者が受信者が誰なのかを直接知らない場合に有効。 • 受信者からのレスポンスを受け取りたい場合は使えない。 • ある画面でコンテンツを Like したのが、他画面でも反映 されてて欲しい場合などに有効。 • コード上では依存関係が見えにくいので、仕様変更による 不具合には注意が必要。 NotificationCenter 親1 親2 親3 子 (親子という表現は適切でないが、前の二つとの関連のため)
27.
どのパターンにせよ、 「子は親のことを知らなくていい」ことが大事! 親 子 delegate 親 callback 子 子 notification NotificationCenter 親1 親2 親3 子
28.
僕はこう思うッス いちいちプロトコルを作るのは面倒だから直接参照したくなるけど、 放っておくとすぐスパゲッティ化するので、早いうちから不必要な 依存性はシャキッと断ち切っておきましょう。
29.
4. インターフェース ∼
晒すものと隠すもの
30.
公開プロパティ/メソッドは できるだけ少なくシンプルにしておく。 • クラスの内部状態/内部でのみ使う操作は private
にしておきましょう (Obj-C なら無名カテゴリ/Swift なら private で)。 • 外から変更されることのない property は readonly / immutable に。 • サブクラス化前提のクラスで、子クラスのみに公開する必要のあるもの も public にしない。(Swift なら internal で、Obj-C はサブクラス専 用ヘッダを用意する) • 「このクラスの役割は何なのか」を意識し、「適切な名前がつけられる かどうか」を正しい設計の指針にする。
31.
僕はこう思うッス 細かなコーディング規約よりもインターフェースの正しさを意識する 方がずっと大事。 クラスの内部実装が汚いのは直しようがあるが、インターフェースが イビツだと修正が大変(内装のリフォーム < 骨格の改築)。
32.
5. 肥大化したクラスをスリム化する
33.
参考:
34.
BaseViewController の危険性 • 共通処理をなんでもかんでも
BaseVC に入れると、どんどん Fat 化してどこに何があるのか分からなくなる。メンテナンス性も下 がるし、変更の影響が見えづらく危険。 • 共通処理のうち一部カスタマイズできようにしようとする必要が 出てきたりして、サブクラスで共有のパラメータを用意したりテ ンプレートメソッドを作るハメになって余計ややこしくなる。 • iOS がアップデートして BaseVC でやってる処理が不要になって も容易に取り外せなかったりする。
35.
スリム化の戦略をいくつか A. モジュール化して切り出し B. 基底クラスをカテゴリ拡張 C.
クラスの実装を分割
36.
A. モジュール化して切り出し • 例えば
TableVC / CollectionVC の delegate / dataSource を別クラスにする。 • 切り出したモジュールとの間での相互参照が増えすぎないように気をつけないといけない (意外とこれが難しいので何でも切り出せばいいというものでもない)。 • 切り出したモジュールが専用の protocol を用意して、親への参照をなくしたりする。 TableViewController TableViewDelegate TableViewDataSource TableViewDelegate TableViewDataSource TableViewController
37.
B. 基底クラスをカテゴリ拡張 • 共通処理のうち、独立性の高い機能を切り出して
UIViewController 拡張にする。 • ロギング、キーボード表示関連、アラート/HUD表示 など全画面共通の機能。 • これも UIViewController+Common などとするとすぐ Fat 化するので注意。 MyViewController 共通処理 1 共通処理 2 UIViewController + ... 共通処理 1 UIViewController + ... 共通処理 2
38.
C. クラスの実装を分割 • Extension
は既存クラスを拡張するためだけでなく、自分で作ったクラスの実装を分割す るためにも使える。 • 例えば AppDelegate にはいろんな機能が詰め込まれがちだけど、互いに無関係なものが 多いので、機能群をまとめて分割するといい。 MyClass まとまり1 まとまり2 MyClass MyClass + まとまり1 MyClass + まとまり2
39.
僕はこう思うッス 最初から何でもかんでも共通化/クラス分割しようとすると危険。 特にクラス階層を深くするのは慎重に。全体像が見えてないうちは ベタ書きのまま我慢。 美意識よりも効果を優先しましょう。
40.
6. 通信処理のカプセル化と使い捨て
41.
通信処理のカプセル化 • Controller /
Model に生の通信処理を書くべきではない。 • endpoint-URL や、リクエストパラメータ、レスポンスの仕様に ついて利用者が意識しなくて済むようにしたい。 • レスポンスは Dictionary などのプリミティブ型ではなく、専用の エンティティクラスを用意した方がいい。型セーフになるし API の仕様変更に対しても柔軟に対応できる。
42.
僕が好きなやり方: 通信自体をオブジェクトとして使い捨てる - (IBAction)searchButtonTapped:(UIButton *)button { NSString
*query = …; XYZSearchRequest *req = [XYZSearchRequest requestWithQuery:_query]; [req startWithHandler:^(XYZSearchResultSet *result, NSError *error) { // 通信コールバック if(error) { … // エラー処理 return; } … }]; } • 通信開始のための手続きがシンプルでいい。 • インスタンス保持しておけば通信をキャンセルすることもできる。
43.
僕はこう思うッス AFNetworking のようなガッツリした通信ライブラリは本当に必要 か見直してみましょう。 API
仕様の特殊性を吸収する簡単なラッパー があればほとんどの場合十分。
44.
7. 外部ライブラリの使用を判断するポイント
45.
• まずソースコードは必ず確認する。 • IF仕様がイケてなかったら実装もきっとイケてない(クラッシュの原因にもなり うる)。 •
コードが公開されていないものは信頼性が保証されている場合に限定すべき。 • 他にも同様のライブラリがないか確認する。★数や最終コミット日時(継続的にメ ンテナンスされてるか)なども確認する。 • 分厚いライブラリの場合は警戒する。全面的にその仕様に依存した設計になってし まうのはリスク(例: Three20)。 • 自分が欲しい機能はそのライブラリの何割を占めるか?一部だけならそのコードに インスピレーションを受けた上で自作した方がいいかもしれない。 • それでも使用した方がよければ、ライセンスを確認した上で使わせて頂きましょう。
46.
8. (おまけ)これからの Swift
対応のために
47.
Swift 対応 既存コードを機械的 に書き換える Swift 最適化+ こっちの作業は機械がやればいい!
48.
objc2swift project https://github.com/yahoojapan/objc2swift Fork me!
49.
総まとめ:僕はこう思うッス よくできた設計は Storyboard とクラスのインターフェースを一望 するだけで大体の構造が分かる。細かくルールを定めるよりも先に、 どういう設計を目指すのかチームのみんなで合意しておきましょう。
50.
Questions?
51.
Thanks! @taketo1024
Jetzt herunterladen