SlideShare una empresa de Scribd logo
1 de 51
Descargar para leer sin conexión
さらに上を目指すための
iOS アプリ設計
@taketo1024
(このスライドはヤフー社内で「中級者iOSアプリ開発者」向けに行った講義の資料です)
本講座の目的
• iOSアプリ開発者がより高い視点からアプリの設計
を考えられるようになること。
• デザインパターンなどのお堅い話ではなく、「いい
設計」を感覚的に納得できるようにしたい。
• 「いい設計」を意識できるようになり、プロダクト
の品質と開発スピードが上がれば嬉しいです。
Agenda
1. アプリ開発における「いい設計」とは?
2. Storyboard / xib / コードの住み分け
3. delegate / callback / notification の使い分け
4. インターフェース ∼ 晒すものと隠すもの
5. 肥大化したクラスをスリム化する
6. 通信処理のカプセル化と使い捨て
7. 外部ライブラリの使用を判断するポイント
8. おまけ:これからの Swift 対応のために
1. アプリ開発における「いい設計」とは?
やってはいけないこと
最初から「神殿のような設計」を求めない方がいい。
アプリ開発において受け入れるべき
「3つの変化」
1) OS/デバイス/開発言語/フレームワークの進化
• 最新のものでも1年後には当たり前のように陳腐化している。
• ARC がなかった時代、block がなかった時代とでは「最適な設計」は当然違う。
2) ユーザニーズ/トレンドの変化
•「最適な設計」が完成する頃にはもうそれ自体不要になっていたりする。
• アプリ全体に影響を与えるようなフレームワークの採用には注意(例:Three20)。
3) チーム/メンバーの変化
• 人材流動化の時代。いつでもメンバーは入ったり抜けたりする。
• サービスやチームの規模も大きくなれば、設計のあるべき形も当然変わる。
変化に対応できる「いい設計」の要件
1) 柔軟性
• プロダクトの要件や仕様の変更にすぐ対応できる。
• 特定のライブラリやフレームワークにできるだけ依存しない。
2) 拡張可能性
• 一極集中せず、機能を並列的に付け足していける。
• 逆に不要になったものは簡単に取り外せる。
3) 安定性
• 何かをちょっと変えただけで落ちまくるようになっては困る。
参考:「メタボリズム」
建築には空間的な制約があるが、ソフトウェアは真にメタボリックな設計が実現可能。
メタボリズムは、1959年に黒川紀章や菊竹清訓ら日本の若手建築家・都市
計画家グループが開始した建築運動。新陳代謝(メタボリズム)からグルー
プの名をとり、社会の変化や人口の成長に合わせて有機的に成長する都市
や建築を提案した。
彼らの構想した将来の都市は、高度経済成長という当時の日本の人口増加
圧力と都市の急速な更新、膨張に応えるものであった。
彼らは、従来の固定した形態や機能を支える「機械の原理」はもはや有効
的でないと考え、空間や機能が変化する「生命の原理」が将来の社会や文
化を支えると信じた。 …
引用:Wikipedia中銀カプセルタワービル

黒川紀章
僕はこう思うッス
慣れない内はまずはスピード優先で作っていい。開発速度
が鈍ってきたらリファクタリングを検討しよう。そのとき
にちゃんと時間を取らせてもらえるようにマネージャとの
信頼関係を築いておくことも大事です。
2. Storyboard / xib / コード の住み分け
あかんパターンその1.
激重スパゲッティストーリーボード
• 画面数が多くなると重く、可視性も悪くなる。
• チーム作業だとコンフリクトしまくってやばい。
あかんパターンその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];



