iOSDC 2016

雑ですみません、iOSDCへ参加した際の雑多書きです。
内容に需要があればもう少し綺麗にします。。。

• Handing rich text in swift
  • デザイナーの要望とできることで違いが出て、とかのやりとりが起こる
  • Textkit
    • 高速なモダンテキストレイアウトレンダリングエンジン
    • coretextで作られている
    • uikitと統合
    • UILabelを使えばtext kitを使ってるってことになる？
      • ヒラギノとシステムフォントで文字の大きさが変わる
        • 英字が大きくなる
      • ヒラギノ指定
        • 文字が一部切れるとかが起こる。文字の高さも違う。
      • 行の高さ
        • フォントが持っている
        • Font metricsで色々説明。フォントの構成。ここを見て、行の高さをどうするかレンダリングしている
        • ヒラギノは特殊なmetrixを持っていて、上下が狭くなる。それによって欠ける
        • iOSの日本語フォントはだいたいこんな感じ
      • 対応
        • 上下にDescantを補う
          • ちょうど2倍にするといいらしい。
      • 注意
        • ヒラギノを明示的に指定しない、システムフォントを指定する
          • デザインしようしょにヒラギノって書いてある場合、本当にそのフォントを指定したいのか、システムフォントでいいのか確認すること。だいたいシステムフォントでいいはず。
            • 指定したい場合、きちんと表示されない場合があるのえ気を付けて実装する。
          • 中国語フォントにフォールバックしたくない場合もあるかも。
    • 描画サイズを得る
      • bandingナンチャラ
      • 表示したいテキストが高さ、広さぴったりに表示できる
    • UITextView
      • デフォルトのマージンがある。
        • 上下textcontennerincent
        • 左右linefragmentpadding
      • ヒラギノ
        • font.leadingが高さを把握
      • コントロールする場合は、デフォルトのスタイルをリセットする必要がある。
        • textcontainerinsetを取り除く
          • それぞれ0をしていするとマージンがなくなる
        • font.leadingを取り除く
          • trueになってるけど使わない方がいい。false
          • この数値も含めて描画サイズを計算する
        • そうすると、コントロールがしやすくなる
          • 行間の調節
            • nsattributeedstring
            • min /max のlineheightがある
              • 複数のフォントサイズが複合した場合のためにある
    • まとめ
      • nsattributtedstring大事
      • タイポグラフィを知ろう
      • ヒラギノ本当に使うのか確認、システムフォントでいい？
    • 質問
      • システムフォントのがヒラギノより日本語が大きい。どう対応するのか。
        • 対応難しい。対応すると結構工数大きい。
      • デザイナーはphotoshopでヒラギノをしている。ソフト上でできないの？
        • 確認し　ます。iOS 9でも システムフォントが「San Francisco」なので、それをしていすれば行けそう。
• RxSeiftは開発をどう変えたのか
  • メルカリのiosエンジニア
  • イベントストリームを抽象化
    • 変化の流れ
    • observable　イベントストリーム
      • uitextfield.io_？？
    • ここのイベントはsubscribe() で受け取る
      • イベント発生ごとにobserberが実行される
    • bind to()
      • observer<element>に自動反映する
      • 何かするたびに、何かを自動反映するとか
    • operator
      • observableの変化ん、絞りこい、組み合わせ
    • conbinlatest()
  • 従来の方式との違い
    • rx
      • vierdidloadだけで終わる
      • 水道にホースをつなぐイメージ。
      • ためておいて動作するって方法がない。必要がない。opelatorで表現出来る？
    • 従来
      • このパターンではこっちのが読みやすい
      • バケツに美雨を入れるイメージ
        • どんどん入れていくイメージ？
      • イベントストリームの最新の値を保存しておき、都度取りに行く
      • テキスト、ボタンのタップと表現の仕方が違うので難しい
  • 天気
    • ボタンタップ、位置情報の認可、情報取得
  • まとめ
    • イベントストリームを宣言的に使えるようになったので、把握しやすくなった
    • 状態管理を以前よりも減らせる
    • 本出します、swiftの。
  • 質問
    • コード量は増える？減る？
      • 総量は増える。でもコントローラーは減るかも。
• Colectionveiw ios10について
  • プリフェッチdatasorce
  • tableviewsの方がパフォーマンスがいい。せるサイズ固定は高速。UIKitを使う場合はナンチャラしないと落ちる。
  • 重い処理は、celforナンチャラでやる
  • bletlayer処理を行わない
    • 透過pngとか置いたりするとき、角丸とか。
    • シミュレーターのデバッグでチェックできる。赤エリア。このエリアは減らそう。
    • 透過pngファイルは使わない
      • 背景入れろ。
    • clearcolor背景を使わない。background colorを合わせる。
    • 角丸、シャドウは画像でやった方がいいっぽい。
