Apple Watch:時計用のアプリを作り、それを台無しにしない方法

Apple Watchの公式販売が今日から始まりました。 Webで見つけられるそれらの驚くべきアプリケーションコンセプトの90%は実現不可能です-Appleのガイドラインに精通している人はこれをよく知っています。 時計に実装することはまだ可能であり、開発と設計の観点から-habracatの下でそれをどのように改善するか。

ようこそ



私たちのチームは、ロシアで初めて数時間にわたってアプリケーションを作成しました。 開発者とデザイナーが互いの機能を理解すると、素晴らしいデザインコンセプトが発生する確率はゼロになり、開発時間は数日になります。 Grigory Matvievich( fountainhead 、開発者)とEkaterina Sotova( lost_in_purple 、デザイナー)が、Apple Watch用のアプリケーションを作成する場合に注意すべき点を説明します。



それは約になります:

  1. WatchKitアプリケーションアーキテクチャ
  2. 電話のメインアプリケーションとの相互作用
  3. 視線
  4. 通知
  5. アプリケーションのID:フォント、アイコン、色
  6. ナビゲーション
  7. インターフェイスを介したユーザーインタラクション
  8. 画像とアニメーション
  9. レイアウト/レイアウト


イデオロギー:パーソナライズ、整合性、使いやすさ



「Apple Watchは私たちの最も個人的なデバイスです」とAppleで言います。 そしてこれは本当です-所有者の手に常にあるガジェットは、スマートフォンでは不可能または不要であった新しい形式のユーザー操作を提案します。 ウォッチアプリケーションは、所有者がいるコンテキストに適合させる必要があります。 まず第一に、これは、最も有用な情報のみが非常に圧縮された形式で時計に表示されるべきであることを意味します。 時計とその優れたアプリケーションの主なタスクは、目立たず便利なものにすることです。 Appleは触覚を強調し(Taptic Engineは通知が入ってくるか、時計と対話するときに触覚応答を提供します)、アプリケーションと物理オブジェクトの境界を文字通り「ぼかす」ことを試みました。 。 時計はスマートフォン上のアプリケーションを置き換えるものではなく、補完するものです。 Apple Watchのアプリケーションは、操作が簡単でなければなりません。 情報は簡単かつ迅速に表示される必要があり、邪魔にならずに所有者のいるコンテキストに依存する必要があります。 たとえば、ユーザーがそれを一目見た場合、通知は完全に表示され、Glancesは最も関連性が高く必要なものを表示します。 iPhone上のアプリケーションとのユーザーインタラクションのシナリオを数分で測定できる場合、クロックとのインタラクションの期間は、原則として数秒を超えません。 これらすべては、アプリケーションを設計する際に留意する必要があります。



1. WatchKitアプリケーションアーキテクチャ



スマートウォッチの最初のバージョンでは、Appleはサードパーティの開発者がメインアプリケーションの拡張であるアプリケーションを作成することを許可しました(以降、iPhoneで実行されるアプリケーション「メインアプリケーション」と呼ばれます )。 そして、時計で実行されるアプリケーションは、 「WatchKitアプリケーション」 、または単にiPhone上の「アプリケーション」です。 将来的にはApple Watch専用の開発を行うことを約束します。 現在、時計の機能はWatchKitフレームワークを介して利用でき、時計自体のプレゼンテーションで見ることができるものと比較して非常に制限されています。 Appleや他のいくつかの「選ばれた」企業の開発者は、他の開発者よりも多くの機会があることがわかります。



Apple Watchでアプリケーションがどのように配置されるかを見てみましょう。 インターフェイスの観点から見ると、Apple Watchのアプリケーションは次の部分で構成されています。

  1. アイコンがあり、時計のメイン画面から実行されるアプリケーション
  2. Glance(プレビュー)-iPhoneのウィジェットの類似物
  3. 通知


