iOSオールスターズ勉強会レポートin blog

 
date:2015.02.23   posted by:Tanaka
 

おばんです、田中です。
先日東京で行われたiOSオールスターズ勉強会というイベントに参加してきたのでそのレポートをします。
参加人数が370人を超えるほどの大規模なイベントで、iOS限定の話題でここまでの人数が集まるイベントは初めてだったので始まる前からとても期待度の高いイベントでした。

開催日が2/14のバレンタインデーにもかかわらず集結する300人超のiOSエンジニアという司会のスタートにも震えました。

イベントの進行については各セッション20分で合計9セッション行われました。
イベントページはこちら
イベントのtogetterまとめはこちら

ではさっそく各セッションの概要とポイントを紹介していきます。

『Adaptive Collection View』

LINE株式会社 石川洋資さん

まずAdaptiveとはなにか。
AdaptiveとはワンコードでiPhoneとiPadの両対応ができたり、そういうもののことを言うようです。

従来であれば一つのアプリの画面デザインでもiPhoneとiPadでは設計が変わります。例えばiPhoneであればUITableViewで画面を作るところが、iPadではUICollectionViewを用いて二列にセルを並べる設計になります。
しかしそこでiPhone側ではUITableViewっぽく見えるUICollectionViewのサブクラスを作ってしまえばあら不思議、そのサブクラスを使うことで、ワンコードでiPhone版もiPad版も両対応できるというお話。

石川さんが社内で「取り急ぎiPhone対応してほしい!」と言われてiPhone用にCollection Viewの画面を作って提出したところ、「iPad対応もしてくれてありがとう!」と返答がきて本人もびっくりしたというエピソードがあったとのこと。

その他には、
・UICollectionViewはUICollectionViewFlowLayoutを使うと割と簡単にレイアウトを作成できる
・iOS8からあるSelf Sizing CellというNSLayoutConstraintを適切に配置するとセルの大きさを自動的に計算してくれる機能が便利である
などといったCollectionView周りのテクニックの紹介もありました。

自分も先日UICollectionViewを使う機会があったのでちょうどホットな内容でした。
UICollectionViewはAutoLayoutとの関連性が強いクラスであるというお話でしたので、複数の画面サイズが出てきたこれからのiOS開発でも欠かせない存在となるでしょう。

石川さんはgithubでライブラリーも公開予定とのことなのでこちらもチェックしてみてください。
https://github.com/ishkawa/sandbox/tree/master/Adaptive

『Swiftで使いやすいAPIを考える』

株式会社ユビレジ 岸川克己さん

岸川さんはご本人がSwiftでAPIを設計した経験を元に、その際の注意点やベストプラクティスなどを紹介してくださいました。
自分自身まだ内容を飲み込めていないので断片的にはなりますが、内容を書いていきます!

まずObjective-CとSwiftの違いには以下があります。
・データ型
Class、Struct、Enum、Tuple、Function、Array、Dictionary、Set、Optional
・オーバーロード
・メソッドチェーン

複数の戻り値を返す関数を書くときは戻り値をタプルにして.asString、.asDataなどのドットチェーンで結ぶ方法はアリ。

クロージャ引数には空実装を渡しておけばnilでもOK。

関数を定義するときにデフォルト引数を設定しておくと補完の際にヒントになるかと思ったが、実際に補完を使ってみると「引数 = default」という表記になってしまうので結局よくわからなかった。この場合オーバーロードを使って複数関数を定義してあげたほうが良かった。

Swiftは型に厳しいのでクラスや関数を定義する際には型は細かく決めてあげたほうが使いやすくなる。

Swiftでの設計は原則引数にOptional型を使わないほうようにしたほうが良い。

エラー処理にはEither型を使おう。

ライブラリを提供するときはDocumentと一緒にPlaygroundをつけてあげるとどんな動きになるのかわかりやすいのでオススメ!

などなど…。
正直に言うと自分が理解できた内容は多くは無かったのですが、多くの知らない単語が知識欲にアツい火をつけてくれる素晴らしい発表でした!

『let UIWebView as WKWebView』

ヤフー株式会社 佐野岳人氏

佐野さんの発表資料はこちら
let UIWebView as WKWebView

iOS8から登場したWKWebViewというクラスをiOS8より前のUIWebViewと共存させる方法について。
WKWebViewは簡単に言うとUIWebViewの上位互換のような存在で、UIWebViewと比べると安定性や速度の点で優れているそうです。そのほかにも読み込みのprogressがWKWebViewのプロパティとして良いされており、値の取得が簡単であったりする便利クラスのようです。

