こんにちは、Habr！ iOS用のMail.Ru Mailアプリを最近更新しました。 Apple Watchをサポートするようになりました。 今日は、その時点でまだリリースされていない時間にアプリケーションを開発したときに遭遇したこと、およびSDKのミニマリズムと「ライブ」デバイスでアプリケーションをテストできないことに対処する方法についてお話します。

時計のインターフェースを開発する機能

時計のコードを書くことは、iOSのコードを書くことと大差ありません。結局のところ、すべてのロジックは電話で実行されます。 ただし、ユーザーインターフェイスの開発に関しては、事態は複雑になります。時計のために、ユーザーインターフェイスでのみ使用される新しいクラスが登場しました。 現時点では、これらのクラスは11個しかありませんが、ここではiOSの最初のバージョンを思い出すことができます。 私たちは皆、将来のバージョンでその数がどのように増えたかを知っており、同様の運命が時計用のSDKを待っていることを願っています。 それまでの間、時計用UIの開発の現実は次のとおりです。

時計コンポーネントのみを使用する

時計のインターフェースを開発する際に最初に感じる失望は、以前に携帯電話用に開発した美しいボタン、アニメーション、画面をすべて忘れなければならないことです。 インターフェイスは時計の視覚的なコンポーネントのみを使用するため、これらを再利用することはできません。

新しいレイアウトモデル

最近、Appleは携帯電話に新しいレイアウトモデルを導入しました。 以前は、さまざまな要素の特定の座標と、画面が引き伸ばされたときに要素が引き伸ばされるルールを設定することが可能でした。 しかし、iOS 6以降では、自動レイアウトと呼ばれる新しいモデルが登場し、これらすべてのルールをより柔軟に設定できるようになりました。



自動レイアウトは時計でも使用できることが予想されていましたが、時計用SDKには3番目のまったく新しいレイアウトモデルが登場しました。 これは、Android SDKで使用されるものに似ています（インターフェース全体は、垂直方向または水平方向の要素で満たされたコンテナで構成されています）。

非表示で再構築

iOS SDKにはなかった興味深い機能：要素を非表示にすると、画面から消えるだけでなく、他のすべての要素が代わりになり、画面に空きスペースがなくなります。 これにより、複数の画面を一度に1つの画面に配置し、動的に切り替えることができます。



一般的に、ウォッチ用のSDKには、画面を切り替えるためのいくつかのオプションがあります。アニメーション化された画面が下からポップアップするか、アニメーション化されたままになります（マルチページインターフェイス）。 要素を非表示にする場合のエミュレーションの切り替えは、非公式で文書化されていないが、アニメーションなしで画面を変更できる興味深い代替手段です。

コントローラーインターフェイスではなくコンテキスト

iOS SDKでViewControllerを初期化してプロパティを割り当てることができる場合、クロック用のSDKでは、インターフェイスコントローラー（WKInterfaceController）の作成はシステムによって行われ、コードからアクセスすることはできません。 その見返りに、開発者はcontextと呼ばれる新しいパラメーターを受け取りました。このパラメーターは、表示されるときにコントローラーに渡すことができます。 コントローラー内では、awakeWithContextメソッドで使用できます。 コンテキストを使用して、作成時に渡すのに使用したのと同じパラメーターを渡すことができます。たとえば、子コントローラーが親に情報を渡すために呼び出す必要があるブロック、開く必要があるレターのIDなどです。

アニメーション

この時計により、アニメーションを作成する機能が大幅に低下しました。 プログラムでアニメーションを作成できるCoreAnimationおよびUIKitフレームワークはありません。 時計上の何かをアニメーション化する唯一の方法は、アニメーションGIFのような一連の画像を作成することです。



一方では、コード内でアニメーションパラメータを動的に設定できないため、この方法の柔軟性が失われます。 一方、アニメーションはデザイナーによって完全に開発され、既製の形で提供されているため、プログラマーにとってより便利になる可能性があります-再現できる画像のシーケンスとして（円で、一度だけ、または完全ではなく、一部のみ）フレームのシーケンス）。

一目

Glance（別名「プレビュー」）は、アプリケーションに情報を表示するために作成できる小さな画面です。 たとえば、未読メッセージの数と最後の未読メッセージの送信者の名前を表示します。 Glanceのインターフェースの作成は、レイアウトのセットに制限されています。 このセットには十分なオプションがありますが、提案されたものから選択する必要があります。