建築の観点から見ると、すべてが異なって配置されています。 アプリケーションファイルは、WatchKit AppとWatchKit Extensionの2つの部分に分かれています。 WatchKitアプリは時計に直接保存され、ストーリーボード(インターフェイスの説明)とリソースで構成されます。 WatchKit拡張機能はiPhoneに保存され、コードとリソースが含まれています。 したがって、すべてのコードは電話で実行され、近くにiPhoneがないと、時計上のアプリケーションは起動しません。 電話と時計の相互作用は、WatchKitフレームワークを介して実行され、開発者から隠されています。



各アプリケーション画面は、WKInterfaceControllerクラスのコントローラーオブジェクトによって制御されます。 Glanceや通知を含むすべてのコントローラーは、WatchKit App Storeで実行する必要があります。 ユーザーが時計でアプリケーションを開くと、WatchKitはストーリーボードで最初のコントローラーを見つけ、WatchKit Extensionを起動して必要なコントローラークラスのオブジェクトを作成する必要があることをiPhoneで通知します。 ユーザーがGlanceを開くか、通知を受け取ると、同様のアクションが発生します。



コントローラのライフサイクルは、その古いUIViewControllerのサイクルに似ています。 init、awakeWithContext:、willActivateメソッドは、次のタスクを実行するために使用されます。





初期コントローラーは重要な役割を果たします。 本質的にスクリーンコントローラーであるという事実にもかかわらず、iPhoneのアプリケーションデリゲートに似た機能を備えています。 常に最初に作成および起動され、Glanceおよび通知からWatchKitアプリケーションへの移行を処理します。 初期コントローラの初期化メソッド-アプリケーションへの最初のエントリポイント。 これは、アプリケーションが初めて自分の持っているデータを調べ、適切なインターフェースを表示できる場所です。 内部画面のクラス、数量、順序をコードから設定できる場合、アプリケーションの設計時にストーリーボードでのみ最初のコントローラーとなるコントローラーを選択できます。



WatchKit拡張機能は、ユーザーが時計を直接操作したときにのみ開始され、ユーザーがアプリケーションを終了するか、単に手を下げるとすぐに終了します。 WatchKitアプリケーションのバックグラウンドで作業するという概念はありません。 ただし、システムはアプリケーションの「スクリーンショット」を取ることができます。 手を下げたり、アプリケーションを終了し、しばらくしてから再度実行すると、終了したときと同じ画面が表示されます。 対応するコントローラーのwillActivateのみが呼び出されます。



メインiOSアプリケーションの開発との違い

メインiOSアプリケーションの開発との大きな違いは、initコントローラーの初期化メソッドが開発者ではなくシステムによって呼び出されることです。 パラメーターとデータは、コンテキストを介してコントローラーからコントローラーに転送されます。 画面から画面への移行は、セグウェイによって自動的に発生するか、ストーリーボード内のコントローラーの識別子によってコードから発生します。 どちらの場合も、WatchKitはストーリーボードで目的の画面を見つけ、その後、WatchKit拡張機能は、画面でストーリーボードで指定されたクラスのオブジェクトを(このシーケンスに従って)指定された識別子で作成し、そのinitメソッドを呼び出します。 コントローラのスタックは、システムの「内部」に残ります。 開発者はそれを認識せず、抽象的で隔離されたエンティティと同様にコントローラーのコードを操作します。



もう1つの重要な違いは、すべてのインターフェイス要素が書き込み専用のプロキシオブジェクトであるということです。 表示するテキスト、使用するフォントと色をラベルに伝えることはできません。 したがって、オブジェクトの状態を個別の変数に保存する必要がある場合があります。 また、ベースクラスWKInterfaceObjectから継承することはできません。これにより、アプリケーションの設計が複雑になり、カスタマイズされたインターフェイスオブジェクトを作成できなくなります。

