2006/06/27(火) [n年前の日記]
#1 [iappli] サーバとの通信エラーの原因
について報告が。サーバから送られてくる文字列の最後に改行が入っていたらしい。アプリ側では、仕様書どおりの文字列が送られてくる場合は通信成功、それ以外は通信失敗として処理していたので、改行が入ってると「仕様書どおりじゃない」から通信失敗として扱ってたわけで。トホ。
送られてきた文字列中に、区切り文字以外の制御コードが入っていたら除外するようにしてみた。
連続で通信する際に時間を空けてアクセスしないといけないかも、という話もあったので、通信用のメソッド内の先頭で、 try { Thread.sleep(1000); } catch (Exception e) { } を入れて待つように。どんなときでも待ってしまうが、「このときは連続で呼ばれない」「このときは連続で呼ばれる可能性がある」などと各状態をチェックして対処していくと漏れが出るだろうから、絶対に、どんなときでもwaitが入るようにしたほうが安全な気がする。いや、本当はちゃんと各状態をチェックして、お客様がイライラしない状況を作るべき、だと思うのだけど。
今回のバグは、アプリ制作側の怠慢故、という話になるのだろうか。ちと判断に悩む。…改行も入ってくる可能性があると資料に一言でも書いてあれば、その旨対処もできたろうし。連続で送信されたら困ると資料に一言でも書いてあれば、その旨対処もできたろうし。レスポンス値の内容についても説明がないあたりからして、どうも元々の資料に問題があるような気がする。…これまた、ここでこうやってハマったことが、資料を書いた人間には一切伝わらない可能性も高くて。となると、説明の足りない資料がいつまでも各所に配布され、あちこちでハマる人が出てくる可能性も。厳しいな。
送られてきた文字列中に、区切り文字以外の制御コードが入っていたら除外するようにしてみた。
// s に文字列情報が入ってくる StringBuffer sb = new StringBuffer(); for (i = 0; i < s.length(); i++) if (s.charAt(i) > 0x01f || s.charAt(i) == '区切り文字') sb.append(s.charAt(i)); s = sb.toString();こんな感じ。 _パケ代定額のWIN端末で動くアドベンチャーゲームを作る を参考に。
連続で通信する際に時間を空けてアクセスしないといけないかも、という話もあったので、通信用のメソッド内の先頭で、 try { Thread.sleep(1000); } catch (Exception e) { } を入れて待つように。どんなときでも待ってしまうが、「このときは連続で呼ばれない」「このときは連続で呼ばれる可能性がある」などと各状態をチェックして対処していくと漏れが出るだろうから、絶対に、どんなときでもwaitが入るようにしたほうが安全な気がする。いや、本当はちゃんと各状態をチェックして、お客様がイライラしない状況を作るべき、だと思うのだけど。
今回のバグは、アプリ制作側の怠慢故、という話になるのだろうか。ちと判断に悩む。…改行も入ってくる可能性があると資料に一言でも書いてあれば、その旨対処もできたろうし。連続で送信されたら困ると資料に一言でも書いてあれば、その旨対処もできたろうし。レスポンス値の内容についても説明がないあたりからして、どうも元々の資料に問題があるような気がする。…これまた、ここでこうやってハマったことが、資料を書いた人間には一切伝わらない可能性も高くて。となると、説明の足りない資料がいつまでも各所に配布され、あちこちでハマる人が出てくる可能性も。厳しいな。
[ ツッコむ ]
以上です。