Submit Search
Upload
さらに上を目指すための iOS アプリ設計
•
238 likes
•
30,949 views
Taketo Sano
Follow
2015/05/13 ヤフー社内「中級 iOS アプリ開発者」向けに行った講義の資料。
Read less
Read more
Software
Report
Share
Report
Share
1 of 51
Download now
Download to read offline
Recommended
PHPからJavaへ乗り換えた。そんな昔話をしよう
PHPからJavaへ乗り換えた。そんな昔話をしよう
優介 黒河
ゲームサーバ勉強会第七回(SIG-NetworkSystem)での発表資料です
IOS/Androidアプリの3つの大事な設計方針
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
iOS/Androidアプリを作る際に理解しておいて欲しい「Model」という役割について説明します。わりと意識していないケースがあるので、チェックしてみてください。
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
Ken Morishita
StateMachine for client apps.
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
MVCもやもや話
MVCもやもや話
Tetsuya Kaneuchi
iOS アプリ開発でのMVCについて。すべてを View Controller に書いてしまいがちなのを避けたい。
An other world awaits you
An other world awaits you
信之 岩永
C# 5.0/VB 11で導入された async/await と、 その背後にある実行インフラ await 演算子の展開結果 await 演算子では解決できなその他の非同期 などについての話。
AIと最適化の違いをうっかり聞いてしまう前に
AIと最適化の違いをうっかり聞いてしまう前に
Monta Yashi
最近ちょっと聞くことが多い数理最適化。 エーアイとどう違うなかなと思った時にチラ見して3分でわかった気分になる資料
Recommended
PHPからJavaへ乗り換えた。そんな昔話をしよう
PHPからJavaへ乗り換えた。そんな昔話をしよう
優介 黒河
ゲームサーバ勉強会第七回(SIG-NetworkSystem)での発表資料です
IOS/Androidアプリの3つの大事な設計方針
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
iOS/Androidアプリを作る際に理解しておいて欲しい「Model」という役割について説明します。わりと意識していないケースがあるので、チェックしてみてください。
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
Ken Morishita
StateMachine for client apps.
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
MVCもやもや話
MVCもやもや話
Tetsuya Kaneuchi
iOS アプリ開発でのMVCについて。すべてを View Controller に書いてしまいがちなのを避けたい。
An other world awaits you
An other world awaits you
信之 岩永
C# 5.0/VB 11で導入された async/await と、 その背後にある実行インフラ await 演算子の展開結果 await 演算子では解決できなその他の非同期 などについての話。
AIと最適化の違いをうっかり聞いてしまう前に
AIと最適化の違いをうっかり聞いてしまう前に
Monta Yashi
最近ちょっと聞くことが多い数理最適化。 エーアイとどう違うなかなと思った時にチラ見して3分でわかった気分になる資料
機械学習によるデータ分析まわりのお話
機械学習によるデータ分析まわりのお話
Ryota Kamoshida
某所で機械学習の講習会(?)のようなものをしたときの資料です. 機械学習によるデータ分析について,アルゴリズムやツールの使い方*以外*の部分で 重要だと思うことを重点的にまとめたつもりです.
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
社内勉強会発表用 内容 ・モジュールの凝集度 ・モジュール結合度 ・オブジェクト指向 ・インタフェース
Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法
Hidehisa Matsutani
2016/5/14 第10回 Redmine.tokyo勉強会 発表資料 チームパフォーマンスや品質を評価をするためにメトリクスを活用することは重要です。 REST API、周辺ツール等を活用し、基本機能では実現が困難なメトリクスを見える化する方法をご紹介します。 (平均完了日数や放置日数の分布、信頼度成長曲線やバグ収束率など)
【Swift】ローカル通知のバックグラウンド対応
【Swift】ローカル通知のバックグラウンド対応
Nekokichi
アプリ道場サロンでのLT
正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる
toshihiro ichitani
DevLOVE300 講演 https://devlove.doorkeeper.jp/events/102926
Phpをいじり倒す10の方法
Phpをいじり倒す10の方法
Moriyoshi Koizumi
No-Ops で大量データ処理基盤
No-Ops で大量データ処理基盤
Google Cloud Platform - Japan
デブサミ2017の講演資料です。Google では検索やYoutube、Gmailといったビリオンユーザを抱えるサービスのデータを効率良く処理するため、MapReduceやBigTable、Dremelといった多くの基盤技術を発明してそれらを自社で利用してきました。Google Cloud Platformを使うと、こうした最新のテクノロジーを使いやすいサービスとして利用することできます。データ処理の概要アーキテクチャと BigQuery、Dataflow を中心とした製品について説明します。
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
Flutter移行の苦労と、乗り越えた先に得られたもの
Flutter移行の苦労と、乗り越えた先に得られたもの
Recruit Lifestyle Co., Ltd.
iOS/Android共にリリースから10年を迎えたじゃらんアプリでは、さらなる開発効率と品質の向上を目指しFlutterへの順次移行に挑戦しています。本資料では、その過程で得られた知見についてまとめています。
Geometry with Unity
Geometry with Unity
京大 マイコンクラブ
Geometry with Unity
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Takafumi ONAKA
2012-03-22 techhills
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
BIGLOBE Inc.
その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。 5年という歳月はそれを気づかせるには十分な時間で、 DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。 そのコードは何を失敗していたのか?そして、それは改善するために改善した事とは? BIGLOBEにおける"今"のいいコードの書き方をできる限り具体的な事例を元に紹介します。
Redmineカスタムフィールド表示改善
Redmineカスタムフィールド表示改善
Yuuki Nara
Redmine Custom field layout improvement technique (Japanese Only)
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님
NAVER D2
제 4회 D2 CAMPUS SEMINAR 2세션
ゲームエンジンの中の話
ゲームエンジンの中の話
Masayoshi Kamai
モバイル・コンシューマ開発比較勉強会 #3
GUI アプリケーションにおける MVC
GUI アプリケーションにおける MVC
Yu Nobuoka
- 関連ブログ記事 : http://vividcode.hatenablog.com/entry/study-meeting/kyotojs-3-gui-mvc-basis Kyoto.js #3 での発表資料です。 最近 GUI アプリケーションでの MVC について基本的なことを考えなおしていたので、簡単にオセロ的なゲームを実装してみて、それを発表しました。
세션5. web3.js와 Node.js 를 사용한 dApp 개발
세션5. web3.js와 Node.js 를 사용한 dApp 개발
Jay JH Park
이더리움 연구회 정기 발표회, 세션5 - web3.js와 Node.js 를 사용한 dApp 개발
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計
Yuichi Adachi
第二回 北海道勉強会「スマホアプリ開発、あしたのための環境と設計のアプローチ」 資料
[SOSCON 2017] 주니어 개발자 5000명, 개발 해서 남 주자
[SOSCON 2017] 주니어 개발자 5000명, 개발 해서 남 주자
Yurim Jin
SOSCON 2017에서 발표한 자료입니다. http://www.soscon.net
iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方
kakegawa-atsushi
2014/2/25 に開催された、ヤフー vs クラスメソッド Battle 3 の発表資料です。
BaseViewControllerは作りたくない
BaseViewControllerは作りたくない
今城 善矩
第13回potatotipsで発表した資料です http://connpass.com/event/10697/
More Related Content
What's hot
機械学習によるデータ分析まわりのお話
機械学習によるデータ分析まわりのお話
Ryota Kamoshida
某所で機械学習の講習会(?)のようなものをしたときの資料です. 機械学習によるデータ分析について,アルゴリズムやツールの使い方*以外*の部分で 重要だと思うことを重点的にまとめたつもりです.
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
社内勉強会発表用 内容 ・モジュールの凝集度 ・モジュール結合度 ・オブジェクト指向 ・インタフェース
Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法
Hidehisa Matsutani
2016/5/14 第10回 Redmine.tokyo勉強会 発表資料 チームパフォーマンスや品質を評価をするためにメトリクスを活用することは重要です。 REST API、周辺ツール等を活用し、基本機能では実現が困難なメトリクスを見える化する方法をご紹介します。 (平均完了日数や放置日数の分布、信頼度成長曲線やバグ収束率など)
【Swift】ローカル通知のバックグラウンド対応
【Swift】ローカル通知のバックグラウンド対応
Nekokichi
アプリ道場サロンでのLT
正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる
toshihiro ichitani
DevLOVE300 講演 https://devlove.doorkeeper.jp/events/102926
Phpをいじり倒す10の方法
Phpをいじり倒す10の方法
Moriyoshi Koizumi
No-Ops で大量データ処理基盤
No-Ops で大量データ処理基盤
Google Cloud Platform - Japan
デブサミ2017の講演資料です。Google では検索やYoutube、Gmailといったビリオンユーザを抱えるサービスのデータを効率良く処理するため、MapReduceやBigTable、Dremelといった多くの基盤技術を発明してそれらを自社で利用してきました。Google Cloud Platformを使うと、こうした最新のテクノロジーを使いやすいサービスとして利用することできます。データ処理の概要アーキテクチャと BigQuery、Dataflow を中心とした製品について説明します。
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
Flutter移行の苦労と、乗り越えた先に得られたもの
Flutter移行の苦労と、乗り越えた先に得られたもの
Recruit Lifestyle Co., Ltd.
iOS/Android共にリリースから10年を迎えたじゃらんアプリでは、さらなる開発効率と品質の向上を目指しFlutterへの順次移行に挑戦しています。本資料では、その過程で得られた知見についてまとめています。
Geometry with Unity
Geometry with Unity
京大 マイコンクラブ
Geometry with Unity
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Takafumi ONAKA
2012-03-22 techhills
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
BIGLOBE Inc.
その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。 5年という歳月はそれを気づかせるには十分な時間で、 DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。 そのコードは何を失敗していたのか?そして、それは改善するために改善した事とは? BIGLOBEにおける"今"のいいコードの書き方をできる限り具体的な事例を元に紹介します。
Redmineカスタムフィールド表示改善
Redmineカスタムフィールド表示改善
Yuuki Nara
Redmine Custom field layout improvement technique (Japanese Only)
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님
NAVER D2
제 4회 D2 CAMPUS SEMINAR 2세션
ゲームエンジンの中の話
ゲームエンジンの中の話
Masayoshi Kamai
モバイル・コンシューマ開発比較勉強会 #3
GUI アプリケーションにおける MVC
GUI アプリケーションにおける MVC
Yu Nobuoka
- 関連ブログ記事 : http://vividcode.hatenablog.com/entry/study-meeting/kyotojs-3-gui-mvc-basis Kyoto.js #3 での発表資料です。 最近 GUI アプリケーションでの MVC について基本的なことを考えなおしていたので、簡単にオセロ的なゲームを実装してみて、それを発表しました。
세션5. web3.js와 Node.js 를 사용한 dApp 개발
세션5. web3.js와 Node.js 를 사용한 dApp 개발
Jay JH Park
이더리움 연구회 정기 발표회, 세션5 - web3.js와 Node.js 를 사용한 dApp 개발
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計
Yuichi Adachi
第二回 北海道勉強会「スマホアプリ開発、あしたのための環境と設計のアプローチ」 資料
[SOSCON 2017] 주니어 개발자 5000명, 개발 해서 남 주자
[SOSCON 2017] 주니어 개발자 5000명, 개발 해서 남 주자
Yurim Jin
SOSCON 2017에서 발표한 자료입니다. http://www.soscon.net
What's hot
(20)
機械学習によるデータ分析まわりのお話
機械学習によるデータ分析まわりのお話
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法
【Swift】ローカル通知のバックグラウンド対応
【Swift】ローカル通知のバックグラウンド対応
正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる
Phpをいじり倒す10の方法
Phpをいじり倒す10の方法
No-Ops で大量データ処理基盤
No-Ops で大量データ処理基盤
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Flutter移行の苦労と、乗り越えた先に得られたもの
Flutter移行の苦労と、乗り越えた先に得られたもの
Geometry with Unity
Geometry with Unity
マジカルsvnとキュアgit
マジカルsvnとキュアgit
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
Redmineカスタムフィールド表示改善
Redmineカスタムフィールド表示改善
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님
ゲームエンジンの中の話
ゲームエンジンの中の話
GUI アプリケーションにおける MVC
GUI アプリケーションにおける MVC
세션5. web3.js와 Node.js 를 사용한 dApp 개발
세션5. web3.js와 Node.js 를 사용한 dApp 개발
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
VIPER アーキテクチャによる iOS アプリの設計
VIPER アーキテクチャによる iOS アプリの設計
[SOSCON 2017] 주니어 개발자 5000명, 개발 해서 남 주자
[SOSCON 2017] 주니어 개발자 5000명, 개발 해서 남 주자
Viewers also liked
iOS アプリのメンテナンス性を高めるための基本的な考え方
iOS アプリのメンテナンス性を高めるための基本的な考え方
kakegawa-atsushi
2014/2/25 に開催された、ヤフー vs クラスメソッド Battle 3 の発表資料です。
BaseViewControllerは作りたくない
BaseViewControllerは作りたくない
今城 善矩
第13回potatotipsで発表した資料です http://connpass.com/event/10697/
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
Taketo Sano
2012-02-21 at Yahoo! JAPAN
iOSやAndroidアプリ開発のGoodPractice
iOSやAndroidアプリ開発のGoodPractice
Ken Morishita
iOS/Androidアプリ開発のGoodPracticeのようなものです。
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Masaru Gushiken
「iOSエンジニアがゼロだったじげんがどのように開発を行ったのか?」であったり、個人でSwift学習を行う際のpointなどをまとめた内容になっています。
プログラマのための線形代数再入門
プログラマのための線形代数再入門
Taketo Sano
2015/1/30 「プログラマのための数学勉強会」にて発表。 動画: https://www.youtube.com/watch?v=hyzotMaTtPg
何もないところから数を作る
何もないところから数を作る
Taketo Sano
7/24「第4回プログラマのための数学勉強会」にて発表。
3 auto layout tips
3 auto layout tips
Tomoki Hasegawa
@tomzoh による【第13回】potatotips(iOS/Android開発Tips共有会) の発表資料です。 #potatotips
プロトコル指向 - 夢と現実の狭間 #cswift
プロトコル指向 - 夢と現実の狭間 #cswift
Tomohiro Kumagai
Swift 3.0 で、廃止される BooleanType と、強化される FloatingPoint と。それらを見たときに感じた衝撃。その事実を観察しながら、実際の様子、感じたこと、これからのこと。そんなことを綴った発表資料です。
NS Prefix 外伝 … Copy-On-Write #関モバ
NS Prefix 外伝 … Copy-On-Write #関モバ
Tomohiro Kumagai
Swift 3 の変化のひとつに Foundation での NS プレフィックス削除があります。その中でも、とりわけ "新しい値型" の新設に伴って、値型とクラス型をブリッジする選択が取られた型の、そのパフォーマンスの最適化に注目してみました。
Swift 2.0 大域関数の行方から #swift2symposium
Swift 2.0 大域関数の行方から #swift2symposium
Tomohiro Kumagai
2015/06/28 に @k_katsumi さん主催で開催された「Swift 2 シンポジウム」 (http://realm.connpass.com/event/16556/) で発表させて頂いた資料です。 初めて Swift 2.0 に触れたときに大域関数がごっそり削除されていた衝撃から、それを敢行する上での柱となっていた Protocol Extension の魅力を紹介し、それを以って積極的に使っても良いものなのかを議論させて頂きました。 後半は疑問系が連発しますが「自分はそう思ってるけれど、どう感じますか?」という意味合いです。自分はこう思う!とかありましたらぜひぜひ教えてくださいませ。
AnyObject – 自分が見落としていた、基本の話
AnyObject – 自分が見落としていた、基本の話
Tomohiro Kumagai
Swift の AnyObject の性質を、自分はすっかり見落としていたので、それについての基本的なところを確かめておくことにしました。Swift の @objc による動的ディスパッチ、けっこういい感じに出来たんですね。
objc2swift (続・自動変換の野望)
objc2swift (続・自動変換の野望)
Taketo Sano
ObjC -> Swift 自動変換器の開発
デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナーとエンジニアが話す、iOSアプリケーション開発
Kenta Ohsugi
Sumally デザイナー 大杉 健太 / エンジニア 中元寺 武尊 2015/04/14 Apple Store 銀座
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
Taketo Sano
2015/11/11 "iOS 9 Bootcamp" にて発表。
基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先
Taketo Sano
2015/05/22 「第3回プログラマのための数学勉強会」にて発表。 http://maths4pg.connpass.com/event/14367/
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
Taketo Sano
2015/03/27 「第2回プログラマのための数学勉強会」にて発表。 http://maths4pg.connpass.com/event/11781/
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
Kenji Tanaka
iosオールスターズ2で登壇した内容です。
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
Ken'ichi Matsui
「第5回 プログラマのための数学勉強会 発表資料 (2015/11/21[sat])」 内容は統計学の素養がある方には基本的な事項ですが、ベクトルと内積で見方を変えてみたという点と、あまり統計学に親しみがない方にも理解してもらえるようなまとめになっている、というところに本スライドの独自性があると考えていますので、その辺り良ければご覧ください^^
はじめてのiOSアプリ開発 Swift対応版
はじめてのiOSアプリ開発 Swift対応版
Tomoki Hasegawa
5/25 第8回Swift勉強会 ( https://atnd.org/events/64422 )の発表資料です。
Viewers also liked
(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 への「コード&パラダイム」シフト
基底変換、固有値・固有ベクトル、そしてその先
基底変換、固有値・固有ベクトル、そしてその先
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
VC「もしかして...」Model「私たち...」「「入れ替わってるー!?」」を前前前世から防ぐ方法
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
「内積が見えると統計学も見える」第5回 プログラマのための数学勉強会 発表資料
はじめてのiOSアプリ開発 Swift対応版
はじめてのiOSアプリ開発 Swift対応版
Similar to さらに上を目指すための iOS アプリ設計
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
DevLOVE iPhoneアプリ勉強会
DevLOVE iPhoneアプリ勉強会
Toshimitsu Takahashi
e-Learning Design for Teacher
e-Learning Design for Teacher
Sunami Hokuto
2009年02月23日のセミナー(@東京外大)のスライド。日本語教師向けに、e-learning開発事業で押さえるべきポイントと、その前段階としてITに親しむコツについて話しました。
Itca yammer提案110615
Itca yammer提案110615
伸夫 森本
ITコーディネーターの方々へ向けたソーシャルウェア(yammer)活用のご提案です。ソーシャルウェアについて、yammerの機能概略、現場での活用へ向けたワークショップなどを紹介します。
チームで開発するための環境を整える
チームで開発するための環境を整える
onozaty
チームで開発するために整えておくべきと思うことを紹介します。 どんなアプリケーション、開発言語でも共通する基本的なことです。
2019年度 若手技術者向け講座 オブジェクト指向
2019年度 若手技術者向け講座 オブジェクト指向
keki3
2019年度 若手技術者向け講座 オブジェクト指向
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣
loftwork
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort
loftwork
DSLによる要求獲得でスーパーアジャイル
DSLによる要求獲得でスーパーアジャイル
陽平 山口
2011年7月8日(金)に行われた第2回TPS/アジャイル研究会での発表資料です。DSLを中心とする要求獲得がもたらす効果を実例を交えながら解説する内容です。
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
Jurgen Apello による What is Agile Management? の日本語訳http://www.slideshare.net/jurgenappelo/what-is-agile-management
131207 NECTJ Workshop 2
131207 NECTJ Workshop 2
NECTJ
タブレット端末を学習に活かすさまざまなアイデア
タブレット端末を学習に活かすさまざまなアイデア
Naoya Sangu
~ iPadを使った学習支援・生活支援 ~ 「第2回 特別支援教育に役立つ電子情報支援技術の基礎研修と支援機器の実習」発表資料
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
masashi takehara
iQONの開発手法 at iQONエンジニアセミナー
iQONの開発手法 at iQONエンジニアセミナー
Imamura Masayuki
iQON エンジニアセミナー by VASILYでの資料 @kyuns
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について
TomomitsuKusaba
.NETラボ勉強会 2022年1月 「保守性の高いアプリケーション設計について」
Project Management
Project Management
Kazuto Omori
#MSIgnite x Japan Microsoft MVP/RD - Learning story
#MSIgnite x Japan Microsoft MVP/RD - Learning story
Rie Moriguchi
2021年11月2日(火)に開催したMicrosoft Ignite日本語セッション「技術を学ぶその先にあるもの Learning Together, Growing Together」のスライドと、セッションスピーカーを含む30名のMicrosoft MVP/Regional Director(RD)の技術者目線での技術の学びのストーリーをご紹介しています。皆さまの今後の技術の学習の参考にご覧ください。
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
Webpla LLC.
2023年3月28日開催。自然言語処理への夢やChatGPTへの愚痴をこぼしながら、独自ボットの制作方法について実演とともに解説した際の資料です。
社内 DDD 勉強会第1回
社内 DDD 勉強会第1回
shingo suzuki
SRA社内での勉強会資料
2012ー1 TENTOプレゼン資料
2012ー1 TENTOプレゼン資料
TENTO_slide
2012年1月、筑波大学におけるプレゼン資料。TENTOの理念と方法を記述。
Similar to さらに上を目指すための 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プレゼン資料
More from 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
https://arxiv.org/abs/1812.10258
トポロジーと圏論の夜明け
トポロジーと圏論の夜明け
Taketo Sano
2018-10-16 https://cat4pg.connpass.com/event/100728/
Swift で数学研究のススメ
Swift で数学研究のススメ
Taketo Sano
iOSDC 2018 https://fortee.jp/iosdc-japan-2018/proposal/45e3ad74-d815-49eb-8963-5c62e126110b
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
Taketo Sano
https://mspacetopos-summer.peatix.com/?lang=ja
特性類の気持ち
特性類の気持ち
Taketo Sano
2018/04/18 @ https://connpass.com/event/82142/
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Taketo Sano
iOSDC 2017
山手線は丸いのか?プログラマのためのトポロジー入門
山手線は丸いのか?プログラマのためのトポロジー入門
Taketo Sano
#math4pg
何もないところから数を作る
何もないところから数を作る
Taketo Sano
2013-03-22
情報幾何学 #2.4
情報幾何学 #2.4
Taketo Sano
#infogeo16
情報幾何学 #2 #infogeo16
情報幾何学 #2 #infogeo16
Taketo Sano
http://connpass.com/event/25599/
objc2swift (自動変換の野望)
objc2swift (自動変換の野望)
Taketo Sano
ANTLR v4 による、ObjC -> Swift 自動変換器を作る試み。
2015 02-18 xxx-literalconvertible
2015 02-18 xxx-literalconvertible
Taketo Sano
let UIWebView as WKWebView
let UIWebView as WKWebView
Taketo Sano
iOS 8 で導入された WKWebView と、7 以前で使える UIWebView を、ソースを綺麗に保ったまま同居させる方法。 2015/02/14(土) 「iOSオールスターズ勉強会」にて発表。 http://eventdots.jp/event/311301
コードを書けば複素数がわかる
コードを書けば複素数がわかる
Taketo Sano
コードで2次元ベクトルから複素数を構成し、iOSシミュレータ上で複素数を動かしてみる話。「情報科学若手の会冬の陣2015」にて発表。
虚数は作れる!Swift で学ぶ複素数
虚数は作れる!Swift で学ぶ複素数
Taketo Sano
ひろ子 in Objective-C
ひろ子 in Objective-C
Taketo Sano
Objective-C が好きになる Tips & Hack
Objective-C が好きになる Tips & Hack
Taketo Sano
ヤフー vs クラスメソッド「iOS 炎の7番勝負」にて発表 http://dev.classmethod.jp/news/yxcm/
Konashi で始める iOS 電子工作
Konashi で始める iOS 電子工作
Taketo Sano
下位互換コード隠蔽のストイシズム
下位互換コード隠蔽のストイシズム
Taketo Sano
サンプルコード: https://github.com/taketo1024/iOS6CompatibilizerDemo
More from 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
Download now