念願の Xperia Z1 を手に入れたぞ!

Xperia Z1 (au SOL23) が発売されたので買ってきた。

Xperia acro HD (au IS12S) の分割がまだ数カ月残っているけど... もうカメラ起動するたびにメモリーエラーが発生する機種には耐えられなくなった。アプリのテスト的にもマルチユーザー対応の Android 4.2 で 1080p の Xperia Z1 は適していると思っている。4.0 や 720p への対応確認は引き続き acro HD でできるワケだし。

で、とりあえず1日使った感想。

サイズはでかい!が、なんとかなる!

確かにサイズはでかい。同じ 5 インチの Xperia UL よりさらにでかい。一瞬びびる。が、ストラップの力を借りると片手持ちでもなんとかなる。

ストラップは必須。ストラップないと落とす可能性大。本体は下から支える感じでストラップを薬指と小指で挟んでテンションかければ安定するし、画面内の大体に親指が届く。

手が小さい自分(指輪のサイズは11号で結婚指輪はメンズ物買うのあきらめたほどの小ささ)でもいけるんだから男なら大体いけるんじゃないかと思われる。

このサイズに慣れるとこれ以下では満足できなくなると思われる。ちょうどいいと感じていた acro HD が今ではとてもとても小さく感じてしまう。

メインメモリ 2GB のパワーを感じざるを得ない!

Facebook、Twitter、Gmail、LINE、その他 au の常駐アプリ... acro HD のメインメモリ 1GB はもう限界だった。空きメモリ 80MB ってなん!

それから比べると Z1 のメインメモリ 2GB のパワーは絶大だ。acro HD と同じ状態+αにしてもまだ 700MB 以上の空きがある。約9倍。その9倍パワーはカメラとかブラウザの起動時に特に感じることができる。

acro HD はカメラ起動してもメモリに空きができるのしばらく待たないと撮影してもメモリエラーで写真保存されないとかよくあった。それが Z1 だと撮影前後30枚ずつ合計61枚のタイムシフト撮影とか簡単にできちゃう。クイック撮影機能が全然クイックじゃない acro HD とはえらい違い。

もちろん CPU/GPU の性能違いもある。だけれども acro HD だって 4.0 にする前は普通に写真撮れてた。Android 4.x 系は メインメモリ 1GB じゃ足りなかったということなんだと思うことにした。

兎に角、これならスマホで写真撮る機会も増えそうだ。特にタイムシフト撮影は娘の写真撮るのに活躍しそう。子供はアクティブだしね!

...とりあえずこんな感じ。ウォークマンとかはまだ試してない。そのうち MediaGo のライブラリコピーしてみる。acro HD はヘッドホン端子がキャップ付きだったので Bluetooth のレシーバー経由でヘッドホン使ってたけど(これもメモリ不足でたまに落ちるっていう...)、Z1 はキャップレスなのでヘッドホン直差しで行こうと今は思ってる。端子がストラップホールの対角にあるのが気にはなるけど。

Xperia Z1 と PS4 予約した

先週、Xperia Z1PS4 を立て続けに予約した。

Xperia Z1

予約したのはキャリアが au なんで au 版。まだ未発表な docomo 版には Xperia Z1f なんていう、Z1 のコンパクト版が用意されるらしい。正直、docomo うらやましい。でも、au だと iPhone と競合しそうなサイズの機種は出ないという噂。「あーなるほど」とか思った。

この噂を見たのはグローバル版が発表され、まだ au 版が未発表だった9月頭。この瞬間から Xperia Z1 の購入を検討することにした。でかいとは思うんだけれども、もう au で Android な人は5インチ液晶行くしかないじゃん、と。

で、店頭で同じ 5 インチ液晶の Xperia UL をいろいろ触ってみる。うん、でかい。片手でキーボード打つの大変。でも、確かにでかい画面は説得力がある。4.3インチ液晶の Xperia acro HD と比べ、これはいって(操作性)こい(画面サイズ)でチャラになるレベルかも知れない。そして何よりも、もう Xperia acro HD には飽きたし動作の重さにも耐えられない。

