[iOS] Conference With Developers 2に参加してきました #confwd

平屋真吾

2014.02.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Conference With Developers 2 - peatix.com

iOSアプリ開発者向けのカンファレンスイベント「Conference With Developers 2」に参加してきたので、発表内容をまとめてみました。

iOSエンジニアとGitHubとキャリア

発表：浅野慧さん
- Twitter:@ninjinkun
- Blog:ninjinkun's diary
- GitHub:https://github.com/ninjinkun/
発表資料：GitHub活動を通して個人のキャリアを積みつつ仕事の成果を出す方法

GitHubを使ったオープンソース活動についての、浅野さん自身の事例を交えた発表でした。 OSS活動は、自分自身の勉強になるし、使ってもらえる喜びがあるとよく聞きます。社内で評価されたり、GitHubのリポジトリが履歴書の代わりなったりと、２次的なメリットもあるようです。「GitHubチャンス」に遭遇した時に挑戦してみようと思います。

"GitHub活動"

浅野さんはGitHub上でのオープンソース活動のことを「GitHub活動」と呼んでいるそうです。具体的には、自分で作ったライブラリのソースコードを公開したり、他の人のプロジェクトにプルリクエストしたりする活動ですね。

SDKについて話すこと自体難しかった時代もありましたが、ASIHTTPRequestやAFNetworkingの成功、CocoaPodsの普及などにより、iOS界隈でも、GitHubを使った活動が盛り上がっています。浅野さん自身は、パイオニア的な人たちが書いたオープンソースを見ながら勉強し2013年にOSSモジュールの公開を始めたそうです。以下、浅野さんが公開しているOSSモジュールを紹介します。

NJKWebViewProgress

GitHub ninjinkun / NJKWebViewProgress

NJKWebViewProgressはWebViewのプログレスの値を取得するができるようにするライブラリです。現在のUIWebViewには、プログレスを取得する公式のインターフェースがありませんが、NJKWebViewProgressを使うことで取得できるようになります。NJKWebViewProgressは「プログレスを取得する」ことに特化したライブラリ(UIとは切り離されている)ですが、同梱のデモアプリですぐに試せるようになっているそうです。Yahoo!JapanやFacebook Messangerで使われたり、GitHubのスターが500を超えたりしているようで、アプリに採用されたり、反応があったりするのが嬉しいと言っていました。

NJKScrollFullScreen

GitHub ninjinkun / NJKScrollFullScreen

NJKScrollFullScreenはFacebookのように、スクロール操作に応じてナビゲーションバーなどを表示したり、非表示にしたりするときに役に立つライブラリです。NJKScrollFullScreenを使えば、UIScrollViewDelegateをフックしてバーを隠すタイミングを知ることができます。併せて「UIViewController+NJKFullScreenSupportカテゴリ」をつかうことで、表示／非表示を実現できます。こちらもデモアプリがあるので直ぐに試せるようになっているようです。

"GitHubチャンス"

「探しても欲しいライブラリがない」「似たようなのはあるけど丁度のやつがない」、あるいは「気づけば同じ処理を書いてる」のような状態に出くわすことを「GitHubチャンス」と呼んでいました。非UIモジュールやWeb連携の為のモジュール、他言語(他プラットホーム)にはあるけどiOSにないもの等が作りやすいそうです。

デモアプリを同梱させて試しやすくしたり、組み込みやすい設計にしたり、GitHub上での表現を工夫したりと、自分の作ったモジュールを使ってもらえるように色々と工夫しているそうで、参考になりました。

公開用のObjective-Cの書き方

発表：石川洋資さん
- Twitter:@_ishkawa
- Blog:http://blog.ishkawa.org/
- GitHub:https://github.com/ishkawa
発表資料：公開用のObjective-Cの書き方

「自分以外も使うコードを書く時に気を付けたほうがいいこと」についての発表でした。モジュールとして公開する際には、だれでも簡単に導入し正しく扱うことができる、他のコードへの副作用がない、シンボルやリソースが衝突しないなどのことが求められます。この発表で紹介されている書き方は一般に公開する場合だけではなく、チームの一員として他の人と分担してコードを書く場合等でも念頭に置いておくべきものですので、書き方やパターンの使い分けを改めて確認しようと思いました。

