20時間で優れたVKontakteニュースフィードを作成する方法

みなさんこんにちは！ 最近、VKontakte Mobile Challengeからコンテストがあり、私の作品が賞を受賞しました。 第2段階の指示では、モバイルデバイス用のニュースフィードを開発する必要があり、主な評価基準はスムーズなスクロールとポストロードでした。 参加したとき、最終結果に関係なく、テープの実装へのアプローチと、コンテスト中の感情や感情についての記事を書くことにしました。 私がやった。 ストーリーテリングモードでニュースフィードを開発するための猫のヒントとコツ。

コンテストについて

まず第一に、競争について少し話す価値があります。 私が知っているように、VKontakteは毎年モバイル開発者向けのイベントを開催しています。 私自身は2012年と2013年にすでに参加しています。 タスクは、それぞれチャットと画像フィルターの開発でした。 2013年に、私はなんとか最終ラウンドに到達し、100,000ルーブルで勝ちました。それは、4日間の興味深い仕事で非常に良い金額に思えました。



そして、ソーシャルネットワークで広告を見て、試してみることにしました。なぜなら、クールなことは、非常に短時間で高品質のコードを記述できることを自分自身に証明することだからです。

競争には2つの段階がありました：最初の段階では、30の質問のテストに合格し、2つのオリンピアードの問題と1つの高品質の問題を解決することが提案されました（つまり、解決策はテキスト形式の一連の思考です）。 1000人以上の第2ラウンドでは、112のみが通過し（iOSについてのみ話し、Androidでは少し低い値）、メインステージ-アプリケーション開発が始まりました。



指示では、ニュースフィードを作成し、VK APIとの統合を自分で記述する必要がありました。フィードはすべてのデバイスで非常にスムーズである必要がありました。コンテンツの出力には特定の要件がありました（画像とカルーセルを含む投稿、いいねのカウンター、共有、ビューの数、最小化する機能）特定の条件下で投稿を展開します）。



レイアウトがFigmaにアップロードされました。 これは競争にとって良い選択です-アクティブなユーザーの数のために、競争はすぐに感じられます（そして、同時接続の50の制限を超えたため、土曜日にノックアウトされました）。



一般に、いくつかの点を除いて、競争の組織はスムーズでした：タスクの公開直後、レイアウトへのリンクが壊れていたことが判明し、前述のように、土曜日にFigmaへの入り口がブロックされました（この問題は非常に迅速に修復されました）、イベントの後、かなり時間がかかりました結果を期待します。 しかし、すべての否定は同様の投稿をスムーズにします：

勝利の計画と戦略

競技会に参加したり、試してみたい場合、非常に重要で興味深いブロックです。 参加する前に、皆さんがどのような目標を追求し、どのような結果を達成したいかを考えることをお勧めします。 コンテストを開始する前に、自分で優勝したい（つまり、賞品を獲得する）ことを決めました。 これを行うには、戦略が必要です。









勝利戦略の公式は次のとおりです（普遍的でシンプルなようですが、ほとんどの参加者はそれに従わないと確信しています）。

• 課題を注意深く読んでください 。 数時間後、もう一度読んでください（初めてタスクを知覚しなかったときに何度か状況に陥りました）。 念のため、配達の数時間前にもう一度。
• 質問を作成して主催者に尋ねます （通常、割り当ての要件は多くの状況を考慮していないか、非常に表面的に公開されています）。 私はそれをして、「あなたの選択」のスタイルで答えを得ました。
• プロジェクト計画を立てます。 はい、コンテストやハッカソンへの参加はプロジェクトです。 プロジェクトには、目標、スケジュール、リソース、予算があります。 時間は厳密に制限されており、変更の終わりを移動することは不可能です。 追加の人を招待することはできません-競技はチーム競技ではありません。 あなたが持っているすべてはあなた自身の人々です。 /時間。 どれだけの時間を費やすかをすぐに決定します（睡眠、食事、去勢、休憩にどれくらいかかるかをよく考えてください。そうです、容赦ない時間枠の前での無力感から疲労や神経のために生産性が低下します）。
• 計画には、タスク、その優先順位、および重みが必要です （フォーム1、2、4、8の推定値を使用しました）。 評価には、期間、それを実行する意思がないこと、および潜在的なリスク（複雑さ、理解できない条件、そのような開発の経験がないなど）が含まれます。 次に、詳細な計画（またはロードマップタスク）を作成します。最初に最も重要で複雑なものを作成します（最後に簡単で理解しやすいものにします）。
• いくつかの大きな間隔またはマイルストーンを選択します （日は素晴らしいです-3日間ありました）。 そして、それぞれを検討しながら、作業計画を確認し、タスクを分解し、ソートし、そして最も重要なこととして、あなたがすでに喜んでやったことを消し去ります。
  
  ここでのアドバイス（私はまさにそれを行いました）：タスクに「必須」と「追加」という単語が含まれているかどうかを慎重に調べます。 そして、「追加」からのアイテムの評価基準は何ですか。 「必須」セクションの実装要件の欠如を無効にするかどうか。 私はそれを疑います。 したがって、「必須」セクションに注目してください。 私自身のために、私は一般に「高度な」セクションを意図的に取り消し、開始するつもりさえありませんでした。