最後に「自作アプリの FULLHD(xxhdpi)機での動作チェックにもなるじゃん!」という理由付けもした。もう Xperia Z1 を購入しない理由がない。au からの発表を待って 10月2日に即 au ショップで予約したという形。発売は 10月下旬らしい。正直、かなり楽しみです。

PS4

PS1 には飛びついた。PS2 世代は飛びついたハードはなかったけど DC、PS2、GC、Xbox1、この順番で結局全部買った。PS3 世代は Xbox360 のが発売早かったからそれに飛びついた。PS4 世代は... PS4 に飛びついて間違いないよね!

ってことで PS4 予約した。先行予約には決済が必要で「約5カ月先の4万円もするゲーム機の決済今からするとかどうなの?」って若干思ったけど、発売日に欲しい衝動を前にすると、それはほんの小さな問題でしかなかった。超楽しみ。Xperia Z1 とどっちが楽しみか?と言われると PS4 のが楽しみ。早く DS4 触ってみたい。

ただし、問題点がひとつ。ローンチに買うソフトを何にするか? とりあえず初回限定版を予約したから KNACK とかいうアクションゲームのダウンロード権は付いてくる。「本体だけ買っても遊ぶゲームないじゃん!」とはならない。

だからと言ってこれ1本でいいかというと... そもそも発売日当日はダウンロード遅そうじゃない? 買って初期設定したらすぐにゲーム開始したい。それにはディスク版のゲームが必要になる。

候補はこんな感じ?

  1. バトルフィールド 4 (BF4)
  2. コール オブ デューティ ゴースト (CoD:G)
  3. KILLZONE SHADOW FALL (KZSF)
  4. アサシン クリード4 ブラック フラッグ (AC4)
  5. ウォッチドッグス (WD)

このなかでいちばん可能性が低いのは AC4。アサクリは3作くらいやったけど、結構好きなシリーズ。が、もういいかなと思う自分もいる。

同じUBIの WD は動画を見ても何がなんだかよくわからないゲーム。現代版アサクリ?新規IPってところに引かれもするし、不安も感じる。どうなのこれ。

BF4 と CoD:G は人気 FPS の続編。両シリーズとも経験済みだけに安心感はある。弱点は AC4 もそうなんだけど、これらのゲームは年内に PS3 版が発売されるということ。PS3 で2013年に発売済みのゲームのグラフィック良くなった版を2014年2月下旬に買うってのはどうなの... という気がどうしてもしてしまう。

この問題がなくて PC ゲームをやらない人にとって次世代感をいちばん感じさせてくれるタイトルが KZSF ってことになるかと思う。静止画を見ても動画を見てもこのゲームがいちばんきれいに見える。問題は KZ シリーズはゲーム的に普通ってこと。悪くないんだけど... 普通。同じ FPS なら BF か CoD シリーズのが好き。

ってことで、候補のどれもが決め手に欠ける。今のところ... KZSF か WD かな... あーまよう。

Volley で画像キャッシュ

Android 用の Volley なるライブラリの存在を知った。

調べてみるといろいろと便利そうだ。特に、画像を HTTP でダウンロードしてくるところなんて超簡単になりそう。早速フォーミュラニュースまとめ読みのフォトギャラリーに使ってみることにした。その時のメモ。

(1) ディスクキャッシュのサイズを指定して RequestQueue を作成

「Android Volley」でググって出てくるサンプルは大体以下のように RequestQueue を作成している。


mRequestQueue = Volley.newRequestQueue(getApplicationContext());

Volley.java と DiskBasedCache.java を見ればわかるが... これだと 5MB しかディスクキャッシュを使わない。画像キャッシュの場合どうなの?もう少し多くてもいいんじゃない?

と、なるとまず Volley.java の newRequestQueue() メソッドは使わない。newRequestQueue() メソッドのソースを参考に、以下のようなメソッドを作成すればいい。