推奨フォントスタイル

インターフェイスエディターで、テキストフォントを設定するときに、推奨されるスタイルのセットが表示されます。 以前は、システムフォント、そのサイズとスタイル（斜体、太字など）を選択できました。 現在、ボディ、タイトルなどのテンプレートがあります。 スタイルの使用はオプションですが、可能性は、開発者がスタイルを使用するのに役立つ可能性が非常に高く、インターフェースの一貫性が向上することを期待しています。

オーバーレイ要素

iOSとは異なり、時計では要素を重複させることはできません。 この制限を回避する唯一の方法は、グループの背景を画像として設定し、グループのコンテンツに要素を挿入することです。 Mail.Ru Mailアプリケーションでは、この回避策を使用して、新しいメッセージの通知画面を表示します（テキストが表示される送信者アバター-メッセージの件名と送信者。テキストが表示されるように、グラデーションがその下に配置されます）。

属性付き文字列のサポート

時計のインターフェースで見つけた驚きの良さのうち、ラベルでの属性付き文字列のサポートに言及する価値があります。 これにより、個々のフラグメントが異なる形式でフォーマットされるテキストを描画する機会があります。 例は同じGlanceです。テキストの一部を異なる色で強調表示し、他の部分をより大きなフォントで強調表示します

フォースタッチとデジタルクラウン

この時計には、フォースタッチと呼ばれる新しいジェスチャー、つまり「強い圧力」があります。 また、Apple Watchは従来の時計からDigital Crownを継承しました。 デジタルクラウンとフォースタッチはどちらもインターフェイスコントロールであり、まだ完全には明確ではないため、これらの要素を1つのポイントに組み合わせました。 Appleは、それらがどのように使用されるのかまだ不明であるようです。 そのため、Digital Crownはリストのスクロール、ズーム、ストーリーボード要素間の移動に使用されます。



Digital Crownの動作が開発者の影響を受けず、Appleで「ハング」することに満足している場合、Force Touchで待つことにし、Mailアプリケーションの最初のバージョンにそのサポートを含めませんでした。

画像キャッシュ

時計の画像をキャッシュするメカニズムは非常に独特ですが、時計用のアプリケーションを正確に思い出すと、非常に論理的です。 要するに、メインの「ホスト」アプリケーション、WatchKit Extension-電話で実行される時計の拡張機能-および時計で直接実行される時計アプリケーションです。



ウォッチ画面に画像を追加すると、次のことが起こります。 電話のメインロジックが起動され、画像が形成されます。たとえば、インターネットからダウンロードされます。 画像は、BluetoothまたはWi-Fiを介して時計に送信されます。 その後、時計の機能が始まります。 通常のキャッシングでは、画像をアップロードしてユーザーに表示し、次回までファイルに保存します。 時計を使用すると、携帯電話のファイルに画像を入れるだけではできません。毎回時計に転送する必要があるためです。 この場合、時計には独自の20MBキャッシュがあります。



ウォッチキャッシュに画像を配置できるのは興味深いことですが、そこから取得できるのは標準のコントロールだけです。 さらに、私たちが知る限り、キャッシュ内に画像があるかどうかを理解できる間接的な兆候しかありません。 たとえば、キャッシュされた画像のサイズを調べることができるAPIメソッドを使用します。 これは次のように行われます。キャッシュされていると思われる画像の名前を持つファイルのサイズを尋ねます。 サイズが返されるかどうかによって、この画像がキャッシュにあるかどうか、または最初にアップロードする必要があるかどうかを判断できます。

applicationDidFinishLaunchingとapplicationDidResignActiveの欠如

iOSアプリケーションには独自のライフサイクルがあります。 起動、バックグラウンドへの移行、メモリからのアンロードなどが行われます。 これらのイベントが発生すると、アプリケーションは適切なアラートを受け取ります。 ウォッチにはアラートがないため、アプリケーションの起動段階でオブジェクトの作成が複雑になります。 さらに、これらのアラートに関連する作業を行っているサードパーティのライブラリに問題がある可能性があります。 たとえば、統計用のFlurryライブラリは、アラートを受信しないため、サーバー上の統計にイベントを送信しないという事実に直面しています。