• 実装するときは、詳細に注意してください 。 たとえば、タスクに多数のインターフェイスフォームがある場合は、レイアウトに表示される方法で実行します。 インデント、フォント、影、行間隔などに注意してください。 これにより、正確さと一貫性の点が確実に追加されます。 ちなみに、Figmaでは、Zeplinとは異なり、非常に幅広い設定のエクスポートがあります。たとえば、適切なNSAttributedStringを取得できます。

ミッションは木曜日から金曜日の夜に開かれました。 金曜日は就業日であり、職場で競争に参加する機会と希望はありませんでした。 したがって、金曜日の夜に仕事から戻った後、私は最初にどれだけの時間を費やすことができるかを計画、評価、および計算しました。



最初の計画は次のとおりです。

日	時間	タスク
金曜日	4時間	承認、プロファイルおよびテープのデータの取得。
土曜日	9時間	さまざまな高さの赤い正方形のディスプレイを備えたテープのプロトタイプで、プルツーリフレッシュで上にロードし、履歴に無限にロードし、すべてのモデルとサービスを準備します（APIの操作、キャッシュのキャッシュ、イメージのキャッシュ）。
日曜日	9時間	実際のデータ（テキスト、単一の画像、カルーセル）、いいねのカウンター、ビュー、レイアウトによる最終調整の出力。

テープ実装技術

やった！ 紳士、開発者、あなたは正しいブロックを見つけました。 ここでは、タスクの主要部分であるニュースフィードの実装について説明します。



一般的に、ニュースフィードを解除する場合、ニュースフィードは単に適用された実装です。一般に、異種エンティティのリストの作成について説明します（つまり、それぞれが独自の表示を持つことができ、追加の計算と独自の高さが必要です。 、さらにリストはプルトゥリフレッシュを介して更新でき、下から無限にデータをロードできます。



そもそも解決しようと決めたのは一般的な問題でした。 最初のステップは、既存のソリューションを分析することです。 あなたは最強のものに集中する必要があるので、比較のために3つのアプリケーションを選択しました：Vkontakte、Facebook、Instagram。



それで、私は6つの最も深刻で重大な問題の研究を行いたかったのです。

1. プルトゥリフレッシュ（リストの一番上に追加）
2. スムーズな履歴の読み込み（リストの最後に追加）
3. 高速スクロール（または指で摩擦力が許す限りテープを加速します）
4. 一番上までスクロールします（大きなストーリーを蓄積し、ステータスバーをクリックします）
5. 投稿の動的な開示（増加）とアニメーションはありますか
6. ほぼ完全なパケット損失モードでのテープの動作（開発者->ネットワークリンクコンディショナー->非常に悪いネットワーク）

一般に、すべてのアプリケーションは正常に動作しますが、まだいくつかの問題に気付きました。

たとえば、更新中に指を離さずにリボンをゆっくりと引き上げると、VKontakteのプルトゥリフレッシュの動作を確認できます（左のgifを参照）。



この飛躍も見られますか？



InstagramとFacebookはそのような振る舞いを見せませんでした。