通常のビュー階層でさえありません。 動的に、インターフェイスオブジェクトを作成および追加することはできません。 インターフェイス全体をストーリーボードで、つまりアプリケーションの設計段階で定義する必要があります。 リンクはIBOutletを介して行われます。 インターフェースの不必要な部分は隠されています。 ただし、1つの画面に2つの完全に代替のインターフェイスがあり、その1つがコンテキストに応じて非表示になる状況を回避する必要があります。 しかし、Glanceなどの場合には、これが唯一のソリューションです。



didDeactivateメソッドはシステムによって呼び出され、コントローラーが画面上にないことを通知します。 さらに、このメソッドの本体のインターフェースを変更したり、呼び出した後に変更したりすることは無意味です-システムはそれらを無視します。 イベントの発生時に、たとえば、現在表示されていない画面上の表示テキストを変更する必要がある場合、非常に不便です。 willActivate呼び出しまでイベントの処理を何らかの方法で延期する必要があります。 このため、willActivateは、「およびインターフェイスを再構成する必要があるかどうか」という条件の一連のチェックに変わります。

Appleは、必要に応じて遅延データの読み込みを推奨しています。 willActivateでは、メインスレッドでdispatch_asyncとdispatch_afterを使用できます。



2.電話のメインアプリケーションとの相互作用



主な難点は、iPhoneのメインアプリケーションとWatchKit拡張機能が、独自のサンドボックスを持つ2つの異なる分離プロセスであることです。 一方、時計上のアプリケーションがメインアプリケーションに追加されている場合、そのアプリケーションはその兄からデータを受信する必要があると仮定することは論理的です。 そして、ここでAppleはいくつかの方法を提供しています:



1.アプリケーショングループを使用します。これにより、共通のNSUserDefaultsを使用し、アプリケーションとその拡張機能のグループの共有コンテナにファイルを保存できます。

このメソッドを使用すると、ほぼ瞬時にデータを取得できます。 メインアプリケーションは、作業中とバックグラウンドフェッチモードの両方でグループに書き込むことができます。 いくつかの制限があります。まず、メインアプリケーションは、データが更新されたことを簡単にクロックに通知できません。 一般的なNSNotificationCenterでの単純なKVOは機能しません。 解決策:2番目の方法と組み合わせて使用​​するか、データをファイルにアーカイブし、ダーウィン通知センターを使用する1つの有名なポッドを介してデータ転送を整理します。 次に、ファイルを記録するときは、Appleからのこの警告に注意する必要があります。



2. iPhone上のメインアプリケーションと直接やり取りします。

WKInterfaceControllerクラスにはopenParentApplication:reply:メソッドがあり、これが呼び出されると、メインのiPhoneアプリケーションをバックグラウンドで起動します。 デリゲートメソッドアプリケーション:handleWatchKitExtensionRequest:reply:を呼び出して、着信リクエストを処理します。 WatchKitExtensionから、要求完了ブロックが必ず渡されます。これは、メインアプリケーションの応答としてNSDictionaryを受け取ります。 WatchKit Extensionの完了ブロックに加えて、iPhoneのメインアプリケーションがコンテキストに応じて異なるリクエストを処理できるように、任意の情報を含む辞書を転送できます。



メインアプリケーションが非同期リクエストを実行する必要がある場合(たとえば、サーバーに新しいデータを要求する場合)、バックグラウンドタスクを登録することをお勧めします。そうしないと、実行の完了を待たずにiOSが完了する場合があります。 この方法の主な制限 :それには時間がかかります。 メインスレッドをブロックし、回答を待つことは当然受け入れられません。そのため、質問が発生する理由、古いデータを表示する方法、ユーザーに何かが起こっていることを表示する方法、データを視覚的に更新する方法、エラーが返された場合の対処方法などです。 別の重大な制限 :複雑なオブジェクトは転送されません、それらをシリアル化する必要があります。 アプリケーションを設計するとき、どこからでもデータを受信する必要があることを覚えておくことが非常に重要です。 WatchKitアプリケーションの概念のいくつかの作成者は、明らかにこれについて考えていませんでした。 まだセキュリティの問題を考慮する必要があります。 表示されたデータが機密である場合、そのように保存することはできません。 この問題では、メインアプリケーションとWatchKitアプリケーションは同じように動作する必要があります。