• reactive stream
  • FRP
    • 状態の変更 data binding
    • 状態の取得　data observing
  • FRP + MVVM
  • やってみる
    • viewmodel.valiable
  • reactに似ている
    • reactsは、子から親へのデータフローが大変
  • react + redux
    • reactの状態をreduxが管理し、テストがしやすくなる
    • 状態を1つのstoreで管理
    • 問題点
      • 非同期処理が難しい。もともと同期処理用。
  • redux + FRP
  • 理想はelmの設計に近い
  • まとめ
    • データフローってか状態
    • 管理は複雑
      • react reduxから学ぶ
    • emlチェックして
      • FRP捨てるって展開になってきてる？
• ドッグフーディング
  • 全社員にアプリを配布してフィードバック
    • 感想はアンケートフォームに。
      • 10件しかなかった
      • でもやり方が悪い
  • 方法
    • アプリ利用依頼
      • 使ってみてください、じゃ使わない
      • 自分にとってのメリットが見つからない
      • 業務の中でその時間が割り当てられているわけではない
      • テストアプリのメリットを明確に伝える。
    • アプリDL
      • ADEPに参加して配布
      • 既存アプリが削除されている（既存ユーザ）
        • bunddleidentifierを変更すれば大丈夫
    • フィードバック作成
      • メール、文章面倒、とかでやめる
      • フィードバックボタンをつけておく
        • スクリーンショット、フリーコメントでMYMに送れる
    • プライバシー
      • スクショ送るとIDがバレる
        • キャプチャにマスク機能
  • 上記でフィードバックに集中してもらう
  • これでフィードバック増えた
    • 1600件。
  • これをやったことによる変化
    • モチベーション向上。議論活発。業務の仕方の改善。
    • 言いたいことを言いやすい文化に
  • Feedback kitをMITライセンスで公開している
    • 個人的なアカウントで登録している
• メモリ管理
  • スタックとにかく早い
  • ダイナミックにやりたい時はヒープ領域
• stoaryboad
  • デザイナーがstoaryboadを作るワークフロー
  • 導入
    • チームと個人、デザイナーのモチベーション
    • 環境のセットアップ
      • buildできるだけでも便利
    • 手取り足取り
    • 触れあう
  • interfacebuilder
    • 意外とわかりやすい
    • 登場する要素を説明する必要がある
    • viewはシーン。view controller？ってなる
      • 知ってもらえると助かる
  • auto layoutがわかりづらい
    • nslayoutconstraint
      • 計算式で上手いことなるよ
    • intrinsic content size
    • priority
    • エラーが出るときがある
      • 制約と配置があってない：警告
        • constraintと配置
        • 制約の矛盾
        • 制約が足りなくてレイアウトできない
  • adaptivity
    • dynamic text、site class、trait control？
  • 伝えるのに3日かかった
    • iOS、androidのレイアウトを学んでもらう。結構早い期間です。
  • ワークフロー
    • 企画される
    • デザイナーがレイアウト・デザイン決める
    • 機能を実装して、雑に並べる
    • デザイナーに細部を調整してもらう
    • コードレビューをする
  • @IBDesignable
    • UIViewに付加する属性
    • storyboardから設定できる
  • 前提共有
    • キーワードを共有する。ナビゲーションバー = ヘッダー。同じ言葉を使おう。
    • めちゃくちゃ汎用的なviewを作りたくなるけど、あんまりよくない
      • 後で結構変えたくなる
  • UIKitについて学び直す
  • Storybookは分割する
    • コンフルクトよくある
    • デザインの調整は最後にするとか。先にマージするとか
  • デザイナーへ手助け
    • デザイナー忙しい。アプリだけでなくプロモーションとか色々
    • イラレで作っているらしい。画像書き出し面倒。書き出しくんツールを作ったりしてた（前は）
  • まとめ
• mireta
  • webRTC
    • iOS、androidのSDKも出ている？
    • どうやってIPアドレスを知るのか
    • skywayサービスでいい感じにつなげられる
  • やり方
    • ios
      • スクリーンショットを定期的にとっておくる。2秒ごと。
    • ブラウザ
      • dating
• swiftでjavascript
  • javascript core
    • ランタイムで動作