iOSDC2020 day2(9/21)
iOSDC 2020 day2のレポートです(随時加筆予定).
day1は↓
Track A
詳解Storyboard
WWDCでもSwiftUI激推しだったし, もうStoryboardの時代終わりじゃね?
って思ってる人にこそ見て欲しいセッションです.
SwiftUIにいきなりフルリプレイスは難しいので少しずつ移行していくのが現時点では現実的で, そのためにUIHostingControllerを使ってみましょうという内容からスタート.
UIHostingControllerは内部にSwiftUIを持つことができるUIViewControllerで, StoryboardのObjectにもあるものです.
つまりStoryboard上でUIHostingControllerにSegueでつなげばStoryboardからSwiftUIへの遷移が可能になります.
ではどうやってUIHostingControllerに初期rootViewを入れるといいかと言うと, IBSegueActionを使います.
SegueをViewControllerのコードの方にCtrl+ドラッグするとUIHostingViewControllerのイニシャライザ付きでIBSegueActionのコードが生成されます.
その他にも
- Restoration
- Storyboard分割
- Localization
- First Responder
- OSバージョンごとのStoryboard(Custom segue)
- Size Classes
- Object
と, てんこ盛りの内容ですが, 一つ一つ説明が丁寧ですし, こんな機能あったんだと思うこと間違いなしです.
このセッションを聞くだけでStoryboardに関するぐぐらびりてぃがかなり向上すると思われるので, スライドor(アップロードされたら)動画を見てみることをおすすめします!
参考
Track B
Webとネイティブアプリの付き合い方を改めて考える
iOSDCでは珍しいWebに関するセッション.
Webとネイティブの比較だけでなく, PWAやApp Clipsにも言及して比較されていて, 意識的にキャッチアップしないとなかなか普段触れられない内容を知れておもしろいかったです.
Web, PWA, ネイティブ, App Clipsそれぞれプロコンを紹介されていて, 「どれか単一でリリースするのではなくて, 複数(例: Web ＆ ネイティブなど)するのも視野に入れることで, 互いのプロコンを補い合える」と話されていました.
たしかに, プロダクトを作る時においてはどれか単一で実装することで検討されがちですが, リソースが許すのであれば複数実装するのも選択肢だなと.
参考
Track C
「それ、自動化できますよ」: note を支えるワークフロー大全
noteさんの社内での自動化事例を紹介してくださるありがたいセッションです!
Zapierを使う上手に使うことでメールのタイトルや本文の内容をトリガーにしてワークフローが起動するなど, ピタゴラスイッチが上手く機能していておもしろいです.
ちなみに「メールのタイトルや本文の文言をトリガーにすると, メールの内容が変わった時に困らないかなー.」と思い, 発表者のlaprasDrumさんにDiscordのボイスチャットで質問してみたところ「そういったこともたまにあるけど, 頻度はそんなに高くないからたまーに追従するだけでいいですよ.」とのことでした.
また, 同じチャンネルにいらっしゃった岸川さんが「メールの変更自体を検知できるような機構を用意しておくと良いですよ.」といったことも教えていただきました.
laprasDrumさんも「Zapierにはタスクが失敗したらメール通知してくれる機能があって, タスクヒストリーを追うと失敗の原因も割と簡単にわかるので追従も重たくないですよ.」とおっしゃっていました.
参考
XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する
UITest辛い! わかる!
いつの間にか壊れている!
こんな辛みを乗り越えろというマッチョ?なタイトルのセッションですね笑
発表者の佐藤さんが所属するメルペイでのXCUITestの導入順序や実例, 実際のXCUITestの使い方の初級的内容から実践的な使い方としてPage Object Patternまで丁寧に説明されています.
(自分もPage Object Patternの簡単な導入記事を過去に書いているのでよかったら覗いてみてください.)
その他にも
- 効率よくするためにアニメーション消そうね!
- XCUITest実装者が100%嵌る罠
- 継続的にテストしていくには?
などなど盛り沢山な内容ですが, 実例を交えつつお話されているのでとてもわかりやすいです.
参考
Synchronized iPhones, Again!
D トランフ◯「Make America Great Again!」
と聞こえてきそうなセッションタイトルですね笑
セッションの初っ端から30台のiPhoneを同期させるというデモンストレーションを見せられて驚愕!
と思ったらARでした(それでもおもしろかったけど)笑
VideoMaterialを使用することで物体の表面上に動画を流すということが簡易的にできるようです.
VideoMaterialについてぐぐって見ましたがNo Overview Availableでした笑
そしてそして, ARは前座だったようで途中からは実際にBluetoothにより同期する本編に入ります.
が, Bluetoothはそもそも5台くらいとの通信前提なので, 30台同期は素直にやろうと思うと難しいとのこと…
しかしWWDC2019のネットワークラボで質問をしてみたところ「Multipeer Connectivityを使うと良いよ」という回答を得られたそうです.
Multipeer Connectivityだと複数セッションを持つことができ, 1セッションあたり8台ほど接続可能みたいです.
最後には改めて(ARじゃない)iPhoneの同期デモを見られて感動です!
余談
紙でできたかわいい猫のお面を被って登壇されていたのですが, 途中息苦しさから酸素を意識的に取り入れられてて笑いましたw
参考
Track C
iOSアプリ開発のための”The Composable Architecture”がすごく良いので紹介したい
The Composable Architecture(以下TCA)という聴き馴染みのない(少なくとも僕は初耳)アーキテクチャの紹介でした.
Swiftでのアプリ開発に用いられる人間工学を考慮(すごい)したアーキテクチャのようですが, なんとSwiftUIとも相性のいいもののようです!
状態管理を行うStateをReducerからしか扱えない制約があり, Reducerは分割可能でFat Reducerを回避できる設計になっているのが特徴で, たしかにヒューマンエラーを起こしにくい構造になっている気がします(実際に使ってみてはないので, 実感値はないですが).
また, サンプルにテストの書き方を提供してくれているようで, テスト初心者にも優しい!
これは完全に余談ですが, 発表者の今城さんがミー文字を用いて発表されていてご本人の顔が見えないことが理由なのか, 途中で声優の杉田智和さんの声に聞こえてきて「銀さん？！」って時々なりました笑
参考
Swiftで始める静的解析！
Swiftにおける静的解析といえばSwiftLintが有名かなと思います.
僕もとてもお世話になっています.
しかし, 静的解析ツールは自作することも可能です(僕はしたことありません).
このセッションではSwiftSyntaxというライブラリを用いて実際に静的解析を自作していく過程を丁寧に説明されています.
実例はコードクローンを発見して警告を出すというもので, IntelliJにはあるけどXcodeには無い静的解析のようです.
SwiftSyntaxの用い方から, そもそも静的解析がどのように行われているのかも説明してくださっているので, 初心者の自分でも理解できてすごくおもしろかったです!
参考
Firebase Dynamic Links で既存のユーザーだけでなく、潜在的ユーザーにも体験を提供したい！
Firebase Dynamic Links(以下FDL)の機能説明や導入方法から丁寧に説明されているセッションです.
私も普段から最もお世話になっているFirebaseの機能の一つです.
動画などの資料を用いたり, 類似技術のCustom URL SchemeやUniversal Linksとの比較などもあり非常にわかりやすかったです.
実際にSwiftコードで処理を書く事例や, FDLの動的生成する時のサーバー側のお話などもされていて, FDL使ったことない人はこのセッション見てみると導入がスムーズだと思います!
※ 補足
これは注意した方がいいです.
また, これは僕の経験上のお話なので, もしかしたら解決策的なものがあるかもしれないですが一応共有しておきます.
参考
テストコードが増えるとバグは減るのだろうか？ — 「0% → 60.3%」で見えた世界の話
- 実は仕様が決まってなかった…
- ここ昔の人が書いた部分で手をつけたくない…
- 自分の書いたコードは問題ないだろうか…
あるあるすぎますね.
これらを解決していく手段の一つがテストコードというセッションです.
テストを書くことのプロコンについて言及されていたのですが, 特に僕が共感したデメリットが「テストコードが神格化される」です笑
これ, けっこうあると思うんですよねー.
テストを書くことにより受けられる大きな恩恵はもちろんあるんですけど, 全知全能の神ではないことを常に意識しなきゃいけないですよね.
実際, テストを書いたからと言って解決しない問題はありますし, テストコードを書くこと自体には工数もかかるので「テストコードを書くべき場所, 人力(QA, PRレビューなど)でやるべき場所などを適切に考える必要があるなー」と改めて感じさせられる内容でした!
参考
よっかたらClap & Twitterフォローしてくださいー
