DLCダウンロード状況について

概要

ダウンロードする際に、現在どのくらいダウンロードするしているか進捗をわかるようにバーなどを出すと思いますが、比較的にここの処理は

端末に負荷がかかりやすい
なぜかよく止まり現在が不明になりがち
ユーザが暇でいつ終わるかとか思う。時間がかかりそうな場合やめるかもしれない。

etc...

とかいろいろあるので、出来る限り情報をたくさん出力する画面にしたほうが開発、デバック効率が格段に上がる気がします。
UIの都合上、本番ビルドではそれらの情報を出せないとした場合、開発ビルドではでるようにしておきたいです。

出力情報

進捗バー

視覚的に一番わかりやすいので必須でしょう。
1本だけでなく複数本にするとよりよいです。
全体の進捗で1本、ファイル単位などでもう1本など。

進捗率

33%
333MB/1000MB

など。
進捗バーが複数本あるなら、1本ごとに対応させてだしてもいいかもしれません。

かなり古い記事で、修正したいことがあるのに、更新もしてませんが(汗)
http://qiita.com/okuhiiro/items/8f4c6280574fed2f7bca
「www.progress」ら辺で進捗が取得できます。

現在ダウンロードしているもの

現在ダウンロードしているファイル名を出力するだけです。
非同期的な感じで、複数同時にダウンロードしている場合はちょっと工夫する必要があるかもしれません。

Wifiなどにつながっているか通信可能な状態か

スマートフォンの通信強度みたいな表記でだすといいでしょう。
地味にこれが切れているのに、ダウンロードできないとか言われるとハマります。

Not Fond

サーバにダウンロードしたいファイルがないケースです。
存在しない旨の出力をして

次のファイルをダウンロード開始するか
そこでストップ

させるか考える必要があります。

DLCダウンロード方法、クリア、切り替えなどについて

概要

ダウンロード方法とは、一括ダウンロード、分割ダウンロードなどです。
いやゆる「キャッシュクリア」、「ファイル修復」などというのがクリアというやつです。

この処理は時間がかかる処理なので、高速化や一工夫しないと運用・開発効率に関わります。

切り替えとは、開発環境のみですが...

端末はどこかのサーバに接続しているわけですが、デバック機能として下図のように切り替えることです。

↓ ↓ ↓

どうするべきか

分割ダウンロードがいい

使う時、都度その分だけをダウンロードする方法です。
メリットとしては

アプリ容量が少なくる可能性が高い(ライトユーザなどに限る)
待ち時間がないように少ないように感じる

デメリットとしては

一括でダウンロードするよりも総待ち時間が多くなる可能性がある。

リリースときから設計していないと導入は難しいですが、いれるメリットのほうが大きいでしょう。

ファイル修復で壊れているファイルのみをダウンロードするのがいい

一つの方法として、端末でファイルのハッシュ値を計算して、サーバ側であらかじめ保存してあるファイルのハッシュ値と比較する方法です。
そして、それが異なっていた場合、すなわち壊れたファイルのみをダウンロードするようにするのです。
ハッシュ値の計算時間はかかりますが、全てを再ダウンロードよりは早いでしょう。
対応するファイルのサーバにハッシュ値がそもそも存在しない場合は、不必要なファイルと判断して消すことも忘れずに行いましょう。これをやらないとアプリ容量がいつの間にか肥大化してしまします。

ちなみに自分が携わっている案件では、全てを再ダウンロード 機能しかないのです。。。
全てを再ダウンロード するのは言わずもがな時間がかかるので、極力さけるべきでしょう。
通信量も多くなるのであまりいいことがありません。
しかし、機能としては確実にリフレッシュしたいときもあるのであったほうがよいです。

切り替えられたほうがいい

このビルドで接続先サーバだけを切り替えたい!ということはよくありそうなケースなので、あったほうがいいでしょう。

言わずもがな自分が携わっている案件では、下記のようにビルド時で決まるため、接続先変える場合は、再ビルドするしかないのです。

# if DEVELOP1
    SERVER_URL = "http://develop1";
# elif DEVELOP2
    SERVER_URL = "http://develop2";
.
.
.