問題タブ [gwt-rpc]

彼の、

GWT でのモバイル開発の経験を共有していただけますか?

クリック可能なパネル/ボタンが多数あり、ブラウザの動作が非常に遅くなる、非常にインタラクティブな Web サイトを開発しています。次のページに移動するのに 1 分以上かかることもあります。

これはアーキテクチャの弱点である可能性があります。すべての要素は、おそらくサブビューを含むビューです。そして、すべてのビューは、サーバーからの DTO によって支えられています。このような深いオブジェクト グラフは多すぎるかもしれませんが、ビュー レンダリングの効率を最適化することに集中しようとしています。もっと。

• Google I/O Conference 2010 のビデオが示すように、UiBinder でウィジェットを作成してみました。しかし、それは速度の改善をあまりもたらしませんでした。HTMLTable、HTMLPanel、VerticalPanel など、多くのパネルを使用します。これは、他のビューをホストするすべてのビューが何らかの方法でそれらをアタッチする必要があるためです。それらを新しいCellListに置き換えると、何か良いことがあるでしょうか、それとも単純なHorizo​​ntalPanelはすでに十分に軽量ですか?

• ページ上のクリック可能なウィジェットが失われています。また、一般的にはウィジェットを削減することをお勧めしますが、onMouseDown イベントを処理するにはすべてのウィジェットが必要です。CPU 負荷が最も低いクリック可能なコンポーネントは何でしょうか? MouseDown ハンドラーを備えた VerticalPanel、ボタンなど?

• ユーザーがボタンをクリックすると、PRC リクエストが発行されます。PRC 呼び出しをしばらく停止すると、ボタンをクリックした直後に RPC 呼び出しを行う場合よりも、クリックされたボタンのスタイル レンダリングがはるかに高速になることに気付きました。スタイルのレンダリングを妨げない RPC 呼び出しを起動する方法を指示するパターンはありますか。

• プロファイリング レポート (Firebug および Speedtracer) は、 setInnerHTML() および add() 呼び出しが負荷の大部分を占めていることを示しています。ビューが親にアタッチされているときに add() を呼び出す必要があり、なぜ setInnerHTML に時間がかかるのかわかりません (ビデオ プレゼンテーションによると、ビューは非常に高速であるはずです)。add() 呼び出しを最適化する合理的な方法はありますか? 私は本当にそれを行う方法を考えることができません。

すべての提案に感謝します。ありがとう。

Wave チームが GWT Web クライアントを構築するために採用したアーキテクチャ アプローチを知っている方がいらっしゃるのではないでしょうか? モバイル向けに設計された 1 つの GWT アプリのパフォーマンスを最適化しようとしているので、その迅速な資格情報を賞賛せずにはいられません :)

• Wave は GWT-RPC を使用してサーバーから定期的な更新を取得していませんか? Firefox はネットワーク上で行われる JSON 通信を追跡しますが、RPC のような通信は追跡しません。

• たとえば、新しいウェーブレットが送信されたとき、それらはどのように処理されますか。すべての Wave DTO にビュー オブジェクトがありますか、それとも他のパターンを使用していますか?

• 新しい Wave が到着したなどの応答後に、GUI はどのように更新されますか。ウェーブレットを含む領域全体を再レンダリングしますか、それとも特定の要素だけが確実に処理されるようにするためのスマートな手法を使用しますか?

ありがとう

RPC (Google DataStore の JDO) 経由でサーバーと対話するアプリケーションを実行しようとしています。そこで、サーバー側で永続的な POJO を定義して、PersistenceManager を介してデータストアに配置しました (gwt rpc tuts に示されているように)。すべて正常に動作します。しかし、POJO はサーバー側でしか定義されていないため、クライアント側でコールバック POJO を受け取ることができません。クライアントがその種のオブジェクトを知っていることをどのように認識できますか?? (私の下手な英語でごめんなさい) ラース