1.アプリとの衝突

導入先のアプリとの衝突を避ける方法についてです。

シンボルの衝突

アプリのコードとライブラリのコードがぶつかってしまうのを防ぐには？
- クラス名：３文字の大文字プレフィックスを付ける(Objective-Cによるプログラミング p.127)
- カテゴリのメソッド名：３文字の小文字プレフィックスを付ける(Objective-Cによるプログラミング p.74)
- 定数：関連するクラス名を頭につける
ライブラリ同士の衝突を防ぐには？
- 依存を明記する
- CocoaPodsの使用を推奨する

リソースの衝突

mainbundleの中には、同じ名前のファイルは1つだけしか存在できない
対策：ライブラリでは専用のNSBundleを使う

2.良い@interface

「使い方を正しく理解してもらうために、どうしたら良いinterfaceを作れるか？」についてです。わかりやすく、正しい使い方を伝えられるようなinterfaceを作るヒントが幾つか紹介されていました。

良いproperty

readwriteとreadonlyに関して

readwrite	readwrite属性のプロパティは、どのタイミングで変更してもオブジェクトの整合性を保つことが望ましい(期待される)ので、そのように実装する
readonly	変更する必要がない、あるいは変更を禁止したい場合にしようする。

良い通知パターン

イベントのハンドリング方法は4つ
それぞれに特徴があるので、ケースに合わせて適切なものを選択し使用する

name	適しているケース	作法	その他
blocks	通知が特定のメソッドに結びつく通知の種類が少ない	引数には結果を渡すエラーが想定される場合はNSErrorも渡す。	構文が異様に複雑。http://fuckingblocksyntax.com/
delegate	通知が特定のオブジェクトに結びつく通知の種類が多い通知の受け手が１つしかない	メソッド名には命名規則がある：(cocoa向けコーディングガイドラインp.15)
NSNotification	通知の受け手が多い通知の送信元と受け手が遠い場合。		グローバル変数的な影響範囲。安易に使用しないほうが良い。
KVO	KVOの使用が指定されている場合、delegateが使えない時など

3.ユニットテスト

「品質が落ちにくい仕組みを導入する」方法についてです。

テストを書く理由

書くことによって開発が早くなる場合がある
- いろんな値や境界値を試すのはデモアプリ上でやりにくい...
- ユニットテストは１度書けば繰り返し実行可能
コードが壊れていることをすぐに発見できる
- 長期にわたって複数人がメンテナンスする場合、ユニットテストを書いておけば、検知が簡単になる
ライブラリのテストのメリットコストに見合う事が多い
- アプリと比べて、ライブラリの仕様変更は少ない

CIを導入する

CIとは?
- ユニットテストを確実に実行するための仕組み
- git push するともれなくレポートがもらえる仕組み
  - "レポート"
    - ビルドは通ったか？
    - テストは通ったか？
    - コードカバレッジは？
最短ルート：ターミナルから実行できるようにする
- "xcodebuild clean test"がローカル上で実行できるようにすれば、あとはCIサーバーにつなぐだけ
GitHub, Travis CI, Coverallsの３サービスを組み合わせると、これらを実現できる

デザインのわかるエンジニアになる

発表：深津貴之(fladdict)さん
- Twitter:@fladdict
- Blog:fladdict
- GitHub:https://github.com/fladdict

エンジニア視点でデザインを理解してみる。という内容で、デザインの手法をエンジニアが普段行っていることに例えてみるという視点が新鮮でした。

デザインとは？

設計する
目的があって、それを達成する方法を提案する
- UX：満足を与える
- UI：使いやすくする
- 情報デザイン：わかりやすくする
複雑なものを整理して解決する
- 解決するための方法の例：
  - グルーピング
  - 階層構造をつくる
  - 主従関係をつくる
  - 色でカテゴリ分けする

文章を書く練習をするように、鍛錬によって訓練できる(先天的なものではない)
デザインも「エンジニアリング」の１つであると捉えることができる

デザインの手法	エンジニアリングに例えると...
ピクセル単位の整列	タグ、ブラケット
グリッドを設計する	クラスをテンプレート化、ベースクラス
色や書体の統一	ネーミングルールを作る
操作にフィードバックを与える	関数に返り値を渡す
色や大きさを与える	型宣言をする

