モバイル」タグアーカイブ

不可解過ぎます!WebViewのHTML5アプリケーションキャッシュ

AndroidアプリからWEBアプリを操作するハイブリッドアプリを開発リリースしています。その際に用いたWebViewという機能。PC版Javaにも同様のものがあり非常に便利そうに見えるのですが、WebViewが提供するHTML5アプリケーションキャッシュに不可解なことが多くて困っています。

「アプリケーションキャッシュ」とは

「アプリケーションキャッシュ」とは、HTML5で導入されたもので、ネットワークへの接続があってもなくても、scriptやら画像データやらHTMLやら、本体のHTMLから参照される全ての外部ファイルを、そのアプリ専用のキャッシュから読み込んでくれるというもの。極論すればネイティブのアプリケーションのように動作しているように見えるというもの(多少遅いけど)。

この機能は非常に便利で、一度キャッシュされると、ちょっと厳格すぎるように見える手続きを陽に踏まない限り、テコでもキャッシュを更新してくれない位強力なものです。SafariやChromeブラウザでの経験しかありませんが、普通のいわゆるキャッシュとは全然違うようです。

キャッシュとアプリケーションキャッシュの違い

ネットを探してみると、膨大な情報がありますが、なんとなく「キャッシュ」と「アプリケーションキャッシュ」を同じものとして扱っている記事が多い感じです。名前が似ているので当たり前なのですが、それでは何故わざわざ「アプリケーション」キャッシュという言い方をするのでしょうね。

同じ、もしくは包含関係にある、それとも、全く排他的なものなのか、それも不明です。実際どちらにも当てはまりそうな場合がありました。

ここでは、「アプリケーションキャッシュ」でネイティブのアプリケーションのように動作させていながら、必要なときにはキャッシュを消去したり更新したりするにはどうすればいいか、ということを考えます。「更新が効く」/「更新が効かない」は、WebViewで呼ばれるURLにあるscriptファイルの文字列を一部変えてみて、表示に変化があれば「更新が効く」、なければ「更新が効かない」としています。もちろんscriptファイルはmanifestファイル内のCACHEフィールドに記述されておりmanifestファイルの文字列を一部マニュアルで更新しています。

WebView#clearCacheが効かない

ネットによると、キャッシュ消去の標準的なやり方は、WebView#clearCacheを使う方法のようです。onDestroy()中で、WebView#clearCache(true)を実行して「loadStorage」と「アプリケーションキャッシュ」で検証してみました。使い方や呼び出す順序がまずいのか、まったく効きません。ネットでは効くのが当然のような書き方が殆どなので恐らくなにか間違っているのでしょうね。これについては簡単なプログラムで確かめてみたいと思います。

省略値を陽に宣言しないと動作しないのは何故?

Enabling HTML5 AppCache in Android Webview programatically.のページには、WebView#AppCacheEnabled()はよいとして、WebView#AppCachePath()、WebView#AppCacheMaxSIze()にも省略値を陽に指定しないと動作しなかったとあります。実際Path指定がないとエラーになりました。

こういうことがひとつでもあると何を信じてよいか分からなくなりますね。ただ、どこかのページには「Pathを陽に示せ」と書いてあったようにも記憶しています。ちなみにAppCacheMaxSizeに1024*1024*5の代わりに「0」としても「アプリケーションキャッシュ」は動作していました。「0」ではなくて「1」とか思いっきり小さい値がよかったのかも知れませんね、この手の検証では。

「アプリケーションキャッシュ」ではなく、「キャッシュ」だけ使いたい場合にはこのような指定は必要ないのか、これも不明です。

Android端末のアプリケーション設定での謎!?

Android端末の「設定」に「アプリケーション」という設定項目があります。アプリを選び「本体データ削除」「キャッシュ消去」のうち、「キャッシュ消去」を有効にしてみました。すると、そこに出ているキャッシュデータ量を示す数字は0になりますが、依然として「アプリケーションキャッシュ」が動作していました。「キャッシュ消去」前の容量は、ちょうど「アプリケーションキャッシュ」のためにMaxサイズとして指定したものと一致しており、直感的に「キャッシュ」=「アプリケーションキャッシュ」もしくは包含されるように考えてしまいました。

