3

バックグラウンド

モバイルWebサイトとして提供され、 Phonegapをネイティブに使用する非常に大きなHTML/JSモバイルWebアプリを作成する必要があります。私は現在、アプリ自体を整理するための最良の方法を決定するために取り組んでいます。

基本的な計画は、それぞれが異なる関心のある主題に焦点を当てる多くのモジュールを持つことです。これらのモジュールのいくつかは非常に基本的であり（つまり、アナウンス/ニュース）、いくつかは非常に複雑です（つまり、スポーツ：チームプレーヤー、スケジュール、ビデオなど）。ほとんどのページに適用されるサイドドロワーナビゲーションがあるため、ユーザーは別のモジュールにすばやく移動できます。モジュール内でディープリンクする機能が必要です。これらのモジュールは、さまざまな開発者やベンダーによって作成されます。

シングルページアプリ

私が目にするモバイルソリューションのほとんどはシングルページに関係していますが、この場合、メモリを大量に使用する可能性があるため、これは悪い考えのように思えます。また、モジュール間のハッシュナビゲーションとモジュール内のセクション間のハッシュナビゲーションを調整することは難しいようです。モジュールの開発は、アプリフレームワークを念頭に置いて行う必要があり、ベンダーや開発者が行う方法を制限します。一方、物事はそれほど頻繁にロードされておらず、すべてが互いに簡単に通信できます。

複数ページのアプリ

複数のページを使用すると、各モジュールは、ベンダーが使い慣れているテクノロジーで簡単に作成できるように見えます（そして、迅速かつ安価に作成できます）。これにより、メモリの使用量が削減されますが、モジュールが通信する機能も削除されます（現時点では、私にはわからない機能が必要です）。すべてのモジュールがさまざまなイベント（ログエラー、ナビゲーションなど）の一般的な処理に使用するJavaScriptライブラリを作成していることがわかりました。モジュール間の各アプリナビゲーションは、DOMをリセットする新しいページ呼び出しになります。必要に応じて、各モジュールで1ページのデザインを使用できます。

お願い助けて

それで、このようなものがどのように設計されるべきかについての一般的または新しい知識はありますか？仕事を始めたいと思っていますが、すでに存在している可能性のあるものを書き直したくありません。私の推論に明白な欠陥がありますか？洞察力のある人から聞いてみたいです。

4

3 に答える 3

0

最初のステップは、これらの要件を明確にすることです。

あなた自身またはあなた自身の会社のためにこれをしているなら、これらのモジュールがどのように（協力して）動作するかを突き止めてください。

あなたがあなたの雇用主のためにこれをしているなら、そこにいる誰かが彼らが見たいものの手がかりを持っているべきです、さもなければ、あなたはそれをどのように構築するつもりですか？

複数のページをサポートし、通信なしでモジュールを開いたり閉じたりするソリューションでは、システムコールやサービスを介して通信する場合としない場合がある複数のウィジェットを同時に維持するフレームワークとは異なるものが必要になります。

それを回避する方法はありません。モジュールのサービス/サンドボックスなどを構築するには、それぞれをページ変更のように扱う（または文字通りのページ変更にする）よりも多くの作業が必要になります。

プログラムに何をさせたいかがわかったら、他の人に使ってもらいたいAPIのアイデアを作り始めます。
UIコンポーネントを構築するためのAPIを提供するのでしょうか、それとも彼ら自身の気まぐれに任せるのでしょうか。

個人的には、各モジュールの変更がiFrameを置き換えるだけで、エンドユーザーがそこでやりたいことを何でもできるという状況は避けたいと思います。
同様に、モジュール作成者がサンドボックス化されていない環境で好きなように実行できるようにする状況は避けたいと思います...エンドユーザー（または英国の裁判所ではあなた）にとってはうまくいきません。しかし、それはまだ問題ではありません。

最初の懸念は、プラットフォームが何をするかです。

次に、バックエンド通信がどのようになるか、モジュールクリエーターに提供するインターフェース、およびエンドからそれらのエンドにデータを取得する方法（httpベースのAPI、REST、または他に何でも......しかし、まだ持っていない場合は、うまくいきます）。

次に、プラットフォームで何が期待されるかがわかっていて、あらゆる種類のタスクを適切に処理できるバックエンドがある場合は、コンテンツクリエーターに提供するサービスを把握し、ウィジェットを作成してアップロードします。 /サービスやサンドボックスなどからデータをダウンロードします。

于 2012-12-13T23:46:43.363 に答える
0

私は数年前に対処するために同様のアーキテクチャ上の問題を抱えていました。モバイルではありませんでしたが、完全にWebベースでもありませんでした。ターゲットアプリケーションは、Webサイトとデスクトップアプリの組み合わせであり、将来的にモバイルになる可能性があります。

興味深い部分は、さまざまな状況で使用できるフレームワークを作成するための2つの以前の試みがあったことです。問題、および両方の試みが失敗した理由は、開発者がそれをUX問題スペースと見なしたことでした。彼らはいくつかの異なる技術を使用してそれにアプローチしましたが、彼らは前もって仮定を立て、ズボンの座席でプロジェクトを飛ばしたため、数ヶ月後には夢中になりました。

私のアプローチは、すべてのUIの議論を完全に避け、あらゆる観点からアプローチできるバックエンドアーキテクチャに焦点を当てることでした。この目的のために、私はデータが双方向に送られるWebサービスを作成し、最終的には数学モデルを提供していました。このサービスは、Flash、Unity、Google Earthプラグイン、そして最後に、古き良きHTMLを提供する無関係のWebアーキテクチャなど、さまざまなテクノロジーを使用してさまざまなソースからアクセスされています。

私からのアドバイスは、バックエンドを正しくするために、フロントエンドのマッピングに集中しないことです。データ構造を整えたら、外部に構築することができます。メモリ管理、モノリシックアプリかどうかなど、いくつかの問題、つまり1ページと多数の問題はほぼ解決します。優れたインターフェースを多数備えた優れたAPIの作成に取り組むことで、「多くのシェフ」の穴に陥ることはありません。一方、分散した開発者の束に十分なロープを与えると、すべての結び目がどこにあるかを見つけることはできません！

最終的にネイティブAPIをSenchaTouch、jQuery Mobile、PhonegapなどのHTML5ベースのテクノロジーに移行するかどうかの決定は、今後数か月から数年にわたって行われる福音主義のブラックホールです。ネイティブアプリの方が流動的でスピーディーな場合もありますが、リソースへの投資を検討する必要があります。一方、JavaScript開発者は隅々まで潜んでおり、不足しているわけではありません。

于 2012-12-13T22:45:46.257 に答える
0

正直なところ、大量で非常に複雑なアプリの構築を検討している場合は、ネイティブ開発を検討するか、少なくともアプリケーションをネイティブ コードに「コンパイル」する Appcelerator のようなものを使用する必要があります。よりよい性能。限られたシステム リソースを適切に管理できるかどうかわからない独自の JavaScript コンポーネントを任意の数の開発者に構築させようとしている場合、すぐにアプリケーションのパフォーマンスの問題に直面することになります。

一方、概念実証のみを目的としており、十分なレベルの複雑さが得られたときにアプリケーション アーキテクチャを大幅にリファクタリングしなければならない可能性を気にしない場合は、単純に Web アプリ アプローチを使用することをお勧めします。 .

実際、フロントエンド アーキテクチャと同等またはそれ以上に、バックエンド サービス アーキテクチャも考慮する必要があります。これは、他の開発者からの提供物を統合しようとする際に、実際に問題に遭遇する場所です。

于 2012-12-13T22:29:13.500 に答える