iOSのマイクロインタラクション。 ヤンデックス講義

数週間前、CocoaHeadsコミュニティの特別なイベントがYandexオフィスで開催されました。これは従来のmitapよりも大きなものです。 開発者のアントン・セルゲイエフは、この会議で講演し、UXデザイナーが通常使用するマイクロインタラクションモデルと、そのアイデアを実践する方法について話しました。 アントンはアニメーションに最も注意を払いました。





-ゲストに会えて光栄だったことは私にとって非常に重要です。 ここでは、私が非常に長い間知り合っていた人、最近知り合った人、まだ会っていない人がいます。 CocoaHeadsへようこそ。



微小相互作用について説明します。 これはちょっとしたクリックです-私たちはエンジニアであり、開発者です。ソフトウェアの部分について詳しく説明しますが、まずはマイクロインタラクションなどの非常に人道的なトピックから始めましょう。 その結果、ボタン、小さなローダー、バーなどの非常に小さな視覚コンポーネントをより効率的かつ簡単に設計する方法を学ぶために、技術的な部分にこの人道的テーマを適用します。 それらはアニメーションで飽和しており、分岐したアニメーションコードは非常に複雑に見えることが多く、維持するのは非常に困難です。



しかし、最初に、少し気を散らす。 それについて考えてください。開発者になることに決めたときのことを覚えていますか？ はっきり覚えています。 すべてはテーブルから始まりました。 ObjCを学ぶことに決めました。 ファッショナブルな言語、楽しい、そのように、広範囲にわたる計画なし。 ビッグオタクランチの本を見つけて、章ごとに読み始め、各エクササイズを行い、チェックし、読んで、テーブルにたどり着きました。 その後、私は最初にデリゲートパターン、より正確にはそのサブ種である「データソース」、データソースに精通しました。 このパラダイムは、今では非常に単純に思えます。データソース、デリゲートがあり、すべてが単純です。 しかし、それは私の心を吹き飛ばしました：完全に異なるデータからテーブルを分離するにはどうすればよいですか？ 紙の上にテーブルがあり、そこに無限数の行、完全に抽象的なデータを入れることができました。 私に大きな影響を与えました。 プログラミング、開発には大きなチャンスがあり、それらを適用することは非常に興味深いと思いました。 それ以来、私は開発者になることを決めました。



開発中に、さまざまなパターンに遭遇しました。 巨大な、アプリケーション全体を記述するアーキテクチャと呼ばれます。 小さなボタンに数十個収まる小さなもの。 これらのすべてのパターンは、空中からではなく、人道的セクターからのものであることを理解することが重要です。 同じデリゲートパターン。 委任はプログラミングのずっと前に登場し、プログラミングはより効率的な作業のためにこれらすべての人道的事項を採用しています。



今日は、別の人道的なことを引き継ぐ別のアプローチについてお話します。 特に、マイクロ相互作用について。



それはすべてローダーから始まりました。 Yandexの前の前の仕事で、Googleマテリアルデザインローダーを繰り返す作業をしました。 それらは2つあり、1つは不定、もう1つは定義済みです。 私はそれらを1つに結合する仕事がありました、彼は特定と不定の両方をすることができなければなりませんでしたが、厳しい要件がありました-それは非常にスムーズでした。 いつでも、ある状態から別の状態に移行でき、すべてがスムーズかつ正確にアニメーション化される必要があります。



私は賢い開発者です、私はすべてをしました。 わかりにくい麺のコードが1000行以上ありました。 それは機能しましたが、コードレビューに関するクールなコメントを受け取りました：「誰もこのコードを編集しないことを本当に願っています。」 そして、私にとってそれは実際には不適切です。 私はひどいコードを書きました。 クールに動作し、私の最高のアニメーションの1つでしたが、コードはひどいものでした。



今日は、その仕事を辞めた後に見つけたアプローチを説明しようと思います。