問題は、すべてを一度初期化できる単一のエントリポイントを備えたiOSアプリケーションとは異なり、監視アプリケーションには、Glance、Notification、およびMain Appの3つのエントリオプションがあることです。 ただし、3つの場合すべてで、監視アプリケーションの起動は最初のコントローラーの表示に関連付けられています。 これにより、awakeWithContextメソッドを使用する機会が与えられます。

@implementation MRWKContactsInterfaceController - (void)awakeWithContext:(id)context { [super awakeWithContext:context]; [MRWKInitialization extensionDidFinishLaunching]; ... } @implementation MRWKInitialization + (void)extensionDidFinishLaunching { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ [self internalExtensionDidFinishLaunching]; }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、拡張クラスの1つでinitializeメソッドを使用できます。このメソッドは、このクラスに初めてアクセスしたときに実行されます。



オブジェクトにアクセスするときにのみオブジェクトが作成される場合、「遅延」初期化を使用することもできます。 しかし、統計の場合、これは役に立たないことに注意してください-たとえば、Flurryは、アプリケーションがいつ具体的に起動されたかを知る必要があります。

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

時計に対するアプリケーションの機能は制限されており、時計でサポートされていないアクションを実行するために、メインアプリケーションを呼び出すことができます。 これを行う方法を検討してください。

Openparentapplication

新しいAPIが登場しました- +[WKInterfaceController openParentApplication:reply:]



ウォッチアプリケーションからメインアプリケーションを呼び出し、バックグラウンドで起動し、要求されたアクションを実行して結果を返すことができます。



例：

 @implementation WKInterfaceController (MRWKParentApplicationActions) + (void)mrwk_markMessageIdAsRead:(NSString *)messageId accountName:(NSString *)accountName completionBlock:(MRWKParentApplicationActionsCompletionBlock)completionBlock { MRWKParentApplicationAction *action = [MRWKParentApplicationAction markAsReadActionWithMessageId:messageId accountName:accountName]; [self openParentApplication:action.dictionary reply:^(NSDictionary *replyInfo, NSError *error) { if (completionBlock) { MRWKParentApplicationReplyInfo *info = [[MRWKParentApplicationReplyInfo alloc] initWithDictionary:replyInfo]; completionBlock(info.success, error ?: info.error); } }]; } @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーショングループ

対話の2番目の方法は、アプリケーショングループです。 iOSでは、すべてのアプリケーションと拡張機能は別々のサンドボックスで実行されます。それらは、自分だけがアクセスできるファイルシステムの限られた領域です。 アプリケーションが共有リソースを使用したりファイルを共有したりするために、アプリケーショングループがあります。 共通のアプリケーショングループをアプリケーションとクロックの拡張子に割り当てると、両方にアクセスできるフォルダーがファイルシステムに表示されます。 特に、この機会を利用して、Mail.Ru Mailアプリケーションが何時間もメインアプリケーションのデータベース（すべてのレター、連絡先など）およびNSUserDefaultsオブジェクト（さまざまなユーザー設定）にアクセスできるようにします。

ダーウィンの通知

Darwin通知は、iOSのプロセス間でメッセージを交換する方法です。 この機能は長い間存在していましたが、拡張機能、特に時計の拡張機能の出現に関連するようになりました。 Darwin通知を使用すると、メインアプリケーションで何かが変更された場合にウォッチにアラートを送信できます。たとえば、連絡先リストがウォッチで開いている場合、この時点でメインアプリケーションに新しい連絡先が追加されます。 Darwin通知を使用すると、メインアプリケーションからイベントを送信して、ウォッチがデータベースの連絡先リストを更新できるようになります。

ハンドオフ

iOSの最新バージョンでは、Appleが積極的に推進しているHandoff機能が導入されました。 ハンドオフは、メインアプリケーションと対話する方法と見なすこともできます。 ここでは、相互作用は直接的なデータ交換ではなく、たとえば、時計からのアクティビティの作成であるため、メインアプリケーションを開くと、特定の画面がすぐにロードされます。 たとえば、ユーザーがMail.Ru Mailを開いて時計に文字を書き始め、iPhoneでアプリケーションを起動した場合、ハンドオフを使用すると、携帯電話のメッセージ作成画面をすぐに自動的に開くことができます。