プロジェクトはGWTとJavaAppEngineで実行され、標準のGWTRPCメカニズムを使用します。App Engineは、RPC呼び出しごとにログトレースを追加しますが、呼び出されたメソッドではなく、サーブレットURLをログに記録するだけです。ログURLにメソッド名を追加します。

RpcRequestBuilderクラスを拡張し、doCreateをオーバーライドして、メソッド名をURLに追加しようとしましたが、問題は、この時点でメソッド名が不明であるということです。これは、後でdoSetRequestDataで（データ文字列の一部として）認識されます。

Itzikに感謝します

皆さん、

GWT Web クライアントをサポートする GWT-RPC サービス (Appengine 上) があります。すべては順調です。

さて、このために Android クライアントを開発している場合、このクライアントにサービスを提供するために、サーブレットを簡素化する必要がありますか? つまり、シリアル化された Java オブジェクトを (GWT のように) 前後に送信する代わりに、Android のパッケージ化された HttpClient を使用して XML を新しいサーブレット (AppEngine 内で GWT-RPC サービスを再利用できる可能性があります) に送信する必要があります。

私はここで順調ですか？Android は GWT-RPC サービス バックエンドを直接許可しますか?

コードの観点から簡潔にしようとしています..

テストとログインの 2 つのメソッドを持つ GWT-RPC サービスがあります。

この順序でメソッドを呼び出し、毎回セッション情報を出力します。

ログインする（）

テスト（）

ここでわかるように、両方の呼び出しに異なるセッション ID があります。

これらの呼び出しごとに onSuccess のクライアント側で、JSESSIONID Cookie の値を出力します。

更新を押すと、次のようになります（これは私が最初に期待したものです）：

ログインする（）

テスト（）

更新の前に、各呼び出しが新しいセッション ID を取得する理由を誰か説明できますか?

GWT-RPC を使用して GWT を実行しています。GWT-RPC は実際には JSON であり、クライアント ブラウザーで Eval() を取得しています。

ブラウザーは Eval() されたものをキャッシュしないので、毎回アプリ全体を再ダウンロードすることになると思います。

ブラウザのキャッシュに取り込まれるライブラリ ファイルなどはありますか? GWT は Eval() されたものをキャッシュするトリッキーな方法を見つけましたか?

ありがとう。ショーン。

gwt-rpc 呼び出しを新しい GWT2.1 RequestFactory cal に移行する必要があるかどうかを判断しようとしています。

Google のドキュメントでは、RequestFactory が「データ指向サービス」のためのより優れたクライアント サーバー通信方法であると漠然と述べています。

ドキュメントから抽出できるのは、通信を簡素化する新しい Proxy クラスがあることです (実際のエンティティをやり取りするのではなく、プロキシのみをやり取りするため、軽量で管理が容易になります)。

それが要点ですか、それとも全体像で何か他のものを見逃していますか?

Firefox で正常に動作するアプリを持っていますが、IE8 でテストしたところ、奇妙なエラーが発生しました。'Stack overflow at line: 0'

RPC 呼び出しから返される大きな/複雑なオブジェクトに関連している可能性があるという GWT ディスカッション グループからの提案の後、問題を、大きくて複雑なオブジェクトを返す RPC サーバー呼び出しの 1 つに絞り込むことができました。

大きなオブジェクトが大きすぎる、または複雑すぎることがエラーの原因である場合、どうすればこれを知ることができますか? 「大きすぎる」というしきい値はどこにありますか?

GWT の議論からのさらなるコメントは、Collections オブジェクトが問題である可能性が高いことを示していますが、これは別の GWT 開発者の経験によるものです。これは、GWT のドキュメントまたはチームによってどこかに文書化されていますか?

しかし、それでも問題は残ります - それが「十分に小さい」ことをどのように知ることができますか?

ユーザーがテキストエリアに書き込むテキストを使用して、サーバー側でファイルを作成する必要がある Web ページを開発しようとしています。

この目的のためにどのテクノロジーを使用することをお勧めしますか? PHP または GWT+RCP? より開発しやすく、より安全で高速なものを使用したいと考えています。

ありがとう