koogawa blog

iOS、Android、foursquareに関する話題

2015/2/14 #dotsios iOSオールスターズ勉強会に参加してきたよ

iOS 勉強会

f:id:koogawa:20150215094432p:plain

昨日はiOSオールスターズ勉強会に参加してきました。

定員370人ということもあり、会場はものすごい人でした。

f:id:koogawa:20150215094636j:plain

すでにクラスメソッドさんから詳細なレポートが上がってますので、詳しい内容はそちらを参照してください。


[イベントレポート] iOS オールスターズ勉強会 #dotsios ｜ Developers.IO

以下は自分用に書いた簡単なメモになります。

『Adaptive Collection View』LINE株式会社 石川洋資氏

  • iPhoneではUITableView、iPadではUICollectionViewを表示するアプリを作るとする
  • 似たようなコード（delegate等）が増えてしまい、冗長になる
  • UICollectionViewでUITableViewぽいものを実装してしまおう
  • 高さ固定ならestimatedItemSizeが便利
  • サンプルコード https://github.com/ishkawa/sandbox/tree/master/Adaptive
  • 1つのViewController、CellでiPhone, iPadに対応できる
    • これがAdaptive
  • Self Sizing Cell(iOS8から) - NSLayoutConstraintを適切に配置するとセルの大きさを自動的に計算してくれる機能。
  • まとめ
    • UITableViewはUICollectionView
    • iPhoneはiPad
    • 同じコードは二度書かない
 

『Swift製ライブラリの良い書き方を考える』株式会社ユビレジ 岸川克己氏

  • SwiftのObjective-Cとの違い
    • データ型
    • Class
    • Struct
    • Enum
    • Tuple
    • Function
    • Array
    • Dictionary
    • Set * NEW!! *
    • Optional
  • Optionalの取り扱いについて
    • オブジェクトがOptionalはnilかも知れない
    • Objective-Cでは、わりとカジュアルにnilを返した
    • なぜならnilにメッセージを送っても無視されるから
    • Swiftは型に厳格なので、パラメーターではできるだけ Optional を受け取らないようにするも大切
    • Closureは例外で空の実装をデフォルト引数とすると良い，closureのnilチェックもいらない
 

『let UIWebView as WKWebView』ヤフー株式会社 佐野岳人氏

  • http://www.slideshare.net/taketo1024/let-ui-webviewaswkwebview
  • UIWebView、WKWebViewのインターフェースは似ているが互換性は無い
  • iOS7でWKWebView使えないのでどうするか？
  • バージョン分岐だらけのコードは危険
    • コントローラーの本来の役割が見えにくくなる
    • ハウルの動く城みたいなコードになる
  • iOSのバージョンは最新さえサポートすればイイじゃん？
    • 100万いれば28万はiOS7ユーザー
  • 方針1: ラッパーで包む
    • IF は WKWebView と共通にする
    • iOSバージョンで分岐、iOS 7の場合は前処理＋UIwebview使う
    • 目的は達成できているのだが、 全メソッドに分岐を入れるのが あまりエレガントな感じしない。
  • 方針2: UIWebView に WKWebView のフリをさせる
    • 手順1: WKWebView の IF を Protocol として切り出す
    • 手順2: WKWebView の拡張で Protocol に適合
    • 手順3: 同様に UIWebView の拡張も作成
    • •だいぶ裏技っぽい （戻り値型を捻じ曲げてる辺り特に）
    • UIWebViewで足りないメソッドだけ実 装すれば良い
 
 

『通信のパフォーマンス改善』Wantedly inc 杉上洋平氏

  • 海外の通信が遅いのに対応するためにパフォーマンス改善を決意
  • やはり画像が重いので、画像に注力して改善
  • 画像はSDWebImage利用者してたので、まずはそちらの仕組みを知るためにコードを解析
  • 遷移元の不要な画像読み込みをキャンセルしちゃう
  • 通信帯域によって取得する画像サイズを変更している。通信状況が悪くても何も表示しないよりはマシ、という考え
    • 通信開始〜終了までの経過時間、受信した画像サイズから通信速度を推測してるらしい
 

『効率的なアプリ開発のベストプラクティス』グリー株式会社 矢口裕也氏

  • UIの実装コスト
    • 昔と比べるとだいぶ楽になった
  • 改善の余地
    • ReactNativeに期待
  • 通信の実装コスト
    • 大原則：やることをへらす
    • 結果：サーバに処理を任せるｗ
    • サーバ担当を説得する
      • リクエスト回数減るよ
  • レガシーサーバ
    • 触るのが怖い
 

『WatchKit を実際にさわってみてわかったこと』フリーランス 堤修一氏

  • WatchKit 予備知識
    • WatchKit Extension、WatchKit Appを持つ
    • WatchKit ExtensionはiPhone側で実行される
    • WatchKit Appはあくまで表示用
  • WKInterfaceObject という全インターフェースのベースクラスがいる
    • そのサブクラスが全部で１１種類
    • 例えば画像を表示するWKInterfaceImageなど
  • WKInterfaceImage
    • UIImage.animatedImageWithImages() が使える
  • テキスト入力
    • presentTextInputControllerWith〜系
 

『長生きするために心臓に悪いリリースはもうやめよう』クックパッド株式会社 所友太氏

  • リリースボタンをおすのがこわい
    • アプリ内課金使ってるし
    • 何億もの損失が出るかも・・・
  • Internal Testersで最終チェックしよう
  • CIと競合するものではありません
  • 万が一のために後から取り返せないデータは保存しておこう
 

『エンジニア戦記 ~ 小さなチーム 大きな未来 ~』クラスメソッド株式会社 平井祐樹氏

  • ブログの会社ではありません
  • WebAPI担当者とうまくやるために
    • JSONにheaderとかある
    • 「サクセスでエラー処理しなきゃいけなくなる」
  • １画面で何回APIたたくねん
    • 1 Screen 1 API Call"
  • まとめ。
  • 1, Web APIの知識は必須。
  • 2,文句を言うのは簡単、改善案を提案できる力を。
  • 3, Web API the good partsを読もう。
 

『まだiOSでリッチな演出に疲弊してるの？』面白法人カヤック 布田隆介氏

  • 演出、機能ともに様々なものがアプリに求められる
  • SpriteKitいいよ
    • ボタン押した時のアニメーションとか簡単にできる
    • ブラーもかけられる
  • SKNode
    • SpriteKitのコアとなるクラス
    • NSObjectのようなもの
    • SKViewをつくりUIViewControllerにadd
    • SKActionでアニメーションつけられる
  • UIKitとSpriteKitを組み合わせるのはあり！
 

感想

  • 非常にレベルの高い勉強会だった
  • 他社のリリース運用方法がわかったのが良かった（所さんの発表）
    • （自分のQiitaの記事が引用されてて嬉しかった！）
  • 通信状況によって画像サイズ変えるのはビックリした（杉上さん発表）
  • 「1 Screen 1 API Call」という言葉が強く印象に残った（平井さん発表）
  • サンプルコードがみんなSwift
    • Objective-Cで説明している人がほとんどいない
    • 既存アプリをSwiftに移行するレベルまでは持って行かなくとも、Swiftが問題なく読めるレベルにはなっておいたほうが良さそう