3.時計で情報の視聴を開始し、電話で続行する方法としてのハンドオフ。

ハンドオフは非常に簡単に実装されます。 NSUserActivityタイプ名は、メインアプリケーションの* -Info.plistに追加されます。 コントローラーメソッドはupdateUserActivity:userInfo:webpageURL:と呼ばれ、パラメーター-必要なタイプNSUserActivityの名前を持ちます。 必要な追加情報をuserInfoに渡すことができます。 この時点で、アプリケーションのアイコンが電話画面の左下隅に表示され、プルアップするとメインアプリケーションが起動します。 アプリケーションデリゲートは、アプリケーションを呼び出します:willContinueUserActivityおよびapplication:continueUserActivity:restoreHandlerメソッド。userActivityを処理し、必要な情報を表示できます。 同時に、ユーザーがポケットから電話を取り出してロックを解除しようとしない場合、システム自体が処理を行い、しばらくするとアクティビティが無効になります。



Apple Watch自体は、Glanceによって生成されたものを除き、NSUserActivitiesを認識または処理しません。 しかし、それについては次のセクションで詳しく説明します。



段落を締めくくるために、Appleからのいくつかのヒントを以下に示します。

  • フレームワーク内のすべての共通コードを作成します。
  • iPhoneとApple Watch間のトラフィックは最小限に抑える必要があります。
  • 「ハード」な作業は、iPhoneのメインアプリケーションで行う必要があります。


3.概要





Glancesは重要な情報をすばやく表示するように設計されたアプリケーションで、下から上にスワイプすることで時計画面から直接呼び出されます。 実際、これらは最も関連性の高い情報(天気、株価指数、カレンダー情報、不在着信、フィットネスの目標、達成度など)を表示するスクロールアプリケーションウィジェットです。 アプリケーションカードの順序はカスタマイズ可能です。 ちなみに、これが必要でない場合は、アプリケーションにGlanceの表示がない場合があります

機能:デザイン

  • 垂直スクロールはありません。
  • ボタン、スイッチ、スライダー、メニューなどのインタラクティブな要素はサポートしていません。
  • サンフランシスコのシステムフォントのみで作業できますが、スタイルは通常、半太字、中、軽などさまざまです。
  • 2つの部分で構成される特別なテンプレートに従って構築されます。
  • 背景を見る-ぼやけた時計。
  • Appleは、マップとテーブルの使用を推奨していませんが、禁止されていません。
  • 視線は、表示される前に常に更新されるわけではなく、スクリーンショットと「最終更新日***」という碑文が表示される場合があります


機能:開発

  • 亀頭をタップすると、クロック上の対応するアプリケーションが開き、初期コントローラーが読み込まれます。 ユーザーアクティビティを通じて、亀頭からの移行を処理し、初期コントローラーから目的のインターフェイスを表示できます。
  • Glanceスクリーンコントローラーの基本クラスは、標準のWKInterfaceControllerです。 一目でライフサイクルはまったく同じですが、init呼び出しとwillActivate呼び出しの間に重要な時間が経過する場合があります。 したがって、willActivateでは、データの関連性を確認する必要があります。


亀頭の構成-2つの部分、上の部分は中心からオフセットされています。



4.通知



システムは、ストーリーボードで通知用のインターフェイスコントローラーを実装していなくても、通知用のユニバーサルインターフェイスを提供します。 しかし、もちろん、それらを美しく快適にしたいです。 ここでは、通知がユーザーを煩わせることなく、同時に現在のコンテキストに関連する情報を提供するために、適切なバランスを見つける必要があります。 ウォッチ画面は非常に小さいため、通知の文言はできる限り明確かつ短くする必要があります。 これは、キリル文字のアルファベットに特に当てはまります。 ロシア語の単語は画面上に非常に困難に配置されます。