じゃあWKWebViewを使えばいいんだ!となりそうなものですが、iOS8より前のバージョンの対応を切れない場合がある…。といったときにどうすれば良いかというお話。

UIWebViewとWKWebViewを共存させるには二つ方法があって、一つはOSのバージョンごとにUIWebViewとWKWebViewを切り替える方法。この方法は切り替えのために用意するコードが多くなって見通しが悪くなったりして弊害が出てきます。

もう一つの方法はUIWebViewにWKWebViewのフリをさせるというもの。UIWebViewにWKWebViewのインターフェイスを追加してやればそれができる!ただし元クラスの定義として戻り値の型の関係上Swiftで書くとどうしても実装できない部分が出てくるのでインターフェイスはObjective-Cで書いて、それをBridging-HeaderからSwiftで呼び出して使ってやるという方法で実装ができるそうです。

WKWebViewという便利クラスが出来たんだという発見と、対応の仕方としてこのやり方は工数少なくて良さそうだなという感想です。設計の練習としても良さそうなのであとで実装して試してみようと思います。

『通信のパフォーマンス改善』

Wantedly inc 杉上洋平さん

杉上さんの発表資料はこちら
iOS 通信のパフォーマンス改善 ・ iOSオールスターズ登壇資料

杉上さんといえばQiitaでのSwiftの記事。その多さと質の良さたるや、Swiftをやっている人で記事を見たという人は多いのではないでしょうか。自分もその一人で、今回懇親会でご挨拶できてとても感動でした。

wantedlyは今年海外進出をするということで、海外では通信速度が遅いという問題があってその対策をどうしたのかというお話でした。

まず使っているツールは二つ、New Relic MobileとPonny Debugger。これで通信を解析したところ、画像の通信改善が必要ということが判明したそうです。
そこでとった改善策は以下の五つ。

改善策①:まだ画面に表示されていない画像を事前に取得する

改善策②:取得する画像に優先順位をつけてダウンロードする
画像通信にはSDWebImageというフレームワークを使ったとのことで、それのSDWebImageOptionsのChange Priorityというものを使って実装したとのこと。

改善策③:遷移元の画像取得をキャンセルする
SDWebImageのCancellAllというメソッドを使うことで実装できるとのこと。

改善策④:画像フォーマットをWebpにする
Webpという規格を使うことで、jpegやpngといった拡張子の画像ファイルサイズを三分の一にできるとのこと。

改善策⑤:通信帯域によって取得する画像サイズを変更する。

実用的で他の場面でも使える対策の数々でした!

『効率的なアプリ開発のベストプラクティス』

グリー株式会社 矢口裕也さん

矢口さんの発表資料はこちら
効率的なアプリ開発のベストプラクティス

矢口さん曰く、iOS開発の醍醐味は一つ一つの画面に注力して最高のアプリを作っていくことであるとのこと。
ではそれを効率的にやっていくにはどうするのか。大原則としてやることを減らせば良い!

サーバー側、クライアント側どちらでもできる処理であればサーバー側に実装を任せた方がコストが低く、修正も簡単である。API側の設計として大切なのは共通化やRESTなどにとらわれないこととクライアントの画面の都合、ライブラリの都合に合わせたjsonファイルを返してもらうことが大事だとのこと。

しかしサーバー担当者からはあまり良い顔をされないことが多いので、その説得の手段もいくつかあるとのことでその紹介もありました。

アプリを作る際にサーバー側とのAPI設計のすり合わせは肝になる部分で、jsonの構成がうまく合わなくて面倒になるということが実際自分にも起こったことなのですり合わせの指針としてとても参考になりました。

『WatchKit を実際にさわってみてわかったこと』

フリーランス 堤修一さん

堤さんの発表資料はこちら
WatchKitを実際にさわってみてわかったこと

ベータ公開されて結構な時間が経ったWatchKit。そのTipsの紹介です。

WatchKitに用意されたクラスはなんとたったの15個!
WatchKitアプリの構成としてはiOS端末に親アプリがあってそれがWatchKit Extensionを持っているのだとか。プログラムはiOSアプリ側で実行してWatchKit Appでは基本的に表示を行うだけという構成だそうです。

そのほかWatchKit Appにおけるアニメーション、テキスト入力、UIのカスタマイズなどの紹介をとてもわかりやすく解説いただきました。WatchKit開発やれる気がしてきました。