デバイスなしの開発

Apple Watchの開発の主な落とし穴は、実際のデバイスでどのように記述するかを理解できないことです。 シミュレータのみが表示されますが、これはその近似の一部にすぎません。 公式文書でも、現実と矛盾しています。

複数の通知を受け取る

シミュレータのいくつかの側面は、原則として反映されていません。 たとえば、ドキュメントには次のケースが記載されています。複数の通知が届くと、丸いアプリケーションアイコンと「N個の新しい通知」というテキストが画面に表示されます。 ただし、シミュレーターでは、どのように見えるかを確認することはできません。 些細なことのように思えますが、実際にはこれは予期しないものになる可能性があります。アプリケーションの名前は予想したものとは異なり、アイコンは正しく表示されません。これを予測することはほとんど不可能です。 リスクを最小限に抑えるためにできる唯一のことは、すべてを完全に文書化することです。

絵文字

プレゼンテーションで、Appleは時計にカスタマイズ可能な美しいアニメーション絵文字が搭載されると言われました。 私たちのアプリケーションはそれらをサポートしています-手紙を書くための標準画面から絵文字を追加できます。 ただし、レターでどのように見えるか、プログラムにどのような形式で来るか、レターに挿入するためにどのように変換する必要があるかは不明です。 これらは通常の絵文字であるという前提がありますが、アニメーションGIFまたは以前に知られていない何かの形で提供される可能性があります。 また、形式はドキュメントで指定されていません。 メールアプリケーションの最初のバージョンでは、絵文字がテキスト形式で提供されるという前提から進めることにしました。

音声ダイヤル

手紙を書くことに関連するもう一つのあいまいさは、音声ダイヤルの仕事です。 一般的には、すべてが明確です。マイクをクリックすると、入力したテキストが表示されます。 ただし、ここでは微妙な違いが考えられます。たとえば、1行のテキストを返すことはできませんが、ユーザーが指示した内容のいくつかのオプションが返されます。

不正ユーザー

次の例はあいまいです。Mail.RuMailアプリケーションを電話にインストールしたが、それを起動したことがなく、その結果ログインしなかったとします。 この場合、時計アプリケーションは利用可能になりますか、ユーザーはApple Watchディスプレイから起動できますか？ クロックのリリース後にのみ明確な答えが見つかりますが、起動が可能な場合に備えて安全にプレイすることにしました。権限のないユーザーは「電話でアプリケーションを開いてログインします」というメッセージを受け取ります。

ハンドオフ

Handoffが時計でサポートされることが発表され、ドキュメントには同じことが示されています。 ただし、シミュレータがハンドオフをサポートしていないため、これがどのように機能するかを検証することはまだできません。 繰り返しになりますが、実際のデバイスを待つ必要があります。

静的/動的通知

プッシュ通知が到着すると、ウォッチは最初に動的な通知、つまりより複雑なインターフェースを表示しようとします。 ダウンロードが遅れると、よりシンプルなインターフェース-静的通知が表示されます。 残念ながら、シミュレータを使用してこれがどのように発生するかを確認することは不可能です。

通知：電話と時計の間の「分業」

一部のアクションは通知に関連付けられています。レターに返信、削除、既読としてマークすることができます。 これらのアクションには、ウォッチ拡張機能によって処理されるものと、メインアプリケーションによって処理されるものがあります。 メインアプリケーションによって処理されるアクションをシミュレータでテストすることはできません。 これらのアクションは電話から直接呼び出すことができますが、時計から呼び出そうとすると、シミュレーターは時計の拡張機能で処理しようとしますが、実際にはアプリケーションによって処理されます。 この動作は、シミュレーターが原則としてプッシュ通知をサポートしていないという事実によるものです-電話でも時計でもありません。 ただし、監視用SDKでは、開発環境から監視用アプリケーションを起動するときに、プッシュ通知の内容を「パームオフ」して、処理方法を確認できます。 問題は、考えられるすべてのケースをテストする方法がないことです。 たとえば、時計のメインアプリケーションまたは拡張機能である通知の処理方法を指定することはできません。 電話で（実際のデバイスで）通知からアクションを呼び出し、時計でこれが同じように機能することを期待することで、アプリケーションによって処理されるアクションのチェックに限定する必要がありました。

