Androidアプリのメンテナンスを引き継ぎました。多少の問題は残っていますが、多少の修正はありますが、Android OSのバージョンが異なるためにまだ問題があります。
たとえば、MediaPlayerクラスを使用してWebリクエストを送信すると、リクエストが送信される前にOSによってカスタムHTTPヘッダーが取り除かれますが、Android 4.X（徹底的にテスト済み）のみであり、この特定の機能は依存するため失敗しますそれらのヘッダー。
これは既知の問題であり、回避しようとしていますが、次のような条件付きチェックを行うことをお勧めします
if (OS.VERSION == 4) {
knownIssueDialog(This feature will not work on your Android version... etc.");
}
明らかに、サポートチャネルにこれを記載しますが、これらの既知の問題もソフトウェアに埋め込み、必要なときに必要に応じて提示することは（すべてを追跡することを前提とする）良いアイデアかどうか疑問に思っています。上記のようなものです。
このような種類の問題に基づいて、複数の悪いレビューと多くのサポートメールを受け取り続けるため、適切に機能しないことがわかっている機能をブロックするだけで、多くの時間と頭痛の種を節約できると思います。
2つの潜在的な問題があります。
- ユーザーは、「既知の問題」ダイアログのようなものを見たことがないでしょう。多くのユーザーは、それが何を意味するのか理解していないかもしれません。
- 開発のオーバーヘッドが少しあります-これらの問題をコードのどこかに追跡する必要があります。幸いなことに、Javaアノテーションを使用すると、そのような条件付きチェックの前に、
@KnownIssueまたはそれに類することができるため、それらの検索/変更が非常に簡単になります。
ソフトウェアに「既知の問題」プロンプトを入れるのは理にかなっていますか？
編集：これは、約1週間前に発生し始めた問題であることを追加します。私は問題を半分修正しましたが、問題を引き起こしているのはOSであるため、4.Xで修正できる可能性は非常に低いです。修正された新しいバージョンをリリースして、ユーザーベースの50％を再び幸せにし、他の50％（4.Xユーザー）に4.Xでも問題が続くことを警告し、アップグレード（または何か）。問題は、ソフトウェアでそれを行う（つまり、4.Xユーザーにダイアログを表示する）か、「修正が機能しませんでした!!!」というサポートメールを送信するだけかどうかです。その後、問題をさらに詳しく説明するサポートページに移動します。