特殊な問題。突然サムネイル画像が作成できなくなった。

テストは asus Pad TF300T という専用キーボードの付属したタブレットを使用。
キーボードのユニットにUSB接続端子が１つある。

普通はアダプタを使い本体にUSBデバイスを接続する。
制約はストレージの場合、FAT32でフォーマットされていること。FAT32でないと認識されない。

ところが TF300TのキーボードユニットのUSB接続はNTFSでフォーマットされていてもアクセス可能。

発生した問題はストレージ内のアイテム数の上限の違いから起きたこと。



症状と経過：

アプリ実行時に突然サムネイル画像が表示されずにエラーメッセージ警告。
エラー警告はUSB接続の外部ストレージのみ。
例外処理でファイル入出力、及び、ファイル作成で弾いたところ。

それにandroid OS 付属ファイルマネージャーで外部ストレージのディレクトリの移動もできない。

原因を考えたが分からない。
ディレクトリ内の１番から２４番目まではサムネイル画像ファイルは作成される。
２５番はエラー。他のディレクトリのサムネイル画像ファイルは作成されずエラー表示。

２４番と２５番の違いを解明しようと、２４番のサムネイル画像ファイルを削除。
アプリを実行すると２４番は作成するが２５番はエラー。

手詰まりでディレクトリ内のサムネイル画像ファイル２４枚を削除。
たまたま、他のディレクトリへ移動したら２４枚のサムネイル画像ファイル作成後にエラーストップ。

２時間ほど悩んで原因候補に当たる。
数百枚のサムネイル画像ファイルを削除した後にファイルマネージャーのディレクトリの移動を実行したら問題なく移動できた。



FAT32だと2TBまでしかフォーマットできない。NTFSはそれ以上のストレージをフォーマットできる。
接続していたHDD容量は3TB。
ストレージ内の取り扱えるアイテム数はFAT32よりもNTFSの方が遥かに多い。

知らず知らずにFAT32で取り扱える上限を超えていたのだろう。
デバイスが外付けストレージのフォーマットをFAT32に制限しているので、android OSで取り扱えるアイテム数の上限をFAT32に合わせていると推測できる。


対応は、本体内の画像と同じのキャッシュディレクトリにサムネイル画像ファイルを保存する。

外部ストレージはディレクトリの移動を考えてサムネイル画像ファイル用ディレクトリを元の画像ファイルと同じ場所に作っていた。
かなり特殊な状況だが問題が起こる事、予防方法が取れない事でシステムがキャッシュファイルを場合により削除してくれる事に逃げる。

アプリ再考。フラグメントは必要？

現状、画像ビューワーはほぼ完成して安定して動くようになった。
KitKatでもメモリ不足の例外で止まらないように対処した。

ただ、別アクティビティやフラグメントも使わず、レイアウトの表示非表示で機能切り替えを行っているためにアプリ起動時間が長い。
起動時間が長い。はユーザーの不満の大きな要素である。
解消するには機能別にアクティビティか、フラグメントに分けて各初期化時間を分散する事。

メインアクティビティはスタート画像表示とメッセージのみで、画面やボタンをタップしたら本体へ移行するのが王道だろう。
プログレスサークルの導入も必要。

方法案：
１、mainActivity + subActivity(今までのレイアウト切り替えを使う)

２、mainActivity + 複数 subActivity(機能ごとに用意)

３、mainActivity + 複数フラグメント(機能ごとに切り替え)

考察：
１、
メリット：作り直す部分が少なく起動時間の不満解消に早い対応が可能。
デメリット：スタート画面以後のサブ初期化時間は長いまま。メモリ消費も変わらず融通もない。

２、
メリット：起動時間の短縮。アクティビティ毎にメモリ解放をシステムが管理。メモリ不足対応をシステム任せを期待。
デメリット：開発時間がかかる。アクティビティ毎のデータ共有の難しさ。最小データ通信。アクティビティ毎の廃棄処理。

３、
メリット：起動時間の短縮。フラグメント毎にメモリ解放をシステムが管理。メモリ不足対応をシステム任せを期待。
デメリット：開発時間がかかる。フラグメント毎のデータ共有の難しさ。最小データ通信。フラグメント毎の廃棄処理。

 

選択：
巨大なアプリでは無いし１番で様子を見たいところ。しかし、プログレスサークルが思ったように動作させられない。
２番３番は似たようなもの。onCreate()を分散するので各初期化時間は短くなる。
デバイスの違いに柔軟にデザインを対応させられるフラグメント使用が良いのかもしれない。

 

準備：
機能別フラグメント作成に当たり、データ処理の系統を確定する。
フラグメント間のデータ通信の種類や最小サイズを考える。
フラグメント破棄されることを考慮し、フラグメント再構築時の各種データ保存を考える。
プロファイルデータのアクセスを考える。種類による保存、読み出しの場所とタイミングを分ける。