最も人道的なトピックであるマイクロ相互作用モデルから始めましょう。 それらはどのように埋め込まれ、一般的にアプリケーションのどこに隠されていますか？ 私たちは技術の世界でこのモデルを使い続けています。 レンダリングとアニメーションを扱うUIViewがどのように機能するかを見てみましょう。 特に、UIViewのCALayerと密接に統合されて動作するCAActionメカニズムについて詳しく説明します。 そして、小さな例を考えてみましょう。



最初に定義。 どうやら、著者は接頭辞「マイクロ」が本当に好きでしたが、マクロやナノの相互作用はなく、サイズは関係ありません。 簡単にするために、単に相互作用と呼びます。 これは、アプリケーションとのやり取りを最初から最後まで記述できる便利なモデルです。 4つのポイントで構成されます。トリガー、この対話で実装する必要があるビジネスロジック、ユーザーに何かを伝えるためのフィードバック、アプリケーションの状態の変更です。



1つのストーリーを3つの異なる役割で説明します。 開発で最も重要なこととして、ユーザーから始めます。 報告の準備をしているときに、病気になりました。 私は薬局を見つける必要があり、Yandex.Mapを開きました。 私はアプリケーションを開き、それを見て、それは私を見て、何も起こりません。 その後、私はユーザーであり、私がメインであることに気付きました。アプリケーションで何をすべきかについて指示を出します。 私は向きを決め、「検索」ボタンをクリックし、「薬局」と入力し、「OK」をクリックしました。アプリケーションは内部作業を行い、私の隣にある必要な薬局を見つけて、画面に表示しました。



私は正しいものを検索し、薬局に加えて、特別なボタンが画面に表示されていることを発見しました-ルートを構築します。 したがって、アプリケーションは新しい状態に移行しました。 私はそれをクリックして、薬局に行きました。 薬局を見つけるために-私は何らかの理由でこのアプリケーションに入った。 私は彼女に連絡しました。 私は幸せなユーザーです。



このアプリケーションが登場し、その中から何かを探すことができるようになる前に、最初に開発されました。 このプロセスを思いついたとき、UXデザイナーはどう思いましたか？ すべては、ユーザーとアプリケーションがお互いを見るときにミュートシーンから抜け出す必要があり、何も起こらないという事実から始まりました。 このためには、何らかのトリガーが必要でした。 すべてに始まりがあり、ここでも、どこかから始める必要がありました。



トリガーが選択されました-検索ボタン。 クリックすると、技術的な観点から問題を解決する必要がありました。 サーバー上のデータを要求し、応答を解析し、何らかの方法でモデルを更新し、分析します。 ユーザーの現在の位置などを要求します。 そして、このデータを得て、すべての薬局がどこにあるかを正確に把握しています。



これで終了するようです。 結局、問題を解決し、すべての薬局を見つけました。 問題が1つだけあります。ユーザーはまだこれらの薬局について何も知りません。 彼はそれを理解する必要があります。



どういうわけか、この問題の解決策をまとめて、彼がそれを理解できるように、美しいパッケージでそれを彼に届ける。 ユーザーは人間であり、感覚を通じて外の世界とやり取りすることがありました。 技術の現状では、モバイルアプリケーションの開発者として、視覚-画面に何かを表示すること、聴覚-スピーカーで再現すること、触覚を使用することで、ユーザーを手で押すことができます。



しかし、人間ははるかに機能的です。 しかし、技術の現状は、現時点ではこれら3つにしか頼ることができないようなものです。 この場合、画面を選択し、必要な最寄りの薬局を地図の上部に表示し、これらの薬局に関する詳細情報のリストを表示します。 そして、これはまさにすべてであり、ユーザーは薬局を見つけ、すべてがうまくいくように思われます。



しかし、問題があります。 ユーザーがアプリケーションを入力したとき、彼は薬局の場所がわからない状況にありました。 そして彼の仕事は彼女を見つけることでした。 しかし、今では状況が変わっており、薬局がどこにあるかを知っており、もはや薬局を探す必要はありません。 彼には次の仕事がありました-次の薬局への道順を取得すること。 そのため、画面に追加のコントロールを表示する必要があります。特に、これはルートを構築するためのボタンです。つまり、アプリケーションを別の状態に移行し、次のインタラクションの新しいトリガーを再び受け入れる準備ができています。



