ネットワーク接続が悪い場合でも？
具体的には、HTTP POST 経由でファイルをアップロードしようとする別のスレッドを (UI から) 起動するコードを作成しました。ただし、接続が悪い場合、プロセッサは outputstream.close() または httpconnection.getheaderfield() またはネットワーク経由でデータを強制する読み取り/書き込みでスタックすることがわかりました。これにより、スレッドがスタックするだけでなく、プロセッサ全体が盗まれるため、ユーザー インターフェイスでさえ応答しなくなります。
スレッドの優先順位を下げようとしましたが、役に立ちませんでした。
私の理論では、この動作を回避する簡単な方法はありません。そのため、すべての j2me チュートリアルでは、すべてをバックグラウンド スレッドで送信するのではなく、「ネットワーク経由でデータを送信しています...」画面を作成するように開発者に指示しています。誰かが私が間違っていることを証明できれば、それは素晴らしいことです.
ありがとう！
コードの書き方と実行する場所に大きく依存します。CLDC では、スレッド化の概念はかなり制限されており、スレッドが長時間持続する操作を実行している場合、他のスレッドもブロックされる可能性があります (通常はブロックされます)。アプリケーションを設計するときは、これを考慮する必要があります。
重要な側面の 1 つは、バックグラウンドでのネットワーク呼び出しが失敗したときに表示できる汎用 UI または画面が必要なことです。これは、J2ME などのモバイル アプリではほぼ必須です。
本座が言ったように、アプリの起動時にデータをプリフェッチしたり、読み込まれた画面 (つまりナビゲーション パス) に基づいてデータをプリフェッチしたり、アプリなどに組み込まれているデフォルトのデータセット。
もう 1 つは、組み込みのタイマー メカニズムです。一定時間後にデータのダウンロードを再試行し、たとえば 5 回または 1 ～ 2 分後に中止し、一般的な画面またはエラー メッセージを表示します。
J2ME の一部のハンドセットでは機内モードを検出できます。可能であれば、それを検出して適切な画面を迅速に表示できます。
また、私にとってうまくいった設計の 1 つは、UI とネットワーク スレッドを同期させて、それらが互いにロックアップしないようにすることです (いくつかのサムスンとサンヨーの携帯電話にかなりの数の興味深いバグがあったため、このアドバイスを多量の塩分と一緒に受け取ってください。これの）
全体として、あなたにとって良い答えはありませんが、異なる戦略です。