0

Visual Studio 2008 を使って Windows Mobile 6 向けのアプリを開発しています。モバイル デバイス エミュレーター (およびデバイス自体) はエディット コンティニュをサポートしていないようです。つまり、アプリケーションをコンパイルし、エミュレーターにデプロイし、起動して、作業中のポイントに到達する必要があります。 (場合によっては 1 ～ 2 分かかります)、コードをステップ実行して、何が起こっているかを確認します。変数の値をその場で変更することはできますが、コードを更新することはできません。そのためには、実行を停止し、コードを変更して、プロセスを繰り返す必要があります。

それは非常に遅い開発につながります (私は古いタイマーが言うのを聞くことができます.より大きなコードを一度に開発しようとしているので、デバッグは苦痛なスパートでのみ行われますが、間違ったプロパティを呼び出したり、間違ったイベントにアタッチしたりして、作成後に最初からやり直す必要がある場合は、依然として非常にイライラします。・ラインチェンジ。

Windows フォーム アプリケーションを同時に開発し、すべてのフォーム オブジェクトに同じ名前を付けて、2 つの間でバックエンド コードを共有することを検討しました。そうすれば、Winforms アプリでコンパイルし、バグを解決し、エディット アンド コンティニュを実行し、検証が終わったらコードをモバイル アプリケーションにコピーするだけで済みます。より良いアイデアはありますか？

4

2 に答える 2

0

デバイスではなく、エミュレーターにデプロイします。

ただし、アプリケーションを配布する前に、デバイスでテストしてください。

エミュレーターを使用すると、コードをステップ実行したり、メモリ内で実行されている値を編集したり、コードに変更を書き込んだりできます。

コードに加えた変更は、実際のデバイスと同様に、デバッガーを停止して再コンパイルするまで実行されないことに注意してください。ただし、これらの変更は、次にコードを実行するときに適用されます。

ブレークポイントがたくさん。

スレッドがたくさんある場合、ブレークポイントはイライラするでしょう。

于 2013-02-06T14:21:02.267 に答える
0

まさにこれが、私が多くのインターフェイス、適切なビュー/モデルの分離、およびソフトウェア サービスへの依存を使用する理由です。私の開発の多くは、デスクトップ単体テスト、またはアプリ全体をデプロイしてスピンアップすることなくデバイス上で実行される小さな「シム」アプリで行われます。

基本的に、私のプロジェクトのほとんどにはデスクトップ プロジェクトとデバイス プロジェクトの両方があり、ほとんどの機能的な作業はデスクトップで行います。UIなどを接続する必要がある場合にのみ、デバイスに移動します。デバイス UI をモックアップするためにデスクトップ UI を作成することはありません (または非常にめったにありません)。作成している場合は、UI がビジネス ロジックと結合しすぎていることを示しています。

于 2013-02-06T01:01:23.210 に答える