…
}
なかなか最適解がない
• Storyboard のいいところ
• アプリの画面構成・遷移が一望できる。
• 簡単な遷移ならコードを書かなくてもいい。
• UI をグラフィカルに構成していける(デザイナと分業できる)。
• もどかしいところ
• 画面遷移も構成も一個のファイルに詰め込んだら当然重くなる。
• 文字列の ID でコードと紐付けなきゃいけない。
• 遷移間の処理は prepareForSegue:sender: で分岐しなきゃいけない。
僕のオススメのやり方
• Storyboard は画面遷移を定義するためだけに使う。
• 各コントローラの UI 構成は xib で作る。
• 画面の遷移処理は performSegueWithID: でやる。
Storyboard で画面遷移、xib で画面構成
Viewを外しておく
+
対応するファイル名の xib
が自動で読み込まれる!
これで全体の画面遷移と各々の画面構成が分離できる
+
…
Storyboard で画面遷移、xib で画面構成
Storyboard 非対応な外部ライブラリもこの方法で行ける
#import "XYZStoryboardSegue.h"
@implementation XYZStoryboardSegue
- (void)perform
{
// 具体的な処理
}
@end
独自 UIStoryboardSegue を作れば、どんな遷移も繋げる
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 のこと意識せずに済む。
• このやり方の難点
• xib だと navigationItem を指定したりできない(Outlet で繋いでおい
てコードから指定することはできる)
• 画面遷移処理は全てコードで記述しなきゃいけない。
• その他のやり方
• xib を使わず 画面遷移用の Storyboard と各画面別の Storyboard を
分ける。
• Segue は使わず、 instantiateViewControllerWithIdentifier: によって
コードで VC を生成して画面遷移。
僕はこう思うッス
現状最適なソリューションはないので、画面の数やチーム人数に応
じて上手くやってける方法を探っていきましょう。
3. delegate / callback / notification の
使い分け
原則:相互参照は良くない
• 特殊なケースを除いて、オブジェクトが相互に参照しあってメッセージを送り合うの
は密結合になってよくない。
• アプリは基本的に木構造になっているので、子が親を参照したり、子同士で参照しあっ
たりしないように気をつけたい。
• オブジェクト間の依存関係を必要最小限に制限しながら通信する方法としてある
delegate / callback / notification の3パターンを解説します。
親
子
親
子 子
A) delegate パターン
• UITextFieldDelegate, UITableViewDelegate,
UIImagePickerControllerDelegate など。
• 子(委譲する側 = delegater)は親(委譲される側 =
delegate)の詳細については知らず、必要に応じて問い合わ
せ/丸投げする。
• TableViewController(親)が TableView(子)を持つよう
な、親が子を管理していてその存在期間中に密なやり取りが
ある場合に有効。
• 1対N には不向き(親のメソッド内で分岐が必要になる)
• VC 間の通信も delegate パターンになっていることが多い。
親 (delegate)
子 (delegater)
子は無責任に問い続ける
B) callback パターン
• UIAlertControllerAction, …WithCompletionHandler: など。
• 親が子に対してやっておいて欲しい処理を予め指定しておく。
• 子への命令とコールバックをまとめて書けるのが利点。
• 通信などの単発の命令の完了処理や、処理中に密なやり取りを
する場合に有効。
• AlertView / ActionSheet が callback パターンになったのは
必然。
親
子
子
用が済んだらサイナラ
C) notification パターン
• UIApplicationWillEnterForegroundNotification,
UIKeyboardWillShowNotification など。
• 通知者が受信者が誰なのかを直接知らない場合に有効。
• 受信者からのレスポンスを受け取りたい場合は使えない。
• ある画面でコンテンツを Like したのが、他画面でも反映
されてて欲しい場合などに有効。
• コード上では依存関係が見えにくいので、仕様変更による
不具合には注意が必要。
NotificationCenter
親1 親2 親3
子
(親子という表現は適切でないが、前の二つとの関連のため)
どのパターンにせよ、
「子は親のことを知らなくていい」ことが大事!
親
子
delegate
親
callback
子
子
notification
NotificationCenter
親1 親2 親3
子
僕はこう思うッス
いちいちプロトコルを作るのは面倒だから直接参照したくなるけど、
放っておくとすぐスパゲッティ化するので、早いうちから不必要な
依存性はシャキッと断ち切っておきましょう。
4. インターフェース ∼ 晒すものと隠すもの
公開プロパティ/メソッドは
できるだけ少なくシンプルにしておく。
• クラスの内部状態/内部でのみ使う操作は private にしておきましょう
(Obj-C なら無名カテゴリ/Swift なら private で)。
• 外から変更されることのない property は readonly / immutable に。
• サブクラス化前提のクラスで、子クラスのみに公開する必要のあるもの
も public にしない。(Swift なら internal で、Obj-C はサブクラス専
用ヘッダを用意する)
• 「このクラスの役割は何なのか」を意識し、「適切な名前がつけられる
かどうか」を正しい設計の指針にする。
僕はこう思うッス
細かなコーディング規約よりもインターフェースの正しさを意識する
方がずっと大事。
クラスの内部実装が汚いのは直しようがあるが、インターフェースが
イビツだと修正が大変(内装のリフォーム < 骨格の改築)。
5. 肥大化したクラスをスリム化する
参考:
BaseViewController の危険性
• 共通処理をなんでもかんでも BaseVC に入れると、どんどん Fat
化してどこに何があるのか分からなくなる。メンテナンス性も下
がるし、変更の影響が見えづらく危険。
• 共通処理のうち一部カスタマイズできようにしようとする必要が
出てきたりして、サブクラスで共有のパラメータを用意したりテ
ンプレートメソッドを作るハメになって余計ややこしくなる。
• iOS がアップデートして BaseVC でやってる処理が不要になって
も容易に取り外せなかったりする。
スリム化の戦略をいくつか
A. モジュール化して切り出し
B. 基底クラスをカテゴリ拡張
C. クラスの実装を分割
A. モジュール化して切り出し
• 例えば TableVC / CollectionVC の delegate / dataSource を別クラスにする。
• 切り出したモジュールとの間での相互参照が増えすぎないように気をつけないといけない
(意外とこれが難しいので何でも切り出せばいいというものでもない)。
• 切り出したモジュールが専用の protocol を用意して、親への参照をなくしたりする。
TableViewController
TableViewDelegate
TableViewDataSource
TableViewDelegate
TableViewDataSource
TableViewController
B. 基底クラスをカテゴリ拡張
• 共通処理のうち、独立性の高い機能を切り出して UIViewController 拡張にする。
• ロギング、キーボード表示関連、アラート/HUD表示 など全画面共通の機能。
• これも UIViewController+Common などとするとすぐ Fat 化するので注意。
MyViewController
共通処理 1
共通処理 2
UIViewController + ...
共通処理 1
UIViewController + ...
共通処理 2
C. クラスの実装を分割
• Extension は既存クラスを拡張するためだけでなく、自分で作ったクラスの実装を分割す
るためにも使える。
• 例えば AppDelegate にはいろんな機能が詰め込まれがちだけど、互いに無関係なものが
多いので、機能群をまとめて分割するといい。
MyClass
まとまり1
まとまり2
MyClass
MyClass + まとまり1
MyClass + まとまり2
僕はこう思うッス
最初から何でもかんでも共通化/クラス分割しようとすると危険。
特にクラス階層を深くするのは慎重に。全体像が見えてないうちは
ベタ書きのまま我慢。
美意識よりも効果を優先しましょう。
6. 通信処理のカプセル化と使い捨て
通信処理のカプセル化
• Controller / Model に生の通信処理を書くべきではない。
• endpoint-URL や、リクエストパラメータ、レスポンスの仕様に
ついて利用者が意識しなくて済むようにしたい。
• レスポンスは Dictionary などのプリミティブ型ではなく、専用の
エンティティクラスを用意した方がいい。型セーフになるし API
の仕様変更に対しても柔軟に対応できる。
僕が好きなやり方:
通信自体をオブジェクトとして使い捨てる
- (IBAction)searchButtonTapped:(UIButton *)button
{
NSString *query = …;
XYZSearchRequest *req = [XYZSearchRequest requestWithQuery:_query];
[req startWithHandler:^(XYZSearchResultSet *result, NSError *error) {
// 通信コールバック
if(error) {
… // エラー処理
return;
}
…
}];
}
• 通信開始のための手続きがシンプルでいい。
• インスタンス保持しておけば通信をキャンセルすることもできる。
僕はこう思うッス
AFNetworking のようなガッツリした通信ライブラリは本当に必要
か見直してみましょう。 API 仕様の特殊性を吸収する簡単なラッパー
があればほとんどの場合十分。
7. 外部ライブラリの使用を判断するポイント
• まずソースコードは必ず確認する。
• IF仕様がイケてなかったら実装もきっとイケてない(クラッシュの原因にもなり
うる)。
• コードが公開されていないものは信頼性が保証されている場合に限定すべき。
• 他にも同様のライブラリがないか確認する。★数や最終コミット日時(継続的にメ
ンテナンスされてるか)なども確認する。
• 分厚いライブラリの場合は警戒する。全面的にその仕様に依存した設計になってし
まうのはリスク(例: Three20)。
• 自分が欲しい機能はそのライブラリの何割を占めるか?一部だけならそのコードに
インスピレーションを受けた上で自作した方がいいかもしれない。
• それでも使用した方がよければ、ライセンスを確認した上で使わせて頂きましょう。
8. (おまけ)これからの Swift 対応のために
Swift 対応
既存コードを機械的
に書き換える
Swift 最適化+
こっちの作業は機械がやればいい!
objc2swift project
https://github.com/yahoojapan/objc2swift
Fork me!
総まとめ:僕はこう思うッス
よくできた設計は Storyboard とクラスのインターフェースを一望
するだけで大体の構造が分かる。細かくルールを定めるよりも先に、
どういう設計を目指すのかチームのみんなで合意しておきましょう。
Questions?
Thanks!
@taketo1024

