全アーティストの一覧が左、その選択に対応するアルバムと所属する曲の一覧を右に表示する。従来の実装では全曲をひとつのテーブルで表示していた。コンポーネントに反映するだけの単純処理で済む。今回はアーティスト、アルバムという親子関係がある。よって曲情報の階層化が必要。保存形式から見直すべきか迷った。ようにするべきか否か。管理まわりを相当に変更することとなる。動的に階層化したほうがよいだろうと判断した。音楽プレーヤーを見ると、アーティスト名のソートにおいて定冠詞が考慮されている。除外した名前で判定され、BEATLESWhoと扱われ比較されるようだ。定冠詞の大文字・小文字は無視。サンプルでもこれを参考に比較関数を実装してみた。媒体として流通していた場合、複数枚で構成されている可能性がある。これはどのように扱うべきだろうか。面でコンセプトを変えるものもあった。アルバムが作られている。した意図を汲むならばディスク単位でアルバム表示することになる。曲の所属するディスクごとにジャケット画像を変えている可能性もあり、それを判定できる。同様にアルバム内でディスク番号を分類することにした。アルバムとして分けてしまうと曲の追加と削除処理が面倒というのが、その理由。この処理は以下のように実装した。ディスク番号でグループ化。なる連想配列を生成するような感じ。単位でループさせることでディスク番号の階層を表示している。以下の比較関数でソート済み。優先度はディスク番号、トラック番号となる。これを前提とすることで、グループ化されたディスク内でトラック番号の順に並ぶ。欄をみると以下のように書いてある。フィールドに指定された値になるようだ。指定されたパス直下にあるものになる。フィールドを書き換えてアプリを再起動したところ、その名前のディレクトリ内にデータが保存された。設定した値が既存アプリと衝突した場合はどうなるのか。実行してみたところ既存アプリのディレクトリと結合された。内容がそのまま読み込まれてしまった。アプリのデータを相互に破壊する危険性がある。なりの一意な識別子で衝突回避しているのだと想像していたけど、そんなことはなかった。衝突したことの検知や対策は用意されておらず自衛するしかないようだ。とでも指定しておくのがよいだろう。サイトなどで取得しておきたドメインを逆順にしてアプリ名と結合する。プロジェクト今回実装したサンプルを以下に公開。akabeko.me。