見出し画像

iOS DC 2019 参加レポ - domonr

※ほぼ自分用メモです。

画像1

# Day0

## SwiftのStringの文字数の数え方を完全理解する 30min

https://speakerdeck.com/taka1068/swiftfalsestringfalsewen-zi-falseshu-efang-wowan-quan-li-jie-suru
https://fortee.jp/iosdc-japan-2019/proposal/80d31384-c8e6-4813-8b6b-568ed0eb9b20

StringのIndexはString,Indexだよ!Arrayのindexとは違うよ。
StringはArrayよりちょっと扱いにくい…
StringはUnicodeに忠実であろうとするためにめんどくさい仕様になっている。
絵文字はUnicodeScalarが複数持つものもある。
ぱもUnicodeScalarを2つ持つ。はと◯。
UnicodeScalar2つで国コードを表すことができる(JPとか)
先頭のUnicodeScalarから順に文字を決定するため、後半の文字であればあるほど計算量が増える。
Stringが添字アクセスでSetできないのはMutableCollectionに準拠していないため。
1文字あたりのバイト数が違うので、Intの添字でO(1)で計算できない。常にO(n)。


## ダックタイピングとidでUserDefaultsをモック化する 30min

https://fortee.jp/iosdc-japan-2019/proposal/873b4cdb-4c92-4111-bf0b-67a67dbb242e
https://speakerdeck.com/417_72ki/datukutaipingutoiddeuserdefaultswomotukuhua-suru

ob-cの型システム。実行時に方をチェックしないので違うClassを入れても実行時にCrashする。
delegateはこの弱い型付けを用いた実装方法。
ob-cのoptionalはおそらく、メソッドが存在するかどうかをチェックするメソッドを用いて実現しているのでは?
id型はなんでもありなので柔軟性のあるコードを書くことが可能になる。
弱い性的型付けと実行時に方のチェックをしない仕様を使って黒魔術をします。
以上の記述を使用してUserDefaultsのMockを実現するライブラリが以下。

MockUserDefaults
https://github.com/417-72KI/MockUserDefaults

画像2

# Day1

## 色の難しい話に負けない体づくり60min

https://speakerdeck.com/s_shimotori/iosdc-japan-2019-60-mins-for-color
https://fortee.jp/iosdc-japan-2019/proposal/760a3747-b7d3-4b1a-a141-85a93a31f66d

コントラスト比大事ですよね。ただ、計算式が複雑なので毎回計算するのは非現実的だよね…
SwiftのUIcolorのイニシャライザっていっぱいあるけど使ってる?(RGB指定ぐらいだよね…)
iPhoneのディスプレイは48bpp!なので各色12桁あるw
RGBはディスプレイから出る光のバランス。
人間の細胞を考慮したパラメータが三刺激値。
RGB刺激値を使いやすくXYZ刺激値にして、XYZ表色系を作成。Yは輝度(物理的な明るさの値)。
ガンマ値:色にどのぐらいの補正をかけるか(基本全てのものにかかっている)
RGB色空間:古い
DCI P3色空間:映画で使ってる
Display P3色空間:DCI P3 と同じ範囲の色が使えて、RGBっぽいガンマ補正がかかっている
SwiftでDisplay P3色空間用のイニシャライザもあるぞ!(使うとちょっと色が鮮やかに!)
Macなら color sync utility で遊べるよ!
WCAG (アクセスビリティのドキュメント), 色、コントラスト、資格花瓶、(視力、視野。)https://waic.jp/docs/WCAG20/Overview.html
色覚異常(男性は10%ぐらいいるかも)。先天性は赤と緑が苦手、後天的(加齢)は青が苦手がち。
青と赤ならだいだい全員判別可能!(グレイスケールで確認して、色が同じ場合は何かしらのたいsカウが必要そう)
コントラストとは、色の差異。(コントラスト感度は人によって違う)、4.5:1以上を目指す!
視覚過敏:明るい色を見ると目や頭が痛くなる(白背景だと目の負担がでかい)
ダークモードのメリット
- 目に優しい、バッテリー消費量を節約できる
液晶ディスプレイは常に光を出している(XR)。有機ELの場合は色を発しているので黒いと光量を節約できる(XS)
色反転機能≠ダークモード

プロジェクトでやってる? → プロジェクトでは年季が入っているので厳し目><

