先日のSeattle Xcoders Meetupで,The Omni GroupのソフトウェアエンジニアであるCurt Cliftin氏は,Apple Watch用ソフトウェアの開発がどのようなものなのか説明した。その中で氏は,Watchアプリの概念モデル,携帯電話とのデータ通信,いくつかの課題について論じている。
概念モデル
最初に考慮されるべきだとClifton氏が言うのは,WatchKit 1.0では,iPhoneアプリにバンドルされたエクステンション内でコードが実行される,という点だ。
Watchそれ自体では,Appleが提供する以外のコードは一切動作しないが,イメージアセットとコンパイルされたストーリボードをホストすることができる。イメージを動的に生成して,Watchに送り込むことも可能だ。そのために20MBのキャッシュが用意されているが,これは低速な上に信頼性が低い,と氏は言う。
WatchKitフレームワークはまだ,ごく小規模なものである,というのが氏の意見だ。Watch上のビューに使用されるプロキシクラスがその大部分を占める上に,そのほとんどがsetterメソッドだけで,getterを備えていないクラスである。
同期オプション
iOSエクステンションは,それをホストするアプリとは分離されたプロセス内で動作するため,2つの間のデータ同期は重要だ。そこで氏は,利用可能ないくつかの同期機構をレビューしている。
- NSFileCoordinator: 残念なことにこれは,Appleのテクニカルノートによって,アプリ↔エクステンション間の同期手段から除外されている。
- Group権限とユーザデフォルト: セットアップや利用は非常に簡単だが,変更が通知されない。
- CoreData/SQLite共有データベース: 氏によれば,これも必要十分なメカニズムだ。
- シードファイルとコールバック: 氏のサンプルアプリで使用しているソリューションであり,詳細に説明されている。iPhone上のホストアプリがシードファイルを,例えばJSONペイロードなどと一緒に,共有アプリケーションコンテナに書き込む。
- Watchエクステンションがデータシードファイルを読み込む。親アプリに送り返すべきユーザアクションが存在すれば,ホストアプリをバックグラウンドで動作させることの可能な
openPatentApplication:reply:
メソッドをコールする。親アプリは,用意ができたときにコールするreply
ブロックを受信する。 - ホストアプリは,シードファイルのデータを更新した後に,replyブロックを呼び出す。これによって,新しいデータがエクステンションへと転送される。
- Watchエクステンション側ではシードファイルを読む必要はなく,
reply
ブロックを通じて受信したデータをメモリ内で更新すればよい。
- Watchエクステンションがデータシードファイルを読み込む。親アプリに送り返すべきユーザアクションが存在すれば,ホストアプリをバックグラウンドで動作させることの可能な
プレゼンテーションの次のパートは,氏のサンプルアプリのソースコードのウォークスルーと,Xcodeでデバッグを行う方法のデモに充てられていた。デバッグのプロセスは,iOS8アプリのエクステンションのそれに近い。
課題
最後のパートは,開発者が今後直面するであろう,課題に関する議論の時間に充てられた。
- 前述のように,WatchKitが提供するのはsetterのみであるため,アクティブでないコントロールへのコマンド送信がまず課題となる。これはデータの不一致につながる可能性があるため,各クラスがアクティブか非アクティブか,そのコントロール状態を追跡することで処理される。このアプローチは,サンプルアプリでは,一連の
_updateDisplay*
メソッドを通じて実装されている。 - Xcodeのコピーフェーズ内でフレームワークをコピーすることによって,ホストアプリとWatchエクステンションとで,フレームワークを共有することができる。
- 自動レイアウトはサポートされず,左から右,上から下に埋め込み可能なグループに置き換えられる。グループを入れ子にすることで,非常に複雑なUIを構築することも可能だが,それはまったく別のモデルになる。
- 最後に,通知用のWatchインターフェースがどのようなものか,Watchからの通知がどのように扱われるのかについては,まだ明らかになっていない。
Clifton氏のサンプルアプリはGitHubで公開されている。