iOSDC 2019
Advanced Segue
Custom Segue については資料参照のこと
ライブラリのインポートとリンクの仕組み完全解説
ライブラリのインポートやリンク時に謎のエラーに悩まされるのを解決したい
ツールの方が使う脳は簡単だけど、問題解決が困難
どの手段を利用しても、インポートの設定は利用者に任されるので、利用者が知識を持っていた方が良い
難しさ
種類が多い...
静的リンクか？動的リンクか？
DLか？パッケージマネージャを使うか？
また、アプリケーションプログラミングよりも低レイヤーの知識が必要になる
Library の形式には、ざっくりと以下がある。Framework とその他は以前はアイコンで区別がついたが、最新の macOS では見分けがつかないらしい。見分けるためには file コマンドを利用すると良い。 Dynamic/Static の2種類がある
これらの中でも、例えばプラットフォーム毎の違いや、言語の違い等があり、Library の違いはその掛け算分そんざいするが、各々の違いの組み合わせを考える必要がある、という場合は少なく、基本的には各違いを独立して意識すれば問題解決できることが多い。 Static/Dynamic の違いは、シンボルの解決がコンパイル時か？ランタイムか？の違い。Static の場合は一つのバイナリに固められるが、Dynamic の場合は Framework 自体がコピーされ、実行時に参照される。基本的には、Dynamic の方が柔軟で、多くの場合使いやすい。Static だとシンボルの衝突を回避しながらリンクしていくのが大変。 インポートとは？
Xcode のプロジェクトにおけるインポートは、他の言語におけるインポートとは違う。例えば、Ruby なんかのインポートは動的なので if 文で分岐ができるが、Swift は コンパイル時 インポートとは？
Xcode が暗黙的にやっていることを観察して、どうやったらインポート, リンクできるのか明らかにしてみる
インポート: 外部ライブラリを自分のコードベースで利用する言語きのう
Ruby とうは動的にできるので if で分岐などできるが、Swift hあ無理
ビルド時 (コンパイル時) に解決できる必要がある
リンク: コンパイル後のオブジェクトファイル, 外部ライブラリを連結する
コンパイル後に行う
全てのシンボルを解決される
リンクとは？
確認したい場合:
Xcode を利用して外部ライブラリを利用可能にする Embbed framwrodk にDDするだけ
コードから import する
ビルド > リンク > 実行しても問題ない
Linked framework and libraries にも入る
リンクせずに embed するというのはありえない
逆は静的ライブラリ
diff をみるとプロジェクトの差分も結構でてる
Build phase が追加される
Xcode 11 の場合、プロジェクトディレクトリ内に Framwork を持ってきてないとハマるかも
コピーしてくれない
dylb: ダイナミック隣家のプログラムの名前
ファイルを消していく
import も compile も成功する
リンク時点では発生する
モジュールとは？
インポートするのに必要。public な API の宣言の集まり
header を module としてまとめる
Swift では自動生成
import はモジュールに対して行われている
Modules ディレクトリ内にある
.swiftmodule, .modulemap
module stablity？
swift moduel？
Framework バンドル街でも良い
module を持ってないと import できない
必要なら自分で書いて Framework バンドル街に置く
swift include path を設定する
Module Map, Bridging HEader
Bridging-header: シンプルだが、import 出てこない。アプリケーション全体に作用する
module map: 上位互換
リンクできたけどインポートできない
ABI Stabilliry
Module Stabiliry
リンク
プラットフォームが違うとリンクに失敗する
変数化したり, fat binary 作ったりで解決できる
XCFramework: いくつかのフレームワークをまとめるコンテナフレームワーク
Q:
クリーンコード
Bob おじさんの話
kickstarter の OSS アプリ勉強になって良い
Protocol を中心に、Generics の話
Start with a protocol (in WWDC2016)
具体的な型から考えていき、Protocol をあてはめていく
具体的な解決策を、ジェネリックな解決策にあてはめていく
retroactive modeling
protocol のパワーの一つ
URLSession 以外で利用することが難しい
mock のためだけではなく、ジェネリックな問題解決のために Protocol を利用すべきではないか？
Foundation のみ利用することで、他の機能の追加、拡張や、モックがより簡単になる
PAT使う時
associated type には制約がある
protocol を配列として使うか？
protocol の設計と使用目的があっているか？
最初から generic にすると、逆に重複が増えたりわかりにくくなったりする
protocol よりも、generic な struct の方が良い場合がある
BLE
Slack で実況しました
サービスデザイン
Motivattion
デザイナ不足なので自分でやらないといけない
開発者とデザイナの認識が違う
Design System
パターン等、デザインの共通言語を作る、ということ
メリット: 一貫したデザイン, UX の提供. 知識の共有
Example) TED, Airbnb, Bootstrap, Human Interface Guideline, Material Design
TED は開発チームに割と委ねられていた
Airbnb はデザインチームが完全に決めていて、それに従って実装する
Design System って？
決まった形式はない...?
共通しているのは 思想 = デザイン原則 という気づきを得た
プロダクトを作るときに大切にしてほしいこと
スマホにおける Design System
HIG, Material Design 飲みじゃダメか？
無機質なものになってしまうのでは...?
サービスの特色が現れない
サービス特有の事情にも目を向けたいね
スタイルガイド
どう管理するのがよい？
意味を持った命名をつけて管理するのが良いはず
パターンライブラリ
視認しやすいように管理するのが大事
コミュニケーションしやすいように管理したい
Pococha での Design System の事例
デザイン原則の事例をだーっと紹介してくれている
スライドを見るのが良さそう
スタイルガイド:
コード化, 視覚化
XcodeGen を利用する
パターンライブラリ:
これもコード化, 視覚化
具体的にどう運用しているのかが木になる
Sketch で定義するのではなく、
yaml に何を書いているのか？その色に対する意味となる言葉を書いている
コードにベタがきではないのは...
フォントや色の意味と具体的な値の組を書いている
更新は開発でやる
定義はデザイナーやチームでやる