こんにちは 私たちは、ninjamock.comプロジェクトのninjam開発者のチームです。 Ninjamock.comは、もう1つのオンラインスケッチおよびプロトタイプデザイナーです。 プロジェクトは完全にjavascriptとHTML5で記述され、サーバー部分はASP.NET MVCにあります。



このプロジェクトの作業中、私たちは膨大な数のレーキを踏んで、共有したい大規模なJavaScriptアプリケーションの開発において貴重な経験を得ました。 この記事では、1つのindex.htmlファイルのプロトタイプが、250を超えるクラスと60,000行のコード（サードパーティライブラリを含まない）を含む本格的なプロジェクトにどのように成長したかを説明します。 また、一般的には、アーキテクチャを説明し、クライアントでのレンダリングの実装を詳細に説明します。





UPD： ツイッターまたはfbページの更新をフォローする

開始する

私たちは全員1つの大企業で仕事をしています（まだ仕事をしています）。どういうわけか、ある瞬間にうんざりしていて、自分たちのために働くプロジェクトを開始するために世界をとらえることにしました。 それで、ある秋の日、私たちはバーに集まって「お茶」のマグを飲み、それをどうするかを話し合った。 N番目の円の後のどこかで、私たちの素晴らしい計画は準備ができていました。

• 最高のスケッチデザイナーを書く
• ???
• 利益を上げる

後に、私たちは独創的ではなく、私たちの前にこの計画、つまりドワーフのビジネス計画を思いつきました。



スケッチデザイナとは、スケッチ、ワイヤフレーム、またはアプリケーションのモックアップを描画できるだけでなく、クリック可能なシンプルなプロトタイプを作成できるアプリケーションを意味します。 主な対象読者は、モバイルアプリケーションの開発に携わるプログラマ、デザイナー、ビジネスアナリスト、および小規模企業であり、アプリケーションの設計をすばやく作成したり、プロトタイプをテストしたりする必要があります。



主な競争相手として、私たちは有名なbalsamiq.comを検討しました。balsamiq.comの財務諸表により、私たちはこの分野で働き始めました。 しかし、同じことを考えたのは私たちだけではなかったようで、この年にいくつかの同様のプロジェクトが登場しました。



フラッシュで記述されたbalsamiqとは異なり、すべてのプラットフォームで作業できるように、すべてを「正しく」実行し、HTML5で記述することにしました（それは当時流行の流行だったためです）。



balsamiqとのもう1つの違いは、特定のプラットフォーム（iPhone、iPad、Windows Phoneなど）に焦点を合わせていることです。 つまり、balsamicは何かを描画するための汎用プラットフォームであるため、特定のプラットフォームに固有のセマンティクスはありません。 なぜこのようなセマンティクスが必要なのですか？ たとえば、描かれたデザインのコードを生成します。 私たちにとって、すべてのコントロールは多かれ少なかれ本物のように振舞います。

現在のプロジェクトアーキテクチャ

サーバー側は非常にシンプルで、ASP.NET MVCに実装されています。 おそらく話すことはあまりありません。 私たちが持っているコードのほとんどはクライアント上にあり、JavaScriptで書かれています。 プロジェクトを開始したとき、CoffeeScriptに目を向けましたが、そのときのインフラストラクチャはかなり未加工であると考えていたため、すべてを純粋なJavaScriptで記述することにしました。



自分自身を尊重するすべてのJavaScript開発者と同様に、複数の自転車を発明し、フレームワークをいくつか作成しました。たとえば、独自のクラス作成方法があります。次の記事のいずれかで説明する興味深い点があります。 現在、TypeScriptの出現により、WebStormにサポートが表示され次第、TypeScriptに切り替える予定です。



クライアントには、すべてのJavaScriptを使用する1つのメインページがあります。 サードパーティのフレームワークから、jQueryとknockout.jsを使用します。 ただし、アーキテクチャ的には、サードパーティのフレームワークに厳密に結び付けないことにしました。そのため、使用が許可されるプラットフォーム固有のクラスはわずかです。



顧客コードには以下が含まれます：

• 設計要素のオブジェクトモデル、つまりコントロールの基本クラス。
• レンダリングの中核。 これには、マウスおよびキーボードのイベント処理クラスが含まれます。 これらのクラスは、座標による要素の検索と移動、要素の描画順序の作成、各要素の描画自体の呼び出しを行います。
• 特定のプラットフォームの設計要素（コントロール）（現時点では、iPhoneのみ）。 各コントロールは、指定された座標での自身の描画方法を決定します。 現在のコントロールの場合、レンダリングはコントロール自体のコードに「ハードコーディング」されます。たとえば、「ボタン」のコードでは、長方形を描画し、色で塗り、上にテキストを描画し、中央に配置します。 ただし、新しいコントロール（まだリリースされていない）を描画するために、別の方法で行うことにしました-独自のデザイナーを使用して完全なコントロールを描画します。 部分的にこの機能は既に使用可能になっているため、1つ以上の要素を選択し、右クリックして[資産]-> [資産に変換]を選択することができます。 その後、左側のパネルに新しい要素が表示されます。 また、要素をダブルクリックすると、そのテンプレートを編集できます。
• ページおよびダイアログのプレゼンテーションモデル（ViewModel）。 これらは、knockout.jsテンプレートが関連付けられているプラ​​ットフォームに依存しないクラスです。
• アプリケーションを実行しているプラ​​ットフォームにカーネルをバインドするクラス。 ここに、マウスイベントとキーボードイベントをサブスクライブするためのコードがあります。 このコードは、後の処理のためにイベントをカーネルにリダイレクトします。 たとえば、コンピューター、iPad、またはiPhoneでは、イベントのサブスクライブの方法は異なります。 MacおよびPCにはキーボードショートカットなどがあります。
• 拡張機能。 コードを設計するとき、私たちはopenness / closenessの原則に依存していました。したがって、拡張機能は原則として不要な機能を実装します：たとえば、要素のスナップ、要素がドロップされたときにコンテナーを強調表示、localStorageにプロジェクトを自動保存します。 合計17の拡張機能があります。