Más contenido relacionado

La actualidad más candente

Primeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-endPrimeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-endDiego Eis
 
Arquitetura da informação
Arquitetura da informaçãoArquitetura da informação
Arquitetura da informaçãoCristiane Mendes
 
20160526 依存関係逆転の原則
20160526 依存関係逆転の原則20160526 依存関係逆転の原則
20160526 依存関係逆転の原則bonjin6770 Kurosawa
 
오픈 소스 사용 매뉴얼
오픈 소스 사용 매뉴얼오픈 소스 사용 매뉴얼
오픈 소스 사용 매뉴얼Kenu, GwangNam Heo
 
Sw개발 hw제작설계서 임베부스러기
Sw개발 hw제작설계서 임베부스러기Sw개발 hw제작설계서 임베부스러기
Sw개발 hw제작설계서 임베부스러기21HG020
 
BEM記法~HTMLコーディングする際のidやclassの命名規則~
BEM記法~HTMLコーディングする際のidやclassの命名規則~BEM記法~HTMLコーディングする際のidやclassの命名規則~
BEM記法~HTMLコーディングする際のidやclassの命名規則~Younju Park
 
취미로 엔진 만들기
취미로 엔진 만들기취미로 엔진 만들기
취미로 엔진 만들기Jiho Choi
 