通知は、 Short LookLong Lookの 2段階で表示されます。 通知を受け取ると、時計が穏やかに振動します。 手を上げると、ユーザーは通知の「ショートビュー」を見ることができます-ShortLookは、ユーザーがひと目で見続けるとすぐにLongLookでアニメーション化されます。



ロングルックには、通知の全文、アプリケーションのアイコンと名前、および「スキップ」通知が含まれます。 ここでは、最大4つのコンテキストアクションをプッシュできます。たとえば、アプリケーションの場合、「速度を拡張する」などです。 Dismissボタンは常にシステムによって提供されます。 他の可能なボタンとそれに対応するアクションは、通知の特定のカテゴリのUIUserNotificationSettingsを介してiPhoneのメインアプリケーションのコードに登録する必要があります。 つまり、それらはアプリケーションの設計段階で決定され、プッシュは行われません。 したがって、常にカスタムインターフェイスを表示する場合は、通知用のユニバーサルカテゴリを作成すると便利な場合があります。



ボタンアクションには、バックグラウンドとフォアグラウンドの2種類のアクティブ化モードがあります。 フォアグラウンドアクションでボタンをクリックすると、WatchKitアプリケーションが開き、handleActionWithIdentifier:forLocalNotificationまたはhandleActionWithIdentifier:forRemoteNotificationメソッドのいずれかが呼び出され、選択されたボタンの識別子を受け取ります。 背景のボタンをクリックすると、iPhoneのメインアプリケーションのバックグラウンドでアクションが起動し、アプリケーションデリゲートの対応するメソッドの1つが呼び出されます。



レイアウト通知の機能:設計

  • LongLookで異なるスタイルのシステムフォントを使用します。
  • LongLookのアプリケーションの名前でプレートの色を変更します。
  • ShortLookのGlobalTintColorを使用して、アプリケーション名の色を設定します。


ただし、通知ではボタン、スライダー、スイッチなどのインタラクティブな要素は使用できません。


通知インターフェースには、 静的動的の 2つのタイプがあります。 カスタムインターフェイスを実装する場合は、静的タイプのコントローラーを作成する必要があります。 静的なタイプのインターフェースは、動的なタイプと比較して、簡素化された一般的なタイプの通知です。 システム自体が、バッテリーとユーザー設定に応じて、選択するインターフェイスを決定します。 動的タイプは実装できません。



静的インターフェイス機能

  • すべての画像は、WatchKitアプリに含まれている必要があります。
  • インターフェイスにはテーブルとマップは含まれません。
  • 通知メッセージを表示する1つのラベルを除き、インターフェイス全体は静的です。


動的インターフェイス機能

  • 通知の内容に応じて、ラベル、画像、グループ、およびセパレータを使用および変更できます。
  • 必要に応じて、テーブルとマップを追加できます。




5.アプリケーションID:フォント、アイコン、色



ウォッチのWatchKitアプリケーション内では、タイトルと時間、およびForceTouchを介して呼び出されるコンテキストメニュー以外のフォントを変更できます。 サンフランシスコのシステムフォントパッケージにはキリル文字のスタイルはありませんが、時計自体とXcodeではすべて問題ありません。 Glanceと通知では、カスタムフォントを使用できません。



メインアプリケーション内では、すべてのヘッダーにグローバルティントカラーが設定されます。 コンテキストまたはデータに応じて実行時に変更することはできません。アプリケーション設計段階で一度設定され、アプリケーションのヘッダーの色と「ショートビュー」通知のアプリケーション名の機能を実行します。 残念ながら、PageControlの色も変更できません。コンセプトを信じないでください。 アプリのユーザーに広告を見ているように感じさせないでください。 ブランディングには、目立たないツール (色、フォント、画像) を使用することをお勧めします