「本体データ削除」だと「アプリケーションキャッシュ」が更新できますね。何故でしょう。ただ本体データ削除のデータ量は70kB程度で自分のアプリは画像を含め150kB程度ありますので、「アプリケーションキャッシュ」が「本体データ」に含まれるというのも数字が合いません。「キャッシュ消去」にでている量は5MB強とリーズナブルです。

やっとみつけたWorkAround(ワークアラウンド、回避策)

「本体データ削除」だと何故か「アプリケーションキャッシュ」が更新できますが、設定が多いと結構つらいです。なので、なにかいい方法はないかと探していたら、すぐ近くにありました。「強制停止」+「キャッシュ消去」です。理由は分かりませんが、設定もそのままでキャッシュ(アプリケーションキャッシュ?)やloadStorageもクリアできるようです。

PHPとは共存できないんでしょうか?

もうひとつ不思議なのが、PHPとの共存です。ご存知かも知れませんが、PHPコードは大抵サーバ側で処理するものですから、manifestファイルにindex.phpとあってもクライアントだけの環境ではうまく動作するはずがありませんが、index.phpそのものではなくindex.phpの処理結果をキャッシュしているのか、それなりに処理できています。いつも厳格な「アプリケーションキャッシュ」の風貌にそぐわない感じがしています。

WebViewのHTML5アプリケーションキャッシュ、不可解過ぎます。

といっても、恐らく私の勉強が足らないだけなのでしょうね。

結構複雑でわかりにくい話ですみません。

関連する記事・ページ

無料Androidアプリ「10秒で10年日記 逆さ日記帳」をGoogle Playにてリリースしました
「10秒で10年日記 逆さ日記帳」の設定に「全てのカレンダ」項目を追加しました
“Just10SecGet10yDiary R10Diary” has another feature of “All Calendars”
自作無料WEBアプリ「10秒で10年日記 逆さ日記帳」に検索機能を追加しました
「10秒で10年日記 逆さ日記帳」というWEBアプリをリリースしました

お世話になったリンク

Enabling HTML5 AppCache in Android Webview programatically.
caching – Cache dynamic page using html5 cache manifest using Android webchromeclient – Stack Overflow

以上です。

Android端末の種類でGoogleカレンダの背景色が微妙に違う!?

iOS系端末とAndroidOS系端末には色々な違いがありますが、アプリ開発者にとって恐らく一番と誰もが認める違いは「端末の種類」でしょう。AndroidOS系端末は現在3000種類以上(ハードの数とOSの版数の掛け算?)あるようです。

こうした膨大な種類があるAndroidOS系で、解像度やボタン配置などのハードの仕様が違うのは当然として、ソフト面でも違うことがあり、Androidアプリを作っていると結構戸惑うことがあります。

今回は、殆どのAndroid系端末にプリインストールされているであろうGoogleカレンダについて、アプリ開発者としての体験談です。

ご存知の方は多いと思いますが、Googleカレンダは複数のカレンダを同時に表示したり検索したりして管理できるのですが、属性のひとつとして「カレンダ背景色」があります

原則的には自動割り当てされますが、仕事や家族や恋愛や信仰などでそれぞれご自分のイメージにあわせた色分けをされている場合も多いと思います。

ちなみに私の場合は、「仕事」は青、「家族」は薄青、「恋愛」関係?はオレンジ、「創造」はピンク、などにしています。今週はどういった時間を使ったかがひと目でわかるため大変重宝しています。

こうした「カレンダ背景色」について、Androidアプリを作成する際にもAPIを通して取得することができますが、私が所持するAndroidOS系端末の種類によって仕様が微妙に異なりました。

挙動に違いについて、最初は単なるバグ(Codingミス)だと思っていましたが、そうではなく「仕様」(または「仕様の周り」)が違うのだということが追々分かってきました。

ソフトウエア技術者は必要最低限の仕様については必ず守ります