Introdução ao Front-end no Desenvolvimento Web
Introdução ao Front-end no Desenvolvimento WebIntrodução ao Front-end no Desenvolvimento Web
Introdução ao Front-end no Desenvolvimento WebAnderson Luís Furlan
 
DDDを実践できるエンジニアを育成するための取り組みについて
DDDを実践できるエンジニアを育成するための取り組みについてDDDを実践できるエンジニアを育成するための取り組みについて
DDDを実践できるエンジニアを育成するための取り組みについてBIGLOBE Inc.
 
Análise de Redes Sociais com Python
Análise de Redes Sociais com PythonAnálise de Redes Sociais com Python
Análise de Redes Sociais com PythonAna Paula Gomes
 
자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃
자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃
자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃Dongsik Yang
 
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님NAVER D2
 
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計Tadayoshi Sato
 
Model view controller (mvc)
Model view controller (mvc)Model view controller (mvc)
Model view controller (mvc)M Ahsan Khan
 
파이썬 생존 안내서 (자막)
파이썬 생존 안내서 (자막)파이썬 생존 안내서 (자막)
파이썬 생존 안내서 (자막)Heungsub Lee
 
ドメインモデルの育て方
ドメインモデルの育て方ドメインモデルの育て方
ドメインモデルの育て方増田 亨
 