## Swiftクリーンコードアドベンチャー ~日々の苦悩を乗り越え、確かな選択をするために~ 30min

https://fortee.jp/iosdc-japan-2019/proposal/0c06aeca-5b6a-4bbe-aeeb-7531740975c5

コードを書く時間より読む時間のほうが長いよねー
ただ、コードの正義はたくさんあるので統一するのは無理だよね…
わかりやすい-安全である-変更に強い(Start With a Protocol)
ジェネリックにする必要がなければする必要はない。タイミングが大事。
1つの機能を持つ(1つしか持たない)Protoocolを作成するといい感じ!
Protocolは強力だけどジェネリクスの方がいいときもあるよ!
コードを書くときは書く前よりもきれいにして帰ろう!(ボーイスカウトの原則より)

## 画像処理における、UIImageとCGImageとCIImageの効果的な使い分け ~ 30min

https://fortee.jp/iosdc-japan-2019/proposal/3c30c4b4-a647-4198-8e8c-e8100293ee93
https://t.co/u1wObao3xb

カメラの性能向上で画像認識しやすくなっている。
画像処理への入力はUIImage(要圧縮)
画像処理でいちばん大事なのは前処理。
CIImageをできるだけ使いまわして、必要なところ(InとOut)でUIImageにする。
リサイズをCIImageでやるかUIImageでやるかは曖昧。どっちでやろか。
CIImage(Core Image)
- 画像処理ができる。Metal後敷なしにGPUの恩恵を受けられる。ImutableなのでマルチスレッドでもOK
- 遅延実行されるので注意(よくわからん)
CIImageでのリサイズ処理はCIFilterを使う(CGAfinTransformでも可)。
UIImage
- Imutable. png, jpegに最適化されている、
iOS9だったらcontextデリサイズ
iOS10だったらoptionalじゃなくて生成できる。UIGraphicsImageRenderer。(UIImageのリサイズならUIGraphicsでやるなあ)
結果 → CIImageを使ってリサイズしたほうが早い。アフィン変換が一番早い!UIGraphicsImageRendererが意外と遅い….
ただ、品質が処理ごとに違います(特性があるので一概に品質の善し悪しではないので目的に合わせてリサイズしたほうが良いかも)。
(CGInterpolationQualityをどれ使うかでも変わりそう、バイキュービック法(CIBicubicScaleTransform)は輪郭が強調される 文字や漫画の拡大だとこっちの方がいいのかな、多分UIImageはUIGraphicsBeginImageContextWithOptionsを使えば早くなりそう、UIImageにはCIImageが入っているかCGImageが入っているかわからないらしい)
AppleのDocumentを見てもそれぞれの変換時の特徴があんまり書いてないのよね

## FatViewControllerを安全に書き換える方法が見つからなかったので、どういう痛みを許容するか考えた 

https://fortee.jp/iosdc-japan-2019/proposal/123b9027-1aea-4557-997e-fd2c5275974b

自動テストを入れないとプログラムを書き換えるのが怖いが、自動テストを入れるためには設計を書き換える必要がある…
いい感じなやり方でがんばったので共有します〜
UITestが良いかなと思ったが、E2Eだと実装コストが高すぎるンゴ…
BDD→ユニットテストを実装したらいらなくなりそう& メンテナンスコスト高そう…
一時的な手動テスト→手戻りがあったときのコストが高い…
結果、一時的な手動テストで乗り切りました(ただ、手戻りが発生してつらかった)
今後はつらいのでリグレッションテストを入れないと!
 → 責任者的にアプリの絶対的に必要な機能は?(例:決済機能、商品購入機能)
 → それ以外は一旦バグってもまぁええ
痛みを許容する時
いきなりすべてを網羅して完璧なものはできない。段階的に進めていくしか無い。
テスト範囲外で起きたバグはしょうがない。(ポストモーテム)
テストの戦略を考えるにあったってチームで共通認識を持っていたほうが良い。

## 詳解 Auto-Renewable Subscriptions

https://fortee.jp/iosdc-japan-2019/proposal/723b458a-2b5d-41a1-bec5-2cd5ccf722c0
https://t.co/q5sFWhz8PB