iOS 7のフラットデザインを理解する

レイヤー構造

iOS 7をパッと見た感じでは、フラットに見えるが、レイヤー構造を積極的に使っている
状況をユーザーへ伝える手段としてレイヤー構造が使われている。

例	目的
ホーム画面のパララックスエフェクト	レイヤー構造を理解してもらうため (技術を自慢するためではない!)
曇りガラスブラー	一時的なステートであることを明示的に宣言する。前のステートへ帰れることを保証する、そのことをユーザーに伝える
カレンダーアプリなどのズームアニメーション	どれをタップしたかを伝える。 (ナビゲーション中心ではなく、コンテンツ中心。ユーザーから見たオブジェクト指向)

テーマカラー

押せる部分に使う
どこを押せるか問題への対策
10種類のテーマカラー (iOS 7 color palette)

手触りにも全て意味がある

視覚言語

アニメーション、動き、形など、言葉ではない手段で何かを伝える「JavaScriptより自由度の高い言語」と考えることもできる

アニメーションを使うことでできること

例	目的
(AppStoreの購入ボタンの円形アイコンのアニメーション)	特定の場所に注目を集める
ブラー背景に移行するアニメーション	状態の変化を通知する
push、pull、modalなどの画面遷移アニメーション	ナビゲーション
(良くない例：最近話題になったiOS 7の電卓)	一瞬の変化を知覚させる
メール送信などで、直ぐに処理完了にするのではなくアニメーションを表示する	ユーザーに考える時間を与える
削除やアンドゥ操作のアニメーション時間のかかる処理を行っている時のアニメーション(ゲームのステージ読み込み時の演出など)	ストレスの軽減(目に見える変化をユーザーに見せたほうが良い場合) 体感時間を減らす

音を使う

画面を見ていないユーザーに通知する手段：電話、アラーム、処理の終了

JavaScriptCore.frameworkでできること

発表：岸川克己さん
- Twitter:@k_katsumi
- Blog:24/7 twenty-four seven
- GitHub:https://github.com/kishikawakatsumi
発表資料：JavaScriptCore.frameworkでできること

iOS SDK 7.0(MacOS SDK 10.9)から追加されたJavaScriptCore.frameworkについての発表でした。アプリの全てをJavaScriptで書くことはないにしても、他プラットホームとの共通化部分をJavaScriptで書いたり、JSのライブラリを使ったりと活用できる部分がありそうです。

JavaScriptCore.framework

概要

Objective-CとJavaScriptのブリッジ
- Objective-CからJavaScriptを実行とその逆
- 両オブジェクトの相互変換
国内のドキュメントが少ない

メインのクラス

JSVirtualMachine
- シングルスレッドのJS仮想マシン
- 基本的には１つ使う
JSContext
- JSの実行コンテキスト。オブジェクトの管理
- 名前空間の衝突を避けるときなど、複数使ったりする
JSValue
- JSオブジェクトのラッパー
- JS側から受け取った時に適切な型に変換する

使用例

Objective-CからJavaScriptを呼び出す
- 一部のロジックをJSで記述
  - WebやAndroidと共通化してるときなど
- JSで書かれたライブラリを使う
  - 例：
    - text-hatena.js (はてな記法 Parser)
    - textile.js (Textile Parser)
    - JSONH (JSONの圧縮)
JavaScriptからObj-Cを呼ぶ
- JSExportというプロトコルが重要
  - プロトコルに従っているものだけ呼べる。
  - 既存のクラスをJSExportに適合させる必要がある(Obj-C ランタイム APIと関連)
    - 制限がきつい...操作できるようにするための手順が多い。用意することが多い

JavaScriptBridge

GitHub kishikawakatsumi / JavaScriptBridge

JavaScriptからObjctive-Cのオブジェクトを操作するためには、予め既存のクラスをJSExportに適合させる必要がありますが、JavaScriptBridgeを使うことで事前準備が済んでいる状態をつくることができます。つまり、ほとんどのクラスに必要なファイルを作ってあるんですね(ここで、会場では拍手が巻き起こってました!)