ドメイン駆動設計入門
ドメイン駆動設計入門ドメイン駆動設計入門
ドメイン駆動設計入門増田 亨
 
모던 C++ 정리
모던 C++ 정리모던 C++ 정리
모던 C++ 정리Hansol Kang
 
ADO.NETとORMとMicro-ORM -dapper dot netを使ってみた
ADO.NETとORMとMicro-ORM -dapper dot netを使ってみたADO.NETとORMとMicro-ORM -dapper dot netを使ってみた
ADO.NETとORMとMicro-ORM -dapper dot netを使ってみたNarami Kiyokura
 

La actualidad más candente (20)

Primeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-endPrimeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-end
 
Arquitetura da informação
Arquitetura da informaçãoArquitetura da informação
Arquitetura da informação
 
20160526 依存関係逆転の原則
20160526 依存関係逆転の原則20160526 依存関係逆転の原則
20160526 依存関係逆転の原則
 
오픈 소스 사용 매뉴얼
오픈 소스 사용 매뉴얼오픈 소스 사용 매뉴얼
오픈 소스 사용 매뉴얼
 
Sw개발 hw제작설계서 임베부스러기
Sw개발 hw제작설계서 임베부스러기Sw개발 hw제작설계서 임베부스러기
Sw개발 hw제작설계서 임베부스러기
 
BEM記法~HTMLコーディングする際のidやclassの命名規則~
BEM記法~HTMLコーディングする際のidやclassの命名規則~BEM記法~HTMLコーディングする際のidやclassの命名規則~
BEM記法~HTMLコーディングする際のidやclassの命名規則~
 
취미로 엔진 만들기
취미로 엔진 만들기취미로 엔진 만들기
취미로 엔진 만들기
 
Introdução ao Front-end no Desenvolvimento Web
Introdução ao Front-end no Desenvolvimento WebIntrodução ao Front-end no Desenvolvimento Web
Introdução ao Front-end no Desenvolvimento Web
 
DDDを実践できるエンジニアを育成するための取り組みについて
DDDを実践できるエンジニアを育成するための取り組みについてDDDを実践できるエンジニアを育成するための取り組みについて
DDDを実践できるエンジニアを育成するための取り組みについて
 
Análise de Redes Sociais com Python
Análise de Redes Sociais com PythonAnálise de Redes Sociais com Python
Análise de Redes Sociais com Python
 
자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃
자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃
자주 사용되는 UI 패턴(컴포넌트) 과 UI 레이아웃
 
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님
 
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
 
Model view controller (mvc)
Model view controller (mvc)Model view controller (mvc)
Model view controller (mvc)
 
파이썬 생존 안내서 (자막)
파이썬 생존 안내서 (자막)파이썬 생존 안내서 (자막)
파이썬 생존 안내서 (자막)
 
ドメインモデルの育て方
ドメインモデルの育て方ドメインモデルの育て方
ドメインモデルの育て方
 
ドメイン駆動設計入門
ドメイン駆動設計入門ドメイン駆動設計入門
ドメイン駆動設計入門
 
모던 C++ 정리
모던 C++ 정리모던 C++ 정리
모던 C++ 정리
 
Diagrama de Casos de Uso
Diagrama de Casos de UsoDiagrama de Casos de Uso
Diagrama de Casos de Uso
 