そして、投稿の開示には顕著な違いがあります。 FacebookとInstagramの場合、これはスムーズなアニメーションで行われ、VKontakteはクリックするだけでサイズを更新します。







したがって、私たちのタスクは、スムーズなスクロールを作成し、投稿をダウンロードし、アニメーションで公開することです。



最初のステップは、概念を選択し、赤の正方形にプロトタイプを作成することです（なぜプロトタイプにいつも直感的に赤い色を選択するのか疑問に思います。これは誰の場合ですか？）。

生産性を向上させる私の主なアイデアは、Appleが長年導入してきたすべての機能を放棄し、文字通りiOS 3の開発にロールバックすることでした。

• AutoLayoutの拒否（はい、遅いです、信じられません-コメントで証明できます）
• テーブルセルの高さを自動的に計算することを拒否

その結果、次のコンセプトが選択されました。











もう少し詳しく見てみましょう。



メインスレッドでは、インターフェイスを更新し、ユーザーアクション（スクロールダウンとプルツーリフレッシュ、投稿をクリックして増加）を処理し、データを受信および準備するためのサービスモデルをトリガーします。



API呼び出し 。 ここではすべてが簡単です-NSURLCacheが設定されたNSURLSession。 履歴をロードするときはキャッシュを使用し、プルツーリフレッシュするときはキャッシュを無効にすることが重要です。 まさにこの動作は、VKとFacebookで見張っていました。



モデルの解析と作成 。 特定のリクエストを処理し、エラーをスローし、データを含むトランスポートモデルを返すためのロジックを次に示します。



プレゼンテーションモデルの計算 。 パフォーマンスを最適化するための最も重要なステップ。 ここで、トランスポートモデルはPostModelポストフィックスを使用してエンティティに変換されます。 ViewModelは、表示用に完全に準備されたデータを保存します-AttributedString、計算されたセルの高さ（折りたたみと展開の2つの状態）、文字列としてのフルネーム、日付文字列（DateFormatterから既に変換済み）。



その後のみ、データはメインストリームに戻ります。 このようなロジックをSwiftに実装するのは非常に便利で簡単です。 ViewModel構造を作成します。 構造は、新しいスレッドに転送されるときにコピーされます。



優れたコンセプトが用意できたので、出力メカニズム自体について説明しましょう。



最初に、テープの実装対象（UITableViewまたはUICollectionView）を選択する必要がありました（実装に十分な時間が割り当てられていません）。 明らかに、UITableViewは出力の一覧表示に適していますが、リストを上、下から拡大したり、コンテンツセルを増やしたりすることに問題があるかどうかは非常に心配でした。 したがって、私は単純なものから複雑なものに行くことにしました-つまり UITableViewに問題がなければ、そのままにします。



私が最初に決めたのは、プルトゥリフレッシュを決めることでした。 このパターンを実装するために、UIRefreshControlがあります。 約5〜6年前、UIActivityIndi​​catorを使用して実装を記述し、テーブルのcontentInsetを変更しました。 だから、今はしないでください！ UIRefreshControlには便利なコンパクトなインターフェイスがあり、松葉杖の雲が必要です。 使い方はとても簡単です。







ただし、それを使用すると、VKクライアントの上記の問題がどこから発生するかが明らかになります。 それらはコンポーネント自体に存在するようです。 私はすぐにその理由と解決策を探しました。



インターネットのヒントは言う（ そのようなまたはそのような ）：

• endRefreshingを呼び出すときに、コントロールが更新されているかどうかを確認します（isRefreshing）
• 正確にUITableViewControllerを使用します（この場合、マジックプライベートメソッドが呼び出されるため）

私はこれとそれの両方を試しました-私は肯定的な効果がありませんでした。 私は動揺していましたが、時間を無駄にせずに進むことにしました。 ところで、誰かがこの問題を克服する方法を知っているなら-コメントに書いてください。



次のステップは、下からデータのロードを実装することです。



最初はあまりクールになりませんでした-下から読み込むとひどい遅れがありました（明らかにテーブルからcontentSizeをジャンプしました）：









そしてこれは地獄だ:-)この結果では、あなたは間違いなく勝てない。 しかし、簡単な検索で、私が忘れていた素晴らしい手がかりが得られました。







