15

この質問に対する可能な答えをグーグルとSOで検索しましたが、その場所に散らばっている小さな情報しか見つけることができず、そのほとんどは個人的な意見のようです.

この質問が主観的であると考えられることは承知していますが、私は個人的な意見を求めているのではなく、理由のある事実 (過去の経験など) や、ベスト プラクティスを説明しているブログ/ウィキへの単一のリンク (これは私が正直に言いたいこと）。私が探していないのは、これを機能させる方法です。自己更新デスクトップアプリケーションを作成する方法を知っています。

自己更新デスクトップ アプリケーションを作成するためのベスト プラクティスについて知りたいです。私が特に興味を持っているベスト プラクティスの種類は次のとおりです。

  • クライアント ソフトウェアが古くなっているが、他のバージョンのソフトウェアまたはデータベース自体と通信しようとしても壊れない場合、更新を強制しますか? もしそうなら、この重大な変更をどのように意味しますか?
  • どのくらいの頻度で更新を確認する必要がありますか? 毎週/毎日/毎時、正確にはその理由は?
  • UI の観点から、更新をユーザーに表示するか、バックグラウンドで実行する必要がありますか?
  • メジャー アップデートでない場合、利用可能なアップデートがあることをユーザーに通知する必要がありますか? (たとえば、実際には 1 人のユーザーのみが必要とするアプリケーションのリモート部分にある 1 つのボタンを修正する)
  • アプリケーションにパッチを当てる必要がありますか、それともアプリケーション全体を最初から Macintosh スタイルから再ダウンロードしますか?
  • ユーザーが中央の場所から更新できるようにするか、指定したアプリケーションを介した更新のみを許可する必要がありますか? (クローズド ビジネス アプリケーションの場合)。

確かに、このことについていくつかの書かれた規則/提案がありますか? 多くのアプリケーションで最も厄介なことの 1 つは更新です。これは、「時代遅れ」と「ユーザーが直面している」ことの間の適切なバランスを見つけるのが難しいためです。

これが単一のクライアント用に .net C# で記述され、更新サーバーへの常時接続が可能なマシンで実行されていると考えるのに役立つ場合、これらのマシンはすべてアプリケーションを介して相互に通信し、すべてが中央データベース サーバーとも通信します。 .

4

5 に答える 5

7

多くのソフトウェアが見落としているベスト プラクティスの 1 つは、ユーザーがアプリケーションを起動した直後ではなく、アプリケーションを閉じているときに更新を依頼することです。

それを行わないアプリがどれほど多いかは信じられないほどです (たとえば、Firefox)。アプリを実行したばかりで、すぐに使用したいのですが、代わりに、更新するかどうかを確認するメッセージが表示されます。これにはもちろん 5 分かかり、アプリを再起動する必要があります。

これはナンセンスです。最後に更新を行うだけです。

于 2010-11-25T08:54:13.883 に答える
6

一般的な答えを出すのは難しいです。それは状況によって異なります。更新の重要度、アプリの種類、ユーザーの好み、ユーザー数、ネットワーク幅などです。いくつかのオプション/トレードオフを次に示します。

  • クライアント ソフトウェアが古くなっているが、他のバージョンのソフトウェアまたはデータベース自体と通信しようとしても壊れない場合、更新を強制しますか? もしそうなら、この重大な変更をどのように意味しますか?

    開発者としてのあなたの最大の関心は、そこにあるすべてのアプリをできるだけ最新のものにすることです. これにより、メンテナンスの手間が軽減されます。したがって、ユーザーが気にしない場合は、更新する必要があります。

  • どのくらいの頻度で更新を確認する必要がありますか? 毎週/毎日/毎時、正確にはその理由は?

    更新がユーザーに対して透過的であり、アプリをすぐに再起動する必要がない場合は、通信帯域幅が許す限り頻繁に更新を行うことをお勧めします (更新チェック - 頻繁ではあるが小さい - とダウンロードの両方を考慮して) -まれだが大きい）

  • UI の観点から、更新をユーザーに表示するか、バックグラウンドで実行する必要がありますか?

    ユーザーの好みだけでなく、更新の種類にも依存します: バグ修正と機能/UI の変更 (ユーザーは、以前の警告なしにルック アンド フィールが変更されたことに困惑します)

  • メジャー アップデートでない場合、利用可能なアップデートがあることをユーザーに通知する必要がありますか? (たとえば、実際には 1 人のユーザーのみが必要とするアプリケーションのリモート部分にある 1 つのボタンを修正する)

    前の質問と同じ議論

  • アプリケーションにパッチを当てる必要がありますか、それともアプリケーション全体を最初から Macintosh スタイルから再ダウンロードしますか?

    アプリのサイズが小さい場合は、最初からダウンロードしてください。これにより、異なるパッチ間のミスマッチ (「DLL 地獄」) によって作成される、あらゆる種類の奇妙なバグを防ぐことができます。ただし、これには長時間のダウンロードが必要になるか、ネットワークに大きな負荷がかかる可能性があります。

  • ユーザーが中央の場所から更新できるようにするか、指定されたアプリケーションを介した更新のみを許可する必要がありますか? (クローズド ビジネス アプリケーションの場合)。

    両方だと思います

于 2009-12-16T06:42:40.350 に答える
2

実際の経験から、更新エンジンを更新するための機能を追加することを忘れないでください。つまり、更新の実行は通常2段階のアプローチです

  1. 更新エンジンに更新があるかどうかを確認します
  2. 実際のアプリケーションに更新があるかどうかを確認します

クライアントソフトウェアが古くなっているが、他のバージョンのソフトウェアまたはデータベース自体と通信しようとしたときに壊れない場合は、強制的に更新しますか？もしそうなら、あなたはこの重大な変化をどのように意味しますか？

一般的な方法は、許可されている最低/最古のバージョンを示す「ProtocolVersion」メソッドを使用することです。

「ProtocolVersion」は、クライアントとサーバー間の信頼レベルに応じて、クライアントまたはサーバーのいずれかによって提供されます。信頼レベルが低い場合は、クライアントに「ProtocolVersion」を提供させてから、クライアントが更新されるまでサーバー側へのアクセスを拒否することをお勧めします。「高信頼レベル」のシナリオでは、サーバーが受け入れる「ProtocolVersion」を提供し、これに適応するためのすべてのロジック（クライアントアプリケーションの更新を含む）をクライアントのみに実装する方が簡単です。バージョンチェック/処理コードが1か所にあるだけでよいという利点があります。

于 2009-12-16T08:05:41.830 に答える
2
  • 弁護士が要求しない限り、更新を強制しようとしないでください。承認または無視できる更新通知をユーザーに表示します。彼女が拒否したので、同じバージョンをスパム送信しすぎないようにしてください。彼女が決定を下すのに役立つように、リリース ノートへのリンクまたは変更の簡単な概要を含めます。
  • 毎週はデフォルトの更新チェック間隔として適切ですが、Web からの更新チェックを完全に無効にするなど、ユーザーがこれを選択できるようにします。彼女は高価なモバイル データ プランを利用している可能性があるため、あまり頻繁にチェックしないでください。または、アプリケーションが家に電話をかけるという考えが気に入らないだけです。
  • 更新チェック部分は完全にサイレントにする必要があります。更新が見つかった場合は、ユーザーに通知を表示します。ダウンロードおよびインストール中に進行状況バーを表示します。
  • これを簡単にするために、新しいバージョンについてユーザーに通知します。いくつかのマイナーなバグ修正を含む頻繁な更新で彼らを困らせたくない場合は、更新チェッカーが監視するダウンロード場所ですべてのマイナー バージョンをリリースしないでください。
  • 以前にリリースされたすべてのバージョンのパッチを維持するのは大変な作業です。ダウンロード サイズが問題になる場合は、パッチ以外の方法でサイズを小さくする方法を考えてください (7-zip で圧縮された自己解凍型の exe、独立したバージョンを持つ複数の MSI パッケージにアプリケーションを分割するなど)。

さらに2つのこと：

  • アプリケーションを使用していないときでも、バックグラウンドで常に実行されているプロセスとして更新エンジンを実装しないでください。私の PC はすでに ~10 個のプロセスがリソースを占有しており、非常に迷惑です。
  • 更新エンジン自体を更新する場合、一方ではエンジンを実行してインストールの進行状況 UI を表示する必要がありますが、他方では更新プロセスを閉じて、exe ファイルがロックされることによる再起動を回避する必要があります。%TEMP% からヘルパー プログラムを実行する、Windows インストーラー再起動マネージャーを使用する、インストール パッケージを開始する前にアップデーター exe ファイルの名前を変更するなど、さまざまなことがあります。更新エンジンを設計するときは、この点に留意してください。

    • 于 2009-12-16T08:53:38.493 に答える
    1
    • クライアント ソフトウェアが古くなっているが、他のバージョンのソフトウェアまたはデータベース自体と通信しようとしても壊れない場合、更新を強制しますか? もしそうなら、この重大な変更をどのように意味しますか?

    ユーザーに尋ねます。

    • どのくらいの頻度で更新を確認する必要がありますか? 毎週/毎日/毎時、正確にはその理由は?

    ユーザーに尋ねます。

    • UI の観点から、更新をユーザーに表示するか、バックグラウンドで実行する必要がありますか?

    ユーザーに尋ねます。

    • メジャー アップデートでない場合、利用可能なアップデートがあることをユーザーに通知する必要がありますか? (たとえば、実際には 1 人のユーザーのみが必要とするアプリケーションのリモート部分にある 1 つのボタンを修正する)

    ユーザーに尋ねます (ここで傾向に気づきましたか?)。

    • アプリケーションにパッチを当てる必要がありますか、それともアプリケーション全体を最初から Macintosh スタイルから再ダウンロードしますか?

    通常、アプリケーションのサイズがかなり大きい場合は、パッチを適用します。

    「ユーザーに尋ねる」という回答に関する限り、毎回必ずプロンプトを表示するという意味ではありません。代わりに、彼らに何を求めるべきか、何を目に見えないようにすべきかを設定するオプションを与えてください（そして、特定のことが初めて発生したときに、将来何をすべきかを尋ねて、それを覚えておいてください）. これはそれほど難しいことではなく、ユーザー ベースの大部分から多くの善意を得ることができます。これは、アプリを使用するすべてのユーザーの希望に合わせて固定設定を設定することは非常に難しいためです。確信が持てない場合は、オプションが少ないよりは多い方がよいでしょう。特に、コーディングがかなり簡単な種類のオプションである場合はなおさらです。

    于 2009-12-16T06:25:16.250 に答える