UXデザイナーがこのすべてを思いついて、開発者のところに来て、ユーザーがボタンをクリックする方法、どのように、何が起こるか、どのように検索されるか、ユーザーがどのように満足しているか、DAUを増やす方法などについて説明し始めると想像してください。 最初にボタンについて言及したとき、開発者からの未解決の質問のスタックは、最初の文のどこかであふれていました。



彼は根気よくすべてに耳を傾け、最後に、それが終了したら、大丈夫、これはクールだと言いますが、ボタンについて議論しましょう。 これは重要な要素です。



議論の中で、ボタンは本質的にトリガーであり、それ自体にロジックが含まれており、特に、ユーザーが画面をクリックしたことに関するメッセージをシステムから受信できることがわかりました。 このクリックに基づいて、彼女はイベントのチェーンを開始できます。これは、同じボタンがさまざまなプロセスを開始する必要性に関するメッセージを異なるオブジェクトに送信することから始まります。



ボタンを押すと、ボタンの状態が変わり、ボタンが押されます。 ユーザーが離すと、押されなくなります。 つまり、ユーザーにフィードバックを提供し、ユーザーがこのボタンに何を期待するかを理解できるようにします。 また、ボタンはさまざまな状態で押したり、押したり、アクティブまたは非アクティブにしたり、状態ごとに異なるロジックに従って移動したりできます。



したがって、トリガー、ビジネスロジック、フィードバック、および状態の変更で構成される同じマイクロインタラクションモデルが、ユーザーケース全体のスケール、最寄りの薬局の大規模な検索など、さまざまなスケールでアプリケーションを記述できることがわかりました。だから、小さなボタンの面で。



これは非常に便利なモデルであり、チーム内のやり取りを簡素化し、トリガー、ビジネスロジック、フィードバック、状態変更という4つのエンティティを個別にプログラムで記述することができます。 これを使用するためにUIKitが提供するものを見てみましょう。 そして、提供するだけでなく、使用します。 UIViewサブクラスの小さなコンポーネントであるさまざまなアニメーションを実装する場合、このメカニズムのみを使用し、別の方法では使用しません。



UIViewから始めましょう。UIViewがこのモデルにどのように適合するかを見てみましょう。 次に、これらの状態をサポートするために提供するCALayerを検討し、最も興味深い瞬間であるアクションのメカニズムを検討します。



UIViewから始めましょう。 これを使用して、画面にいくつかの長方形を表示します。 しかし、実際には、UIViewはそれ自体を描画する方法を知りません。これには別のCALayerオブジェクトを使用します。 実際、UIViewは、UIViewのサブクラスで定義したAPIについての他の呼び出しと同様に、システムに触れることに関するメッセージの受信に取り組んでいます。 したがって、UIView自体がトリガーロジック、つまり、いくつかのプロセスの起動を実装し、システムからこれらのメッセージを受信します。



UIViewは、発生したイベントをデリゲートに通知したり、サブスクライバーにメッセージを送信したりすることもできます。たとえば、UIControlを異なるイベントにサブクラス化します。 このようにして、このUIViewのビジネスロジックが実装されます。 すべてにビジネスロジックがあるわけではなく、それらの多くは表示要素にすぎず、ビジネスロジックの意味でのフィードバックはありません。







トリガーとビジネスロジックの2つのポイントに注目しました。 また、UIViewのフィードバックと状態変更はどこに隠れていますか？ これを理解するには、UIView自体が存在しないことを覚えておく必要があります。 作成されると、CALayerのサブクラスであるバックレイヤーを作成します。







そして、彼の代理人を任命します。 UIViewがCALayerを使用する方法を理解するために、さまざまな状態で存在できます。