defereedは24時間立つとfailedになったりする
UIへの反映とtransactionの処理は完全に別々に動かしている
購入完了画面はいつ呼ばれても良いよにmodalで実装しているといい
課金周りは絶対リジェクトされる(ぐらいの気持ちで行かないと痛い目を見る)
sandbox環境のテストアカウントで使い続けると購入に失敗することがあるんだけど
→ たくさんアカウント作っていくしか無い。テストしまくるのでレシートが不正な状態になりやすい
リジェクト理由
→ 金額をボタンに表記しろ!課金画面に必要な情報を
ライブラリ使ってます?
→ 使っていない。必要性を感じないため。課金を他人に委ねるのは怖い
サーバー側のこともiOSエンジニアがキャッチアップしてます?
→ サーバー側もアプリ側も全体的に把握している。お互いにキャッチアップする必要がある。

## 動画アプリの投げ銭機能における消耗型課金の仕組みと実装 30min

https://fortee.jp/iosdc-japan-2019/proposal/d2ce8e9f-6294-45da-912f-2246dba78401
https://speakerdeck.com/nonchalant/iosdc-20190906-dong-hua-apurifalsetou-geqian-ji-neng-niokeru-xiao-hao-xing-ke-jin-falseshi-zu-mitoshi-zhuang

消耗型は再購入するとレシートが上書きされていく。次の購入をするまでは一応レシートに記載される。
まぁ、1回ミスったら取り返しはつかないよね。finishTransactionするまでは残り続ける。
なので、インセンティブを付与するまでtransactionを終了しないでねとAppleは言っています。
非消耗型課金のほうが実装大変だけど、消耗型課金の方がミスった時やばいよねw
複数の未処理Transactionができると困るので、未処理Transactionがあるときは新しいTransactionを生成しないようにする。
レシート検証失敗を手で頑張ろうとするとつらいので、必ず失敗するデバッグモード作っておいたほうが良い

# Day2

## 実践 CallKit/PushKit ときどき🐛退治 30min

https://fortee.jp/iosdc-japan-2019/proposal/1682af8a-9c94-4040-9f0c-086c81aea9a3
https://speakerdeck.com/monoqlo/iosdc-2019

CallKit: iOS6ぐりいからある。OS標準の電話を起動できる
PushKit: iOS8から使える。バックグラウンドで起動してくれる?5KBのデータを送りつけられる。
Twilio: VoIP通話ができるWebサービス。SDKとかもろもろあるYO!
サンプルみたいならTwilioのサンプルを見ればOK!
CXProvider: システムからの要求をアプリに伝える。PushKit → CallKit, CallKit → PushKit
CXCallController: アプリからの要求をシステムに伝える
CallKit Tips: AppleのDocumentから感じるしか無い…ひたすら実機で動作確認しながら理解していくしか無い….
 後で通知ボタンってなに?→リマインダーに登録するだけ 選択肢も固定ここの挙動は非表示も含めてカスタマイズができない
PushKitTips: p12しか使えないので毎年証明書を発行する必要がある….
着信画面の確認はコードで強制的にメソッドを実行すれば起動できる!
Twilioで自動音声流す機能があるので、それでDebugするといいYO!
割り込み通話気をつけないとあかん: 保留を強化しない手もある!アプリがフォアグラウンドになったら保留を終了する手もある!アプリに保留ON, Offボタンを置いても良い。
 → バグ()
手動で結構テストしないといけないので通話周りは大変

## すべての人のためのアクセシビリティ対応 30min

https://fortee.jp/iosdc-japan-2019/proposal/940b3857-749f-4f9e-a740-71761fe53627
https://speakerdeck.com/akatsuki174/subetefalseren-falsetamefalseakusesibiriteidui-ying