public static RequestQueue newRequestQueue(Context context, int cacheSize, HttpStack stack) {
    File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR);

    String userAgent = "volley/0";
    try {
        String packageName = context.getPackageName();
        PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0);
        userAgent = packageName + "/" + info.versionCode;
    } catch (NameNotFoundException e) {}

    if (stack == null) {
        if (Build.VERSION.SDK_INT >= 9) {
            stack = new HurlStack();
        } else {
            // Prior to Gingerbread, HttpUrlConnection was unreliable.
            // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
            stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
        }
    }

    Network network = new BasicNetwork(stack);

    RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir, cacheSize), network);
    queue.start();

    return queue;
}

public static RequestQueue newRequestQueue(Context context, int cacheSize) {
    return HttpUtils.newRequestQueue(context, cacheSize, null);
}

ポイントは new DiskBasedCache(cacheDir, cacheSize)。DiskBasedCache のインスタンスを作成するとき、元のソースは new DiskBasedCache(cacheDir) となっている。DiskBasedCache のソースを見ればわかるが、このコンストラクタはディスクキャッシュサイズにデフォルトの値を使用する。ディスクキャッシュサイズを指定可能なコンストラクタを使って DiskBasedCache クラスのインスタンスを作ってあげればいいだけ。

ってことで、今回作った newRequestQueue を使って RequestQueue のインスタンスを生成すれば、ディスクキャッシュサイズなんて思いのまま。


// キャッシュサイズに 32MB を指定
mRequestQueue = newRequestQueue(getApplicationContext(), 32 * 1024 * 1024);

(2) 画像の取得に成功/失敗したときに独自のコードを実行したい

さて、実際に Volley で画像を取得してみるとする。ググると出てくるサンプルには NetworkImageView を使う例と ImageLoader を使う例がある。

GridView なんかに小さいサムネイル画像を読み込む... なんて場合は NetworkImageView をそのまま使ってもいいかも知れない。GridView の ArrayAdapter で convertView が使いまわされたときの対処もこれだと簡単だ。内部でちゃんと cancelRequest() を呼んでくれている。

だがしかし、NetworkImageView は ImageView の拡張だ。TouchImageView とか、独自の ImageView に画像をロードしたい場合は素直に ImageLoader を使おう。これでも AsyncTask 使うよりずっと楽だ。


ImageListener listener = ImageLoader.getImageListener(
    touchImageView, 
    android.R.drawable.ic_menu_rotate, 
    android.R.drawable.ic_delete);
mImageLoader.get("http://hogehoge/image.jpg", listener);

こんなサンプルをググると発見することができる。ImageListener を ImageLoader の getImageListener() メソッドで作成している。当たり前だが、これだと画像のロード後に自前のコードを実行するとかできない。具体的にはロード後に ProgressBar を非表示にしたい... とか。

そんなときは ImageListener を自前で実装すればよい。ImageLoader.getImageListener() のソースを見てみればいい。実に簡単なコードだということが分かる。これくらいなら処理ごとに getImageListener() を自前で作ったってそんなコストにはならない。


public static ImageLoader.ImageListener getImageListener(final ImageView view, 
    final ProgressBar progress, final int defaultImageResId) {
    return new ImageListener() {
        @Override
        public void onErrorResponse(VolleyError error) {
            if (defaultImageResId != 0) {
                view.setImageResource(defaultImageResId);
            }
            view.setVisibility(View.VISIBLE);
            progress.setVisibility(View.GONE);
        }

        @Override
        public void onResponse(ImageContainer response, boolean isImmediate) {
            if (response.getBitmap() != null) {
                view.setImageBitmap(response.getBitmap());
                view.setVisibility(View.VISIBLE);
                progress.setVisibility(View.GONE);
            }
        }
    };
}

とかね。ポイントは onResponse() だと思う。この onResponse() は、キューの実行中に何度か呼ばれる。なので、response.getBitmap() が != null だったときだけ、ProgressBar を非表示にしてあげればいい。

「response.getBitmap() がずっと null だったら ProgressBar が表示されたままになるじゃん!」 ってことに関しては問題にしなくてもいい。以下の場合は onErrorResponse() が呼ばれるのを確認している。

  • requestUrl のホストが見つからない。
  • requestUrl が 404 not found.
  • requestUrl が画像じゃない。

...こんな感じで。

Recent articles

Categories

Monthly archive

  • (Empty)