Xcode開発

Xcodeを使用するすべての人は、Xcodeにエラーがあることを知っています。新しいバージョンでは新しいコピーが表示されます。 WatchKit SDKも例外ではありません。

配布用証明書

Xcodeは最近、自動コード署名とプロビジョニングに着手しました。 理論的には、Xcodeはすべてのプロファイル、必要な証明書、バンドルIDを作成します。 実際には、彼女はいくつかのケースでこれを行いますが、すべてではありません。 特に、ウォッチの配信プロファイルは自動的に作成されず、開発者向けのAppleポータルで個別に作成する必要があるという事実に直面しました。

38/42 mmの個々のフィレット半径の定義

インターフェイスビルダーでは、38 mmと42 mmの時計の要素の個々のプロパティを設定できるようになりましたが、場合によっては機能しません。 たとえば、時計のさまざまなバージョンのグループに丸みの半径を設定した場合、何も丸くなりません。 このバグを回避するには、グラフィカルインターフェイスエディターではなくコードでフィレットを設定しました。

RemoteInterfacePrincipalClass

ウォッチのplistアプリケーションには、特に不明なRemoteInterfacePrincipalClassプロパティという新しいプロパティが登場しました。 一方では設定されているように見えますが、他方では経験から判断すると、このプロパティの値は何にも影響しません。 実際の時計に表示される場合に備えて、正しいクラス名を入力しました。

SPErrorGizmoInstallNeverFinishedErrorMessage

シミュレーターに問題があります。 時々、ある監視アプリケーションを起動し、それを操作し、停止し、別の監視アプリケーションを起動しようとすると、シミュレーターはそれをインストールすることを拒否し、字幕の奇妙な名前でエラーを出します。 シミュレーターを削除し、すべてのコンテンツをダンプし、完全なクリーンプロジェクトでのみ処理します。

アプリケーションと拡張機能の間のコードの分離

最後に、プロセスの最適化に関するいくつかの言葉。 時計用のMail.Ru Mailのアプリケーションと拡張機能は、同様の機能を実行します。どちらも、連絡先リストの表示、電子メールの送信などを許可します。したがって、時計のメインアプリケーションのコードの一部を再利用することは理にかなっています 以下は、共有コードの割合を増やすためのアクションのリストです。

• 当初、コードの記述はモジュール式であるため、個々のクラスを拡張機能で使用するには、依存関係を追加する必要がありません。依存関係は、作業には必要ないかもしれませんが、コンパイルには必要です。
• CocoaPods-Objective-Cの依存関係管理システムを使用します。 CocoaPodsでは、特定のライブラリを特定のターゲットに追加できます。 これにより、依存関係の大きなリストをメインのMail.Ru Mailアプリケーションのターゲットに接続し、この大きなリストから必要なライブラリのみをクロックターゲットに接続できます。
• iOS 7のサポートを既に放棄している場合は、ダイナミックフレームワークを使用してください。
• スクリプトを使用してプロジェクトファイルを確認します。 コードがCocoaPodsではなく手動で接続されている場合、そこで使用されるファイルのみがターゲットに含まれていることを確認する必要があります。 私たちの場合、構成ファイルでは、メインターゲットとクロックターゲットの間にあるはずのすべての違いが設定され、スクリプトはこれをすべてチェックします。
• メインアプリケーションのクラスを数時間で使用するよりも効率的な場合は、APIを介してメインアプリケーションを呼び出します。

おわりに

私たちの経験をまとめると、次の（かなり明白な）デバイスなしの基本的な開発ルールを自分で特定したと言えます。

• テスト中に問題をキャッチすることはほとんど不可能なので、ドキュメントを徹底的に研究してください。
• 主なオプションに加えて、安全ベルトを実装します-デバイスが期待どおりに機能しない場合。
• 公式のポッドキャストからオタクのポッドキャストまで、デバイスに関するあらゆる情報源を使用します。

ここ、Habréには、何らかの理由で開催できないデバイスを開発する必要性に既に直面している多くの人々がいると思います。 コメントでは、そのような場合にどのようにあなたの人生を楽にすることができるかについての経験を共有することを提案します。