仕様が違うといっても、さすがに基本的な「背景色」そのものが違っているわけではありません。ソフトウエア技術者は必要最低限の仕様については必ず守ります。違っていたらそれはバグと認識されて適切に処理されます。

問題は仕様には「陽に」表れなかったであろう「ふるまい」に関するものです。

今回でいえばα(アルファ)要素です。「透明度」と言い換えてもいいと思いますが、これがAndroidOS系端末の種類によって微妙に違っていたのです。

Codeは総取替えになりますが、これが元でテストの完了した端末にも影響がでることになりました。

こうした違いはCodeのいたるところに存在するでしょうね

これを完全に定義するには標準的なCode例を公開したり、上記のような仕様定義の漏れを駆逐していくしかありません。iOS系であまりそうした瑕疵が見られないのは、種類が圧倒的に少ないからです。技術的な戦略が上手だからでソフトウエア開発技術が優秀だからというわけではないでしょう。

以上です。

海外SIMでテザリング使用時のiCloudの盲点、他

定額ブロードバンドに慣れた生活をしていると、海外での仕事や旅行時にネット接続で思わぬ出費になることがあります。乏しい経験の中からですが注意すべきポイントをいくつか紹介します。

モバイルというのは、ネット接続が前提で便利になっています。メールしかりTwitterしかりFacebookしかりです。

ただ、モバイルの通信コストは、FTTHやADSL等の固定型の通信コストに比べて、かなりの割高になります。日本国内ではモバイル定額が当たり前になってきていますが、実速度は固定型の10分の1以下であるのが実情です。なのでかなりの割高であるといわざるを得ません。

これが、海外旅行等で使う機会の多い海外SIMの場合、

  • 500MBいくらというような容量従量制のものを選択
  • 主に使うのはメールやTwitterやFacebookや写真SNS

という前提でネット環境を設計される方が多いのではないでしょうか。

海外SIMでテザリング使用時のiCloudの盲点

最近では、大容量のデータをネット経由で送受信するサービスの中にも、ネット種別によりサービスを制御してくれるものが出てきました。iOSでいうと「FaceTime」にしても「フォトストリーム」にしても、3GやLTEなどのモバイル通信では陽に設定しないと起動しません。

ところが、WIFI経由だと有無を言わさず起動されます。Wifiのもとが定額ブロードバンドだと問題ありませんがPocketWifiなどのルータを使った海外SIMのテザリングによるWifiの場合、困ったことが起こります。

たとえば、

  • フォトストリーム
  • 産経新聞の無料紙面ダウンロード

の場合、WIFI経由だとデフォルトで起動されます。そしてあっという間に大容量を消費してしまいます。とくに、私の場合、産経新聞の紙面のスナップショットを保存する習慣があるのでこれには参ります。

  • フォトストリーム。テザリングしていると、2台構成で2倍に増幅されますので本当に注意が必要です。スナップショット自体はネットを経由しませんがフォトストリームで怒濤の転送が始まります。海外SIM経由の端末はすべて設定変更しなければいけないようです。もちろん、写真を撮る端末がひとつと決まっている場合はそれだけiCloudのフォトストリームを「オフ」すれば他に転送されないので心配ありません。問題なのはいろいろな端末で写真をとって、ひとつの端末でブログなどの記事にそれらを使う場合などです。
  • 産経新聞の紙面コピー。こちらは2台構成で3倍に増幅されます。サーバからのダウンロード。スナップショットを契機としたフォトストリーム(2台分)。こちらはダウンロード自体を諦めるのがいいかと。

海外SIM運用時のdropboxの盲点

上記のように容量の喰うサービスというのは結構3GやLTEモードのとき自動識別してネット転送を制御してくれたりしますが、サービスによっては、うまく認識してくれない場合があります。

そのひとつがDropboxのカメラアップロードです。自動処理なので本当に知らぬ間に貴重なネット資源が消費されてしまいます。短時間に、しかも大量に。

他にも結構あるのかも知れません。この手の盲点は。

以上です。