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

• 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に関して

良い通知パターン

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

3.ユニットテスト

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

テストを書く理由

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

CIを導入する

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

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

音を使う

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

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を使うことで事前準備が済んでいる状態をつくることができます。つまり、ほとんどのクラスに必要なファイルを作ってあるんですね(ここで、会場では拍手が巻き起こってました!)

Conference With Developers 2 の関連記事

• 2014/2/1 #confwd Conference With Developers 2 - togetter
• Conference With Developers 2 #confwd に参加してきたよ - koogawa blog
• [iOS] Conference With Developers 2 アウトラインメモ - Web scratch
• Conference With Developers 2 に参加してきました #confwd - フェンリル | デベロッパーズブログ

まとめ

iOSアプリ開発の第一線で活躍されてる方々が登壇するイベントであり、たくさんの収穫がありました。今後も、技術を深く掘り進めたり、新しい分野に挑戦したりしていきたいと思います。 主催者の皆様、発表者の皆様、及び参加者の皆様、ありがとうございました!