potatptips#39 に参加した
iOSまとめ枠として参加してきたのでまとめつつ復習。
Learning Firebase
@jpmartha_jp
firebase勉強する方法に関する発表 try!swiftで中の人と話した時に、勉強法に関してアドバイスを貰う
firebaseを勉強する道具
- カンファレンスとかミートアップ
- iOS/Android guide
- iOS/Android Codelabs
- udacityのコース
技術本執筆の勧め
@shhihochangdesu 技術本執筆の経緯、執筆のつらみ、執筆のうまみなどについて
業務と並行で進めるのは非常にきつい
年末年始とクリスマスは消滅した
つらみについて
報酬<つらみ
つらみのほうが大きい 十二人で執筆したため、報酬は12分割された
うまみについて
自分が勉強せざるを得ない環境。 間違ったことは書けないため、すごく勉強した
まとめ
執筆は怖くない 2つのOSに関連した本を書くと業務も簡単にスイッチできる
swiftのstructのstored propertyはvarにしよう
@omochimetaru
http://qiita.com/omochimetaru/items/7265e440418b38088ccb
概要
structのメンバを宣言する時、letとvarのどちらを使うべきか迷う時はどうするという話。
結論から言うと、varにすべきである。
共有とimmutabe
mutableなクラスを複数のオブジェクト間で共有すると、意図しない変更が他の共有者から与えられてしまう。
しかし、structは値型なので、複数のオブジェクト間で共有することができない。(各共有者には値のコピーが保持される)
structはimmutableな挙動をするため、上記のような共有に関する問題が怒らない。
共有とstruct
structは共有不可能なので、メンバとしてvarを用いても、共有によって起こる問題は発生しない。
よって、structのメンバの宣言にはvarを使っても問題ない。
UICollectionViewDataSourceはViewControllerと別にして実装しないほうが良いと最近思う
@yimojo
UICollectionViewにおけるアンチパターンを何とかする
過去の自分の間違った取り組みをアンチパターンとして広める。
アンチパターン
CollectionのViewとDatasourceを分離することは良い。
しかしDatasourceとdelegateを分離してしまうとアンチパターンと化す。
ViewController の肥大化対策としてやってしまいがちだが、これを行うとすごく触りづらいものになってしまう。
責務について
Datasourceの責務、データとViewの提供はViewControllerでやるべきことである。
VCからUIKit系のdelegateを分離しすぎてもコードは肥大化する。
まとめ
Datasourceそのものからデータ部分だけを取り出して、別のDelegateとして切り出す。 その際、Viewについては考えない。
d_date speakerdeck.com
概要
Swift4で変更される言語仕様に関する話。 github.com
@objcの変更に関する話
これまでの@objc
SwiftのコードをObjective-Cから呼び出す際に、@objcをつけることで、明示的に宣言できる。
@objcを明示的に書かなくても良いように推論していた箇所が変更される。
その推論によって、一部のinitializer宣言に必ず@objcの記述が必要になるなどした。
これからの@objc
推論が減る。
これにより、NSObject由来のクラスやdynamic修飾子の付いたメソッドなどに対して推論が行われなくなる。
@objcmembersの導入
XCTestなど、クラス全体が@objcである場合は、@objcmembers修飾子を用いる。
Swift4移行の最小手順
- 警告の解消
- 実行時にクラッシュする箇所の修正
冴えないuserinfoの育て方
@lovee speakerdeck.com
UserInfoについて
Dictionary<String:Any>という型の変数。 UIKitにおけるデータのやり取りで、NSErrorやNSNotificationなどのあらゆる場所で活用される。
問題点
String型をキーに取り出すため、値の方がわからない、わかりづらい。
解決策
Dictionary<String:Any>のまま利用せずに、独自型を定義して使う。
EnumやStruct、Set