ヒント:設計

  • どこにもロゴを挿入しないでください。機能を搭載せずに、使用可能な画面スペースを使い果たしてしまいます。
  • 明るい太陽のような極端な条件で読みやすいように、色は明るくコントラストが必要です。
  • コントロールの対話性を示すために色に制限されないでください-標準のボタンまたはアニメーションを使用してください。
  • テキストには特別な注意を払う必要があります。 彼らはどんな状況でもよく読まれるべきです:外出先、実行中、何でも。 テキストを小さくしすぎないようにします。
  • 時計には、写真や明るい色ではなく、黒い背景を使用することをお勧めします。 画面上の画像にはインデントがありません。そのため、物理的な製品に既にあるアプリケーションを数時間で継続します。 ディスプレイの周りに大きな黒いフレームがあるという事実により、アプリケーションと物理クロック自体の両方が単一の全体であるようです。




6.ナビゲーション



アプリケーションは2種類のナビゲーションをサポートしますが、残念ながら、これらを互いに組み合わせることはできません。



階層ナビゲーションは、UINavigationControllerを使用したiPhoneアプリケーションでのナビゲーションに似た古典的なアプリケーション管理方法であり、ユーザーはアプリケーションを「詳しく調べる」ことができます。 このタイプのナビゲーションは、情報をバッチでユーザーに転送でき、ネストレベルの数に制限がないため、最も便利で技術的に柔軟です。



ページナビゲーション (PageControl)を使用すると、ユーザーは「スワイプ」で画面間を移動できます。 このナビゲーションモデルは、シンプルなデータモデルを備えた小規模なアプリケーションに適しています。 ページナビゲーションを使用する場合、すべてのページのコンテンツが一度に読み込まれ、ページ数の動的な増加は、多くのトリックなしでは実装されません。





ヒント:開発

  • ページナビゲーションでは、initまたはawakeWithContextよりもwillActivateでインターフェイスを構成することをお勧めします。 PageControlで複数の画面をロードすると、最初の画面が表示される前にすべての画面が作成されます。 これは、すべてのコントローラーがinit、awakeWithContext:を呼び出し、最初のコントローラーのみがアクティブになることを意味します。 また、初期化で多くのアクションを設定すると、最初の画面が表示される前にユーザーに長いアクティビティインジケーターが表示されます。
  • ストーリーボードの最初のコントローラーがページナビゲーションで接続されている場合、画面間でコンテキストを転送することはできません。これにより、データを分離する独自の方法を考案できます。
  • ページコントロールを介して接続されている画面の数を動的に変更することはできません。 これを行うには、アプリケーションを完全に「再起動」する必要があります(reloadRootControllersWithNames:contexts:class WKInterfaceController method)。ユーザーの目には、何らかのエラーが発生したように見えます。


また、どのタイプのナビゲーションでも、コンテンツのモーダル表示が可能であり、ユーザーの注意を引き付けたり、アプリケーションの主要部分と対話せずにユーザーが明確な決定を下す必要がある問題を解決したりできます。 同時に、1つのウィンドウと、ページコントロールを介して接続された複数のウィンドウの両方を表示できます。 モーダルウィンドウの左隅のタイトルはデフォルトです。 モーダルモードを乱用することは非常に推奨されません。

画面間の遷移はシステムによって完全に処理され、カスタマイズしたり追加でアニメーション化することはできません。 ページナビゲーションでは、画面が左右に表示され、階層画面では、次の画面がiPhoneまたはiPadのように画面の右端からポップアップし、モーダル画面が下からポップアップします。



7.インターフェイスを介したユーザーインタラクション



ジェスチャー

ウォッチ画面は、iOSで使用されるジェスチャーの完全なリストには小さすぎます。 ユーザーが利用できるものは次のとおりです。



ジェスチャーをカスタマイズすることはできません。



コンテキストメニュー

コンテキストメニューは、強制タッチジェスチャによって呼び出されます。 1つから4つのセカンダリアクションを非表示にすることができます。 画面は本当に押し込まれているようで、コンテキストメニューが上からポップアップします。 背景は半透明で、システムビューの1〜4個のボタンがあります。