しかし、それはすべて簡単に始まりました...

最初のプロトタイプ

最初のプロトタイプは数日で書かれました。 その中で、プロトタイプにあるはずであるように、すべてが非常に簡単でした。 コントロールはHTML要素でした。 たとえば、長方形は単なるdivであり、電話のキーパッドはimgであり、グラデーションが必要なより複雑な要素（タブバーやツールバーなど）はキャンバスです。 すべての要素には絶対座標があり、要素の相対的な位置はcss-property z-indexを介して設定されました。 要素の移動は、jquery.draggableを介して実装されました。



すべてのコントロールはdiv要素に配置されました。これは仮想ページでした。つまり、作業領域よりも広くて高く（スクロールを確実にするため）、スケーリング時にサイズがそれに応じて変化しました。

このアプローチの主な利点は、実装の容易さと優れたスクロール要素です。これは、ブラウザーが私たちに提供するものであり、その他多くの利点もあります。



このアーキテクチャは数か月間続きました。 しかし、私たちのプロジェクトは成長と発展を遂げ、新しい機能が追加されるにつれて、私たちはそれが私たちに合わないことに気付きました。



最初の障害は平凡なズームでしたが、まだ適切に実装できませんでした。 実際には、2つのオプションがありました。

• CSS CSSプロパティ-要素を減らす必要がある場合に最適です。 増加には問題があります。すべての要素はベクトル要素であり、それらのほとんどはキャンバスに描かれています。 cssを介してキャンバスを増やすと、そのコンテンツはビットマップにスケーリングされますが、ベクトルズームが必要でした。 これがどのように機能しないかの例は、 jsfiddle.net / MzGpe / 3にあります。
• 「手動」ズーム。すべての要素を調べて位置とサイズを変更し、すべてのキャンバスのコンテンツ全体を新しいスケールで再描画する必要がある場合。 しかし、スムーズなレンダリングを実現することはできませんでした。すべての要素がスケーリングの瞬間にひどく（連続的に）ジャンプしました。

驚くべきことに、競合するHTMLアプリケーション（fluidui.com、gomockingbird.com、moqups.com）はいずれもスケールアップしていません。

第二のプロトタイプ

私たちの解決策は、すべてのHTML要素を捨てて、すべてを描画する1つの大きなキャンバスに置き換えることでした。 キャンバスのサイズは、仮想ページのサイズと同じでした。 したがって、スクロールは以前と同じように機能しましたが、今ではすべてをスムーズにスケーリングできるようになりました。



このアプローチのもう1つの利点は、キャンバスから画像を簡単に生成できることです。これにより、canvas.toDataUrlメソッドを使用してページのサムネイルを作成できます。 さらに、これはすべてクライアントで実行され、サーバーをロードしません。 さらに、画像の個々のピクセルを処理する機会があります（将来、興味深いグラフィックツールが追加されます）。



15xスケーリングを使用したアプリケーションのワークスペース：







しかし、すべてがそれほど単純ではないことが判明しました。 マウスを使用して要素を移動すると（これが最も頻繁に使用されるアクションです）、すべてのコントロールを含むキャンバスが全体として再描画され、アプリケーションのパフォーマンスに大きく影響しました。 それは非常に単純に決定されました-最初のキャンバスの上に別のキャンバスを追加しました。 そこで、2つのレイヤーを取得しました（最初は3つのレイヤーがありましたが、それは別の話です:)）。 最初のレイヤーには、ほとんど静止画が含まれていましたが、これは比較的めったに再描画されませんでしたが、2番目のキャンバスには、一時オブジェクトや、スナップ線やホバーのハイライト要素などのさまざまな効果が描かれました。 その結果、ほぼ完全に満足しました。







しかし、このアプローチの不完全さを示す問題が再びありました。 スケーリングすると、画像のサイズ、およびそれに応じてキャンバスのサイズが増加しました。 デフォルトでは、デザインページのサイズは1024x768です。 4倍に増加すると、キャンバスのサイズは4096x3072になり、すべてのマシンが（許容可能な速度で）レンダリングに対応できるわけではありません。 さらに、この増加を伴ういくつかのマシンでは、奇妙なアーティファクトがストライプとカラフルなドットの形で現れ始めました。 しかし、4倍の増加は限界からはほど遠い。



その結果、現在使用しているソリューションに到達しました。 これらはすべて同じ2つのキャンバスですが、そのサイズはページデザインのサイズではなく、画面上のページの表示部分のサイズと等しくなりました。 このため、標準のスクロールを放棄し、レンダリング時のスクロールの位置を考慮する必要がありました。



このアプローチでは、1つの小さなマイナスを除き、すべてが正常に機能します。スクロール速度は、以前のオプションと比べてわずかに低下しました。



記事の冒頭のスクリーンショットで、プロジェクトの外観を確認できます。 ここでライブで見ることができます： ninjamock.com 。

エピローグ

現在、プラットフォームでサポートされているコントロールの数を増やすために積極的に取り組んでおり（すぐにiPad、Windows Phone、Surface、デスクトップアプリケーションもサポートされる予定です） 、同時にビジネスプランの2番目のポイントを検討しています。 私たちは、プロジェクトに関するフィードバックや質問に喜んでお答えします。



ninjamockプロジェクトチームは、 pastorgluk 、Denis、およびHeadwithoutbrainsです。