ADO.NETとORMとMicro-ORM -dapper dot netを使ってみた
ADO.NETとORMとMicro-ORM -dapper dot netを使ってみたADO.NETとORMとMicro-ORM -dapper dot netを使ってみた
ADO.NETとORMとMicro-ORM -dapper dot netを使ってみた
 

Destacado

iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方kakegawa-atsushi
 
BaseViewControllerは作りたくない
BaseViewControllerは作りたくないBaseViewControllerは作りたくない
BaseViewControllerは作りたくない今城 善矩
 
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学Taketo Sano
 
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPracticeiOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPracticeKen Morishita
 
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべてApple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべてMasaru Gushiken
 
プログラマのための線形代数再入門
プログラマのための線形代数再入門プログラマのための線形代数再入門
プログラマのための線形代数再入門Taketo Sano
 
何もないところから数を作る
何もないところから数を作る何もないところから数を作る
何もないところから数を作るTaketo Sano
 
プロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswiftプロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswiftTomohiro Kumagai
 
NS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバNS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバTomohiro Kumagai
 
Swift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposiumSwift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposiumTomohiro Kumagai
 
AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話Tomohiro Kumagai
 
objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望) objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望) Taketo Sano
 
デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発Kenta Ohsugi
 
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフトobjc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフトTaketo Sano
 
基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先Taketo Sano
 
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)Ken Morishita
 
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列Taketo Sano
 
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法Kenji Tanaka
 
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計Yuichi Adachi
 

Destacado (20)

iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方
 
BaseViewControllerは作りたくない
BaseViewControllerは作りたくないBaseViewControllerは作りたくない
BaseViewControllerは作りたくない
 
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
 
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPracticeiOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
 
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべてApple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべて
 
プログラマのための線形代数再入門
プログラマのための線形代数再入門プログラマのための線形代数再入門
プログラマのための線形代数再入門
 
何もないところから数を作る
何もないところから数を作る何もないところから数を作る
何もないところから数を作る
 
3 auto layout tips
3 auto layout tips3 auto layout tips
3 auto layout tips
 
プロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswiftプロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswift
 
NS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバNS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバ
 
Swift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposiumSwift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposium
 
AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話
 
objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望) objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望)
 
デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発
 
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフトobjc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
 
基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先
 
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
 
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
 
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
 
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計
 

Similar a さらに上を目指すための iOS アプリ設計

ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 Unicast Inc.
 
e-Learning Design for Teacher
e-Learning Design for Teachere-Learning Design for Teacher
e-Learning Design for TeacherSunami Hokuto
 
Itca yammer提案110615
Itca yammer提案110615Itca yammer提案110615
Itca yammer提案110615伸夫 森本
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整えるonozaty
 
2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向keki3
 
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣loftwork
 
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sortloftwork
 
DSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイルDSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイル陽平 山口
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?Kiro Harada
 
131207 NECTJ Workshop 2
131207 NECTJ Workshop 2131207 NECTJ Workshop 2
131207 NECTJ Workshop 2NECTJ
 
タブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデアタブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデアNaoya Sangu
 
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用masashi takehara
 
iQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナーiQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナーImamura Masayuki
 
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計についてTomomitsuKusaba
 
Project Management
Project ManagementProject Management
Project ManagementKazuto Omori
 
#MSIgnite x Japan Microsoft MVP/RD - Learning story
#MSIgnite x Japan Microsoft MVP/RD - Learning story#MSIgnite x Japan Microsoft MVP/RD - Learning story
#MSIgnite x Japan Microsoft MVP/RD - Learning storyRie Moriguchi
 
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)Webpla LLC.
 
社内 DDD 勉強会第1回
社内 DDD 勉強会第1回社内 DDD 勉強会第1回
社内 DDD 勉強会第1回shingo suzuki
 
2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料TENTO_slide
 