機能:デザイン

  • コンテキストメニューはアイコンでのみカスタマイズできますが、アイコンの色や円の色を変更することはできません。
  • フォントもカスタマイズできません。碑文の長さは2行に制限されています。
  • ユーザーは、ボタン、スイッチ、スライダー、テーブル(行選択)、コンテキストメニューのオブジェクトと対話できます。
  • 地図をタップすると、時計の地図アプリケーションが開きます。
  • アプリケーションの実行中に、オブジェクトの構成を変更できます(たとえば、ラベル内のテキスト)。幅と高さ、および非表示とアルファのプロパティを変更できます。
  • オブジェクトを移動する(原点を変更する)のは難しく、これを行わない方が良いです。


8.画像とアニメーション





Apple Watchには多くの美しいアニメーションがあると誤解されています。 実際、少なくともサードパーティのアプリケーションでは、間違いなく違います。 アニメーションが必要な場合は、ソフトウェアを忘れてください(またはほとんど忘れてください)。 画像のみをアニメーション化できます。 フレームごと。 つまり、古い漫画のように、アニメーションのすべてのフレームを個別にカットする準備をします。 オブジェクトを移動することはできません。 インターフェース状態間の遷移、視差効果、画面間の遷移をアニメーション化することは不可能です。 画像のフレームのみを変更します。 それだけです



バックグラウンドコントローラーWKInterfaceController、ボタンWKInterfaceButton、WKInterfaceGroupの画像を設定できます。 また、WKinterfaceImage画像を表示するための特別なオブジェクトがあります。



ストーリーボードとimageNamedで終わるメソッドのパラメーターで画像の名前を指定すると、システムはWatchKitアプリ、つまり時計に保存されている画像の中から画像を検索します。 imageおよびimageDataで終わるメソッドは、イメージがWatchKit拡張機能、つまり物理的に電話に保存されることを意味します。 したがって、それらを使用すると、画像がiPhoneから時計に転送され、遅延が発生します。 アニメーションフレームには、同じ名前にフレーム番号を加えた名前を付ける必要があります。たとえば、「image0@2x.png」、「image1@2x.png」、...、「image256@2x.png」などです。 この場合、ストーリーボードで指定するか、アニメーション開始メソッドのパラメーターで渡す画像の名前は「画像」とみなされます。



プログラムで、WKInterfaceImageのアニメーションとWKInterfaceGroupの背景を開始および停止できます。 これを行うのに最適な場所はwillActivateです。 さらに、ユーザーが画面を見た後にアニメーションを開始する場合は、開始呼び出しをdispatch_asyncまたはdispatch_afterでラップできます。 アニメーションを定期的に実行する場合は、NSTimerを使用できます。



アニメーション開始パラメータでは、次を指定できます。



機能:開発

  • アプリケーションの実行中に携帯電話から時計に画像を転送する際の遅延のため、現在の最良のシナリオは、設計段階であらゆる場面のアニメーションを作成し、時計のリソースに保存することです。
  • githubには、iOSツールを使用してアニメーションを作成し、一連の画像に変換し、リアルタイムで時計に転送できるプロジェクトが既にあります。 しかし、現時点では、これは最適なシナリオのようには見えません。
  • , 5MB. , Apple Watch , WKInterfaceDevice. , , .
  • . Devices, — Apple Watch, iOS .


— . , , , . Apple Watch, .



9. /Layout



html, . , . . — . , .







, , . . : , . , . origin, . , . . .







. storyboard. , Glance — . , . — .

:

  • Apple Watch , — 38mm, — 42mm. .
  • .
  • — .
  • , , .


おわりに



, , . , , . , — , .



, iOS , . , WWDC , , . , . : , .



, Apple Watch — " ".



また読む:

マテリアルデザイン:月と背中に

iOS-: ,

:



All Articles