そして出来上がり：









セルの高さをアニメーション化する方法を決定することは残っています。



頭に浮かんだ最初のアイデアは、visibleCellsに沿って実行し、アニメーションブロックの高さを増やすことでした。 しかし、分析の段階でさえ、この考えは捨てるべきです-問題は、UITableViewDataSourceで指定された高さを同期し、contentSizeで何かをする必要があることです（これはAppleによって強く推奨されています）。



思いついた2番目の考えは正しいことが判明しました-UITableViewには、アニメーションブロックで実行できるinsert / reload / deleteメソッドがあります：







heightForRowAtに新しい高さも追加する必要があることを忘れないでください。







すべてのように見えますが、完全ではありません！ ポストの展開のアニメーションには、微妙な点が1つありました。 IntagramまたはFacebookでテキストを探してください。高さが増すとすぐにスムーズに表示されます。 どうする 行ごとにレンダリングしますか？ NSTextContainerのレベルに達すると、おそらく同様の機会が表示されます。 しかし、一度にすべてのテキストを表示することは（そのような場合には）それほど悪い考えではないように思えました。 clipToBoundsをsuperViewに設定すると、UILabelが配置され、テキストが表示されます。 そして、アプローチはうまくいきました！ ああ、このアニメーションは私に多くのインスピレーションを与え、第二の風が開きました。 結局のところ、ネイティブVKクライアントにはそのようなアニメーションはありません。 だから彼女は勝つチャンスを追加する必要があります:-)



テープの実装の残りの詳細はそれほど興味深いものではありません。 しかし、あなたはコメントでそれらを尋ねることができます。 また、コードのレイアウトに問題はありません。 ここでは-github.com/katleta3000/vkmobilechallengeです。 私はコーマをしておらず、いくつかの場所にマジックナンバーがあります（しかし、これはスピードコンテストなので、何かを犠牲にしなければなりませんでした）。 ところで、そこでコミットにジャンプすることができます（名前は明確です）。



結果はここで見ることができます-www.youtube.com/watch?v=Md8YiJxSW1M&feature=youtu.be （もちろん品質はひどく失われますが、正確に滑らかなスクロールを示すにはgifよりも良いです）

統計、結果、結論

コンテストは常にタイマーで行われました。 20時間半の純粋なコーディング時間が発生しました。 追跡時間は2つの点で役立ちました。覚えているように、抽象的な単位での推定値があったため、最終日の半ばまでには既に良好な追跡統計があり、残りの最終タスクをより正確に計画することができました。 そして、第二に、「一回の集中」のパターンを特定し、証明することができました。 各ディメンションは新しい反復であるため、コードの記述を68回繰り返していることがわかりました。 平均すると、18.5分になります。 しかし、実際には、反復の最初の日には平均25分があり、2日目の終わりにはそれぞれ7分でした:-)あなたは夢中になり、非常に緊張し、疲れ、パフォーマンスが低下します。 そのようなデータは次回に役立ちます。



個人的には、 Hourlyプログラムを使用しました（ダウンロードして試してみてください）-それは必要なタスクを解決するだけです（そして、私も自分で開発しています）：



素敵なボーナス-閉じたパズルごとに、次のような非常に素晴らしい励まし画面が表示されます。









「VK Mobile Challenge」タスクの最後に、次の画面が表示されたことは面白いです。









そしてはい！ そしてそれが起こった:-)結果に進みます。



ぬいぐるみのためにピーチを引っ張らないようにしましょう。 知らなかったピーチは猫の名前-VKの主人公です。 非常にクールなギフト商品：









4位になり、175kルーブルを獲得しました。 （はい、おそらくあなたはすでにHabra-katで写真を焼きました）。 そして、はい、私は確かに満足しています。 私は目標に到達しました:-)そして、これは間違いなく非常に楽しいです。



最後に、 vkontakteに感謝します-結局、競争はクールでよく組織されていました。 そして、すべての読者にチャレンジとハッカソンに参加することをお勧めします-これは、自分自身に挑戦し、世界中のトップ開発者（または少なくともロシア語を話すコミュニティ）と競争するための素晴らしい方法です。