Similar a さらに上を目指すための iOS アプリ設計 (20)

ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 
 
DevLOVE iPhoneアプリ勉強会
DevLOVE iPhoneアプリ勉強会DevLOVE iPhoneアプリ勉強会
DevLOVE iPhoneアプリ勉強会
 
e-Learning Design for Teacher
e-Learning Design for Teachere-Learning Design for Teacher
e-Learning Design for Teacher
 
Itca yammer提案110615
Itca yammer提案110615Itca yammer提案110615
Itca yammer提案110615
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整える
 
2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向
 
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣
 
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort
 
DSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイルDSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイル
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?
 
131207 NECTJ Workshop 2
131207 NECTJ Workshop 2131207 NECTJ Workshop 2
131207 NECTJ Workshop 2
 
タブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデアタブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデア
 
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
 
iQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナーiQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナー
 
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について
 
Project Management
Project ManagementProject Management
Project Management
 
#MSIgnite x Japan Microsoft MVP/RD - Learning story
#MSIgnite x Japan Microsoft MVP/RD - Learning story#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)MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
 
社内 DDD 勉強会第1回
社内 DDD 勉強会第1回社内 DDD 勉強会第1回
社内 DDD 勉強会第1回
 
2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料
 

Más de 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...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 で数学研究のススメSwift で数学研究のススメ
Swift で数学研究のススメTaketo Sano
 
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータTaketo Sano
 
特性類の気持ち
特性類の気持ち特性類の気持ち
特性類の気持ちTaketo Sano
 
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べSwift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べTaketo Sano
 
山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門Taketo Sano
 
何もないところから数を作る
何もないところから数を作る何もないところから数を作る
何もないところから数を作るTaketo Sano
 
情報幾何学 #2.4
情報幾何学 #2.4情報幾何学 #2.4
情報幾何学 #2.4Taketo Sano
 
情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16Taketo Sano
 
objc2swift (自動変換の野望)
objc2swift (自動変換の野望)objc2swift (自動変換の野望)
objc2swift (自動変換の野望)Taketo Sano
 
2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertible2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertibleTaketo Sano
 
let UIWebView as WKWebView
let UIWebView as WKWebViewlet UIWebView as WKWebView
let UIWebView as WKWebViewTaketo Sano
 
コードを書けば複素数がわかる
コードを書けば複素数がわかるコードを書けば複素数がわかる
コードを書けば複素数がわかるTaketo Sano
 
虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数Taketo Sano
 
ひろ子 in Objective-C
ひろ子 in Objective-Cひろ子 in Objective-C
ひろ子 in Objective-CTaketo Sano
 
Objective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & HackObjective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & HackTaketo Sano
 
Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作Taketo Sano
 
下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズム下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズムTaketo Sano
 

Más de 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...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 で数学研究のススメ
 
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
 
特性類の気持ち
特性類の気持ち特性類の気持ち
特性類の気持ち
 
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べSwift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
 
山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門
 
何もないところから数を作る
何もないところから数を作る何もないところから数を作る
何もないところから数を作る
 
情報幾何学 #2.4
情報幾何学 #2.4情報幾何学 #2.4
情報幾何学 #2.4
 
情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16
 
objc2swift (自動変換の野望)
objc2swift (自動変換の野望)objc2swift (自動変換の野望)
objc2swift (自動変換の野望)
 
2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertible2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertible
 
let UIWebView as WKWebView
let UIWebView as WKWebViewlet UIWebView as WKWebView
let UIWebView as WKWebView
 
コードを書けば複素数がわかる
コードを書けば複素数がわかるコードを書けば複素数がわかる
コードを書けば複素数がわかる
 
虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数
 
ひろ子 in Objective-C
ひろ子 in Objective-Cひろ子 in Objective-C
ひろ子 in Objective-C
 
Objective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & HackObjective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & Hack
 
Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作
 
下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズム下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズム
 

さらに上を目指すための iOS アプリ設計