mieki256's diary

要素が空の場合に問題発生。サーバ側のレスポンス内容に連続した区切り文字が無意味に混入する場合もありうるのではと予想して、それらを一つの区切り文字にするように処理を入れてたのだけど。そのせいで、ユーザが空欄のまま入力 → 区切り文字が連続 → 不具合発生、というお間抜けなことが。スイマセン。自分がやりすぎました。連続した区切り文字 = そこの要素は空、という処理に修正。

しかし、本当にサーバ側が、連続した区切り文字を無意味に送ってくることはないのだろうか。アプリ側は、「『正常な』連続した区切り文字」と、「『異常な』連続した区切り文字」を判別する術がなく。要素数等が資料どおりなら個数チェックで内容の妥当性を判別できるかもしれんけど、現状ではそのへんすら定かではなく。万が一、「正常な〜」と「異常な〜」の両方があり得るなら、対処しきれない。

ていうか。空データがあること自体どうなんだろ。情報の種類としては、サーバ側に登録する際、弾いたほうが良さそうな気もしたり。空の情報がズラズラとページに一覧で並んでたら、ちょっとどうかと思うわけで。…まあ、アーケードゲームのその手の画面でもそういうのはよく見かけるから、さほど問題ではないのかもしれん。…ん？ 空データを受け付けるとしたら、特殊記号なんかも平気で受け付けるのかな。制御コードを入れられたらどうなるんだろう。どこまで、どんな文字をチェックして、通しているのだろう。そのへんなんだか気になる。

という要求が。ヤバイ。一つしか記録してない。ホントに複数必要なのか。必然性が見出せない。しかし、必須らしい。トホ。

容量的に入るかしら。追加してみた。容量オーバー。やっぱり。ますますヤバイ。BG用のclassを削除すべく四苦八苦。容量内に収まった。助かった。でも、エンバグしてる可能性もありそうな。その代わり、createImage を1回すれば、後は使いまわせるようにもなった。メモリの断片化を多少は抑えることができるかもしれない。結果的に良くなったのか、悪くなったのか、よく判らない。ていうか、最初からそういう作りにしておくべきだったのでは。＞自分。

何にせよ、「classを作ってはならない」てのは、本当にiアプリの鉄則なのですな…。

static final int XXXX = YYYY; とか if ( n < XXXX ) { }; とかしていた部分を、直接、if ( n < YYYY ) { }; といった具合に数値で置き換えてみたり。

最適化ツールを通してみたら、1byteたりとも変化なし。すると、コンパイラが定数として扱ってくれているか。あるいは、最適化ツールが定数埋め込みをしてくれているか。

何にせよ、自分の環境では、「プリプロセッサを通して定数埋め込みをすれば容量削減できる」という状況では無いっぽい。

との報告。アプリが起動したかしないかの時に、電源キー押しや着信等の割り込みが入ると、アプリのエラーになるという。メインループ内の初期化ステップまでくれば、エラーにはならないらしいのだけど。

手持ちのN506iSでは、すぐに初期化ステップまできちゃうから、それら割り込みを入れられない・検証できないわけで。対処を入れるとしても、原因が確定した状態で対策を入れるわけでもなく。推測・想像でしか入れることができないあたり、なんとも厳しいというか、頼りないというか。

一応、コンストラクタ内でフラグを初期化して、そのフラグが立ってない間は処理をスキップするようにしてあったのだけど。それでもダメなのか。てことは。コンストラクタ内を通る前に、リジューム処理が呼ばれてる。とか。

何を使って、アプリが完全に起動してないこと・コンストラクタ内をまだ通ってないことを知ればいいのか。…Java初心者なもんで、そのへんわからんです。困った。何かのポインタが null であることをチェックすればどうにかなるかな。って、そのポインタとしてどれを使えばいいのかが判らないわけで。

他の機種では起きてないらしい。となると、ネイティブヒープ不足 or Javaヒープ不足、なのかな。N505とD505はそのへん起きやすいとどこかで見た記憶も。画像の面積を減らさないと。

画面の枠部分に使ってる画像の透明部分を除外すれば、面積がかなり稼げるかもと気づいた。EDGEで編集して分割。

タイトル画面とオプション画面の背景画像を、ゲーム開始直前に dispose() してみたり。ゲーム中は使わない画像なのだから、その分、ゲーム中はメモリに余裕ができるんじゃないかと期待。また、ステージ開始時のBGチップ画像を、一枚ずつ、use() → BG表示用キャッシュに描画 → dispose()、してみたり。瞬間瞬間で、メモリ上に置いてあるBGチップ画像は一枚だけになるし、use() してからすぐに dispose() するから、メモリの断片化も多少は防げる、といいなとは思うんだけど自信なし。ただ、D505i においては更に事態を悪化させる可能性も。D505i は、 _画像のヒープははじめて描画した時に確保される らしいので。どういう動作になるのか、ちと想像できない。

気づいたのが夕方。電話があって気づいた。しかも30分後に提出する予定だったという…。や、目が痛くて休んでた故に気づくのが遅くなってしまったという事情もあるわけですが。しかし、なんとも申し訳ない。

ある程度対策を入れた版を送ろうとしたら。外では、物凄い雷雨に。落雷の危険性が。マズイ。ファイルを渡すまでは、ウチがネットと断絶してしまうわけにはいかんのだけど。しかし落雷は怖い。また、ルータやらなんやらが壊れるのは痛い。

念のために、メールに添付して送ろうとしたら。ウイルス対策ソフト AVG が、「ファイルサイズでかすぎ。チェックできない」と言ってきた。うーん。

試しに「宅ふぁいる便」を使ってみたり。ちゃんと届くかな。

もしかすると、相手先のサーバにアカウントを用意してもらって、そこに転送したほうがいいのかもしれん。…転送するためのサービスについては、ちと調べないと。SSHとFTPを絡めたりするのかな。scpだかsftpだかそのへんが関係してくるのかも。