ある状態を別の状態と区別する方法は？ それらはどこかに保存する必要があるデータのセットが異なります。 CALayerがUIViewに提供する機能を考慮して、状態を保存します。







UIViewとCALayerの間のやり取りであるUIViewには、CALayer内のストレージを更新するという追加のタスクがあります。



ほとんど知られていない事実：CALayerは連想配列として動作できます。つまり、次のように任意のキーに任意のデータを書き込むことができます：setValue（_：forKey :)。







このメソッドはすべてのNSObjectサブクラスに存在しますが、他の多くのサブクラスとは異なり、オーバーライドされていないキーを受信して​​もクラッシュしません。 そして彼はそれを正しく書き留め、それから私たちはそれを読むことができます。 これは非常に便利なことで、CALayerのサブクラスを作成することなく、そこにデータを書き込んでから、それらを読み取って、参照することができます。 しかし、これは非常に原始的な単純なリポジトリであり、実際には1つの辞書です。 CALayerははるかに進歩的です。 スタイルをサポートします。



これは、CALayerが持つStyleプロパティによって実装されます。 デフォルトでは、nilですが、再定義して使用できます。







一般に、これは通常の辞書であり、それ以上ではありませんが、NSObjectが持つ別のメソッドforKeyの値を要求すると、CALayerがどのように動作するかについての特性があります。 非常に興味深い動作をし、スタイル辞書で必要な値を再帰的に検索します。 スタイルキーを使用して既存のスタイルを新しいスタイルにパックし、そこにいくつかのキーを書き込むと、次のようになります。







最初にルートを確認し、次に内陸などを意味がわかるまで確認します。 スタイルがnilになった場合、さらに見ていく意味はありません。



このように、UIViewは、CALayerが提供するインフラストラクチャを使用して、状態変更を整理し、スタイル、スタックをシミュレートできる非常に強力なリポジトリ、または非常に効率的で非常に便利な通常の連想配列を使用して、内部CALayerリポジトリを更新できます。



ストレージで終了し、CAActionで開始します。 彼についてもう少し説明します。







UIViewに新しいタスクがあります-CALayerにアクションを要求するためです。 アクションとは何ですか？







CAActionは、実行メソッドが1つしかないプロトコルです。 Appleは一般的に映画のテーマが大好きで、ここでのアクションは「カメラ、モーター！」です。 その「モーター」は単なるアクションであり、その名前が使用されただけではありません。 runメソッドは、開始、実行、および終了できるアクションを開始することを意味し、これは最も重要です。 このメソッドは非常に汎用的であり、イベント文字列のみを持ち、その他はすべて任意のタイプにできます。 ObjCでは、これはすべてidであり、通常のNSDictionaryです。







UIKitの内部には、CAActionプロトコルを満たすクラスがあります。 最初はアニメーションです。 まず、アニメーションをレイヤーに追加できることを知っていますが、これは非常に低レベルのものです。 その上の高レベルの抽象化は、レイヤーで必要なパラメーターを使用してアクションを実行することです。



2番目の重要な例外はNSNullです。 彼はどのメソッドからも呼び出せないことを知っていますが、CAActionプロトコルを満たします。これは、レイヤーでCAActionを簡単に検索するために行われます。







前述したように、UIViewはCALayerのデリゲートであり、デリゲートメソッドの1つはアクションです（for：forKey :)。 レイヤーにはメソッドforKeyがあります。







レイヤーでいつでも呼び出すことができ、いつでも正しいアクションまたはnilを与えることができます。 アルゴリズムは非常に珍しい検索です。 擬似コードはここに記述されています。行を見てみましょう。 そのようなメッセージを受信すると、彼は最初に代理人と相談します。 デリゲートはnilを返すことができます。これは、検索が他の場所で続行されることを意味するか、有効なアクション（CAActionプロトコルを満たす有効なオブジェクト）を返す場合があります。 しかし、論理的なルールがあります。このプロトコルを満たすNSNullを返す場合、後でnilに変換されます。 つまり、Nullを返す場合、実際には「検索を停止する」ことを意味します。 アクションはなく、必要ありません。



