2

アプリをAndroidからWindowsPhone7に移植し、同期呼び出しを使用してioなどをファイルすることができました（スレッドを使用しているため、作業が簡単になります）。

ただし、現在はWindows 8ストアアプリに移植しており、APIではXxxAsync（）メソッドが横行しています。

盲目的に非同期APIを使用して、最高のものを期待する必要がありますか？

私はさまざまな疑問を持っています...例えば：

ユーザーが[保存]ボタンをタップしてデータモデルを保存するとします。すべての保存は非同期で行われます。これは、ユーザーがデータモデルの保存中にデータモデルの変更を中止できることを意味します。途中で変更すると、データが台無しになり、ファイルが破損しませんか？

これにより、開発者はどのように簡単になりますか？

さまざまな非同期記事（このような）を読んだことがありますが、何かが足りないように感じます...

あなたの洞察に感謝します。

4

6 に答える 6

1

非同期メソッドを使用する理由とタイミングを理解する必要があります。盲目的に使用しないでください。もちろん、これはほとんどすべてのプログラミング手法に当てはまりますが、非同期の場合は特に重要です。何が起こっているのかわからない場合、将来的に混乱する可能性があるためです。

あなたが言及する非同期の問題は、非同期/待機と手動スレッドソリューションの使用で違いがないことを理解することが重要です。async / await（または手動で構築されたスレッド）を使用しない場合、UIが遅く感じたり、イライラするロックアップが発生したりする可能性があります。それを使用する場合は、入力コントロールを無効にしたり、保存されているデータをキャッシュしたり、何を持っているかによって、UIがロックされないという事実を補う必要があります。

最新のAPIに散在する非同期メソッドは、非同期コードやマルチスレッドコードについての考え方を一般的に変えるべきではなく、実際のコードにこれらのアイデアを適用するのがいかに簡単かだけです。

于 2012-11-21T09:16:49.240 に答える
1

そうです、データを保護する必要がありますが、これは個別のスレッドを使用する場合と同じです。非同期パターンを使用すると、スレッドを明示的に使用しなくてもレスポンシブアプリケーションを作成できますが、共有リソースへのアクセスの問題は解決されません。私はchannel9ビデオの1つからの引用が好きです：応答性には責任が伴います。

于 2012-11-21T09:19:38.497 に答える
1

UIでの非同期の考え方は、すべてのコードが1つのスレッド（UIスレッド）で実行されるというものです。ユーザーが[保存]ボタンをクリックすると、ハンドラーが実行されます。この時点で、UIはコードの実行でビジー状態であるため、UIはインタラクティブではありません。サーバーに送信するデータのスナップショットを準備したら、非同期保存を起動し、（技術的には）ハンドラーを終了します。制御はUIに戻り、UIは再び応答するようになります。

この時点で、ユーザーはデータモデルを更新できますが、OSはデータモデルを確認していません。データの個別のバッファー（[保存]ボタンハンドラーで作成したスナップショット）がサーバーに送信されることを確認するだけです。これが発生すると、非同期コールバックが実行されます。これもUIスレッドで実行されます。使用しているバージョンによっては、BeginInvokeを使用して、その呼び出しをUIスレッドに手動で転送する必要がある場合があります。

これは、ブラウザ内のJavaScriptで使用されているものとまったく同じモデルです。

すべての同期の問題を完全に解決するわけではありません。たとえば、アップロード中に[保存]ボタンを無効にしない限り、サーバーが最初の保存をすでに受信しているときに、ユーザーはもう一度[保存]をクリックできます。ただし、これはサーバーが心配する問題にすぎず、2回の同時保存試行に対処できる方が適切です。

考えられる問題の1つは、以前のバージョンのアプリケーションにあります。いたるところにスレッドを使用している場合、ロックまたはスレッドセーフなデータ構造を適切に使用していましたか？あなたが説明する問題は、フリースレッドのアプリケーションに間違いなく存在します！

于 2012-11-21T09:31:40.427 に答える
1

盲目的に非同期APIを使用して、最高のものを期待する必要がありますか？

Windows Phoneプラットフォームでは、APIを使用する必要がasyncありますが、「盲目的に」使用しないことをお勧めします。最初にそれらについて学びます。私のブログに役立つかもしれないasyncイントロがあります。

ユーザーが[保存]ボタンをタップしてデータモデルを保存するとします。すべての保存は非同期で行われます。これは、ユーザーがデータモデルの保存中にデータモデルの変更を中止できることを意味します。途中で変更すると、データが台無しになり、ファイルが破損しませんか？

はい。一般的な方法の1つは、リクエストが未処理のときにデータをコピーしたり、コントロールを無効にしたりすることです。たとえば、このコードは、保存が最初にリクエストされたときにデータをコピーし、保存が完了するまで保存ボタンを無効にします。

public async Task SaveAsync(MyData data) { ... }

// Logically, this is an asynchronous ICommand.Execute implementation.
public async void SaveCommand()
{
  saveInProgress = true;
  dirty = false;
  MyData data = CopyData();
  await SaveAsync(data);
  saveInProgress = false;
}

// Logically, this is an ICommand.CanExecute implementation.
public bool CanSave { get { return !saveInProgress && dirty; } }
private bool saveInProgress, dirty;

スレッドを使用して保存する場合も、まったく同じ問題に直面します。

これにより、開発者はどのように簡単になりますか？

asyncコードは、スレッドを使用するコードよりもはるかに保守しやすくなっています。

于 2012-11-21T13:14:30.720 に答える
1

コードが非同期で実行されるからといって、保存中にユーザーがデータを変更し続けることを許可する必要があるわけではないことを覚えておいてください。ユーザーがデータをそれ以上変更できないようにする方法を決定できるため、ユーザーエクスペリエンスが向上します。

同期して保存し、時間がかかる場合（たとえば、30秒）、ユーザーは30秒間、画面がフリーズして応答しなくなります。多くのユーザーは、その時点でアプリがクラッシュしたと想定します。ただし、これが非同期モデルである間は、何が起こっているかをユーザーに通知するメッセージ（およびステータスバー）を表示するだけで済みます。さらに、アプリの他の機能へのアクセスを許可するオプションがあります。

于 2013-05-29T12:02:03.860 に答える
0

盲目的に非同期APIを使用して、最高のものを期待する必要がありますか？

いいえ、確かにありません。非同期のものは、ユーザーに柔軟なUXをもたらすのに非常に優れていますが、あなたが義務付けているように、非同期のものの実行の瞬間にプログラムの機能資産の管理が複雑になります。

モバイル（およびそれだけではない）の基本的な考え方は、ユーザーにprogress情報を提供すること、および/またはdisableUIhideコントロール（機能アクセスポイント）からその特定の瞬間に何らかの方法でユーザーに害を及ぼす可能性のある情報を提供することです。

于 2012-11-21T09:18:53.627 に答える