障害持ちの人だけでなく万人に便利に使ってもらうための工夫
ユーザビリティ≠アクセシビリティ
アクセシビリティ対象者意外と結構いるぞ!850万人ぐらい。
視覚、色覚、聴覚などなど…
SwiftUIで楽になる!(SwiftUIが大変?
みんな使ってくれなさそうだけど → アクセシビリティ対応したときの使いみちをちゃんとイメージできてる?できていないと流石に意味ない
ズーム機能:拡大鏡
AssistiveTouch:画面にボタンが置いてあってショートカットを設定できるやつ
LEDフラッシュ:電話着信時にフラッシュをたく
色を反転:ダークモードではないけど、色をまるっと反転(スマートは画像はスルー、クラシックは画像の色も反転)
dynamictext, voiceover…
タップ領域は44pt * 44pt、要素を密集させない(ごタップ防止)、色に頼りすぎない(リンクに下線、オンライン・オフライン時に形も変えるとか)
コントラスト比意識してくれー。極力文字を画像にしない(DynamicTypeとか色を反転とかに対応できない)
スタイルに一貫性をもたせる(当たり前か)、閃光とかは危ないよ!
Accessibillity Inspecterでチェックできます!
Dynamic Typeを使うにはTextStyleを設定しなくてはいけない….(デザインちゃんとしてないとできないね…
iOS13からAppleもアクセシビリティに力を入れてるよー
Dynamic Typeに関して開発者がやるべきこと
- Text Styleを設定する(フォントのスタイルを)
- AutomaticallyAdjustsFontをtrue
iOS11以上で画像もDynamic Typeに合わせてサイズを調整できる!
Dynamic TypeはまじでLayoutくずれるんだよね…テキストがよりすぐ見切れちゃうもんね…
→ maximumPointSizeを設定していればMaxを指定できるよ!
色覚異常対応のときは、Chromatic Vision Simulator を使えばOk!
Siriショートカット: iOS12以降で使用可能
 良いショートカット
- 主要機能にすぐアクセスできる
- 繰り返し使うものにアクセスできる
- 条件によらずいつでも実行できることを担保してあげたほうが使いやすい
VoiceOver対応
- UIkitは基本問題ない
- 画像は画像名…
- km/hとかはキロメートルスラッシュエイチになっちゃう
- AccessibilityLabelを設定すればええんや!(Hintも設定できるよ!
良いAccessibilityLabelとは
- シンプルに!ラベルとかボタンの文言は別で設定されるので不要!英語は大文字→ピリオドにしとこ!
- コンテキストに沿っているかどうか(同じ画像でも場所によって違うよね)
VoiceControl
- あんまり情報無いけど触ったら面白いで!
SwiftUIなら最初からアクセシビリティ対応できてるぜ!
デザイナーにもちゃんと共有しようね!アクセシビリティ社内勉強会とかしよう!
料理中とか手が離せないときにVoiceOverで操作せ切ると便利だよねーとかはあるよね
VoiceOver対応アプリ:freee

## LT

終わるとドラ?が鳴る

### 俺たちのARKitでめちゃめちゃ表情豊かなVTuber向け表情トラッカーを作るぞ 

https://fortee.jp/iosdc-japan-2019/proposal/b9fb9fac-d193-4ed1-9740-496b7ac332bc

Pixivさんのライブラリを使ってる?
TrueDepthカメラ+ARKit+Unityで60fpsでVtuberやってる
首から下げるやつは4500円で買ったらしい(意外と高い)

### iOS 12以下でDark modeに対応した地獄の話

https://fortee.jp/iosdc-japan-2019/proposal/0a4ff74b-01fb-4054-938e-0fac9c8c6e03
https://speakerdeck.com/fromkk/dark-mode-iosdc-2019

ダークモード:暗い背景に明るい文字
ColorSet(ライブラリ)、Rxっぽい感じで色を全般しているらしい
↑を使ってダークモード実装したら一部しかならない…
対処方法:
- interfacebuilderでの直指定はだめ
- 画像は差し替えるかTintColorで対応
- 背景も意識する必要あり
- SafeModeとか画面回転とか意識してないとあかん

### Swiftのスタック変数とCPUレジスタの関係を読み解いた

https://fortee.jp/iosdc-japan-2019/proposal/c2a89fff-ce66-4821-b2d4-4b7b6ff293d5

値型ローカル変数はスタックメモリを使う
レジスタ→CPU内のメモリみたいなもの、メモリより早く容量はめっちゃ少ない
→ c++がわかってもSwiftコンパイラのコードが読めるわけではない
LLVM IR: Bitcode的な?
よくわからないけど簡単な計算時はメモリ書き込みしていないって!

### モノレポで複数アプリをリリースする場合のGit運用戦略 

https://fortee.jp/iosdc-japan-2019/proposal/9a13322e-7627-4b60-997e-31e5098ab146

同じ機能画面を他リポジトリと共有できる!?モノレポ管理。
XcodeGenを使う。
めっちゃ良さげだけどやり方わかんねぇww

### SwiftUIでの開発に向けた我々が出来る既存アプリのリファクタリング

https://fortee.jp/iosdc-japan-2019/proposal/faddde97-b0bc-411b-833b-4f2dd7b646c1

Viewからロジックを除いておこう
UIKitとSwiftUiは共存可能なので、パーツを細かく分ければいけそう
コンポーネント化してれば好きなとこだけSwiftUIでエンジョイできる!
VCのみSwiftUI化とかオススメ、

### ARKitの壁認識で、壁にぶち当たった話 

https://fortee.jp/iosdc-japan-2019/proposal/b6608d85-d7c6-4c71-8560-c38ded225d3d

ARKitマスターになりたかったのでエンジニアになったぜ!
特徴がない壁は認識できねー
→ 床からバーチャルな壁を生み出した!(三角関数とか使えば楽勝だぜ!
壁作成Masterじゃないと壁が作れない問題w
ガイドとかいろいろ頑張ったけど無理だった….
ARアプリはさっさとユーザーテストしたほうが良い。
ユーザーはARアプリを使ったことがないのでまじでハードルを下げないと使ってもらえない
(例;手をかざすだけで行けるぐらいじゃないと無理
最終的に床だけ認識してポスターをかけるようにしたらうまくいった!(壁認識する必要なかった…

### iOSDCのプロポーサル判別器をつくろう

https://fortee.jp/iosdc-japan-2019/proposal/f48c494e-0ae2-468b-bb8e-57fcef43e499

プロポーザルはタイトルと概要さえあれば行ける
プロポー雑判別機は無理だったので、生成器をつくりましたw
スクレイピングしてpythonで形態素解析してがっばってみたが日本語がむずい
→ Google翻訳で英語にした
いろいろやったけどプロポーザルは真面目に書いて出したほうが良い
弊社ではiOSエンジニアが集まって、プロポーザルを相互レビューする会を開いたりしています。←これが最強そう

### Write the "code", Change the world. 〜エンジニアと法律〜 

https://fortee.jp/iosdc-japan-2019/proposal/7b99f91a-25e0-4d9c-b05f-fec111c11693

1年ぶりにiOS界隈に戻ってきた話
ブロックチェーンだと責任者がいないので現代社会ではダメそう…
write the code(法律)するしかない
適切なルールを作る役割の人に技術的な情報を適切に渡すべし

### Getting Started with Swift WebAssembly 

https://fortee.jp/iosdc-japan-2019/proposal/3c48cd53-0539-4793-8367-11a4d9efbc9f

WASM:Webアセンブリ
Swiftは独自のLLVM属性を使っているので仲間はずれにされている
Swift側で対応必要なので結構先になりそう
LLVM→WASMの変換は既にある(ゆえにRustやClangではWASMを吐ける)が、Swiftは独自のLLVM属性を拡張しているので、現行吐けない。

### これデフォルトで作れないんだ!?を解消した話 

https://fortee.jp/iosdc-japan-2019/proposal/0e35f584-3f51-4bab-9f24-4fe8e584acab

デザイナーと共通認識持ってるの大事
共通言語(コンポーネントとか)を構築した!がうまく回らない….(人はルールを守らない
bitrise → Dangerを動かして、IBのチェックをする
いろいろやったから詳しくは資料を見よう!

### フィードやチャットのスクロールを全力でなめらかにする

https://fortee.jp/iosdc-japan-2019/proposal/de50c56a-f1b4-43b6-917e-e0911c4bb78d

Automaticの場合はcellForRowAtからWillDisplayの間に行われるのでカクつく…
Facebookはなぜかちゃんと動く…
事前にCellの高さを計算しよう!(テキストの文字数さえわかればできるでしょ☆
先に高さ計算するだけで描画が30倍とかになる(しゅごい

### 令和時代のゲームボーイ開発 👾 

https://fortee.jp/iosdc-japan-2019/proposal/1a25edb5-ff96-4453-8780-72a0158bb394

ゲームボーイのゲームを作った話(iOS関係ないっすw
アセンブラで書かないといけない…無理w
CBDKを使った(これを使うとCで書けるようになる!
dockerを使ってゲームボーイ環境を一瞬で構築できる
gameboyは4色しかないしDotで用意しないといけない
複数のスプライトを組み合わせればめっちゃでかい画像も作れる!
CI環境を構築したのでコミットごとにロムができます!
書き込み可能のソフトを買えば実機で動かせます!!!


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

2

domonr

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。