しかし、次のことがあります。 彼は代理人と相談し、代理人がnilを返した後、検索を続けます。 まず、レイヤーが持つアクション辞書で、スタイル辞書を再帰的に検索します。アクション辞書には多くのアクションを書き込むことができるアクションキーを持つ辞書があり、再帰的に検索することもできます。 それがうまくいかなかった場合、彼はクラスにデフォルトのアクションforKeyメソッドを要求します。これはCALayerによって定義され、最近まで何かを返していましたが、最近の最新バージョンのiOSでは常にnilを返します。



理論を理解しました。 実際にすべてがどのように適用されるかを見てみましょう。



イベントがあり、キーがあり、これらのイベントに対していくつかのアクションが実行されます。 基本的に、2種類のイベントを区別できます。 1つ目は、保存されたプロパティのアニメーションです。 Viewcolorcolor = redを呼び出すと、理論的にアニメーション化できると仮定します。







パターンのないパターンに関するレポートは何ですか？ カップルを描きました。 UIViewには、サブクラス用に定義したある種のインターフェイス、またはイベントでシステムから受信するインターフェイスがあります。 UIViewのタスクは、目的のアクションを要求し、内部ストアを更新して、発生したアクションを起動することです。 順序は、リクエストに関して非常に重要です：アクション、アクションの更新のみ、ストアとアクションの更新のみ。







UIViewでbackgroundColorを更新するとどうなりますか。 UIViewでは、画面上の表示に関連するすべてのものがCALayerのプロキシであることを知っています。 念のため、取得したすべてをキャッシュしますが、同時にすべてがCALayerをブロードキャストし、CALayerでさらにすべてのロジックを処理します。 バックグラウンドを変更するタスクを受信すると、CALayerの内部で何が起こりますか？ ここではすべてが少し複雑です。







手始めに、彼は行動を求めます。 そして、最初にアクションが要求されることを理解することが重要です。 これにより、backgroundColorを含むアクションの作成時にCALayerに現在の値を問い合わせることができ、その場合のみストアが更新され、受信したアクションがrunコマンドを受信すると、CALayerに問い合わせて新しい値を取得できます。 したがって、彼は古いものと新しいものの両方を所有し、必要に応じてアニメーションを作成できます。



しかし、UIViewには1つの機能があります。UIViewでbackgroundColorを変更すると、アニメーションブロックでこれを行うとアニメーション化され、アニメーションブロック外にある場合はアニメーション化されません。







すべてが非常に簡単で、魔法はありません。 ただし、UIViewはCALayerのデリゲートであり、そのようなメソッドがあることを覚えておいてください。 すべてが非常に簡単です。



このメソッドがアニメーションブロックで実行された場合、何らかのアクションを返します。 アニメーションブロックの外側にある場合、このメソッドはNSNullを返します。つまり、何もアニメーション化する必要はありません。 , CALayer .



, UIView , . . ?







, . UIView , read only, , inheritedAnimationDuration. . , . .



? duration, . , run, , .







, CAAction, backgroundcolor opacity, UIView . , , , , . . setValue forKey , , , , , , .



, , , , .



— . , «» «» . .



.







. , , , . UIView CALayer, , , CAAction, , , .











, , , . , . .



. - .



CAAction, , . , , , .







, , , home, . , . , .







. - .







, - , - . , , . , .



, , .







, CAAction , . , UIControl, - , - , , , - .



, . , UIView -, , - , , , .



— . .



? . , . — . activating, inactive active. , , .







. , onOrderIn onOrderOut. , UIKit, .



, -, — , .







. UIView , : isActive progress. . CAAction, .



, . , , 30 CAACtion, . , 30 , NSNull. 15 15 . . — . , — .



, . .



. , , : , -, .



, , . . , UIKit , . . , , , . ご清聴ありがとうございました。