『長生きするために心臓に悪いリリースはもうやめよう』

クックパッド株式会社 所友太氏さん

所さんの発表資料はこちら
長生きするために心臓に悪いリリースはもうやめよう

アップルの審査が終わってリリースボタンを押すのは寿命が縮まる思いがする。バグがあれば会社の売り上げが数億円減るかもしれない!そんな思いをするのはもうやめにしようというお話。

アプリのサブミット前後でどんな確認をしていますか?
テストには以下の四つの段階があるそうです。
Lv.1:プログラミングしながらデバッグ実行して確認
Lv.2:Adhoc版をTestFlightなどで配信してテスト
Lv.3:プロモーションコードを使ってテスト
Lv.4:iTunes ConnectのInternal Testerでテスト
それぞれの段階でAppStoreに公開されるものと同じアプリかどうかという違いがあったり、大切なテストの特徴の紹介などが主とした内容でした。

Internal Testerなど新しい機能のお話などとても興味深いお話と、月額のシステムが止まったら本当に数億のお金の問題になるというクックパッドで働く所さんならではのお話は重みが違い、貴重でした。

『エンジニア戦記 ~ 小さなチーム 大きな未来 ~』

クラスメソッド株式会社 平井祐樹さん

平井さんの発表資料はこちら
エンジニア戦記 〜小さなチーム、大きな未来〜

こちらも矢口さんと同様にiOSとWeb APIとの連携についてのお話。

iOSエンジニアもWeb APIの知識があった方が改善案やこう設計してほしいという提案が出来て良い。知識が無い状態だと返ってきたiOS側を書くときも返ってきたjsonのデータに合わせて設計するのでしっくりこなかったりむずがゆい思いをすることに!

さらに言いたいこととしては
「1 Screen, 1 API call」
一画面には一つのAPIコールで必要な情報をすべて持ってきたい、そうすればリクエスト回数も減って効率的だよね!ということだそうです。

Web APIに関する知識をつけたい方はこちらのオライリーから出ているWeb API The Good Partsがおすすめだそうです!

発表のリズムも良くネタも面白かったですし、具体例を出した内容だったのでとてもわかりやすくて良い内容でした!

『まだiOSでリッチな演出に疲弊してるの?』

面白法人カヤック 布田隆介さん

布田さんの発表資料はこちら
まだiOSでリッチな演出に疲弊してるの?

最後のセッション、めちゃくちゃテンションが低く見える登場(本人としてはとても高め)をした個性的な布田さんの発表はSpriteKitで演出を作ってみたというお話。

iOSアプリでの演出というとCoreAnimationやcocos-2d、Unityを使ったものが多いそうですが、そんな中SpriteKitを使った理由はUIKitやカメラなどのiOS標準の機能との併用がしやすいからとのこと。
SpriteKitのパーティクルを使うとちょっとした演出を簡単にリッチに仕上げることができるそうです!

自分も以前SpriteKitを使った経験があったので疑問点を二つ質問させていただきました。

Q1.演出やゲーム制作にはcocos-2dとかUnityがよく使われているようですが、なぜSpriteKitは選ばれないのですか?
A1.単純にcocos-2dとUnityを使って開発をしている人が多いからそれに合わせることになりがちです。

Q2.パーティクルの処理は重いはずですが、そこをできるだけ軽くする工夫はなにかありますか?
A2.表示するSKViewのサイズを画面いっぱいではなくエフェクトの表示サイズまで小さくすると軽くなります。

個人的にSpriteKitは優秀だと思っていたのですが、なぜそれが選ばれないのか、パーティクルをどう扱ってやればいいかなど疑問に思っていた点が聞けたのは目からウロコでした!とても勉強になりました。

まとめ

9セッションどの発表も見応え抜群で、終始鼻息を荒くして必死にメモとったり単語をググったりしてました。イベント全体を通すとSwiftとObjective-Cの言語の特徴を抑えた話から、通信の効率化の具体的な話や表面のUIの魅せ方の話などうまく全方位をマークしていて満足度がとても高かったです。

iOSまだまだ奥が深くて楽しいなぁ。

聞くだけでは吸収できなかったことを無駄にせずこれからのプロジェクトに組み込みながらじっくりと飲み込んで行こうと思います!

 
Copyright © TheDesignium inc. powered by WordPress & mootools.
Relative Keyword|none