クラサーブなICTと共にクラサーブなICTと共にモバイルやアプリ作成を主なテーマに。旅行や料理や育メンも。「モバイル」タグアーカイブ不可解過ぎます!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」と「アプリケーションキャッシュ」で検証してみました。使い方や呼び出す順序がまずいのか、まったく効きません。ネットでは効くのが当然のような書き方が殆どなので恐らくなにか間違っているのでしょうね。これについては簡単なプログラムで確かめてみたいと思います。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アプリケーションキャッシュ、不可解過ぎます。いっても、恐らく私の勉強が足らないだけなのでしょうね。複雑でわかりにくい話ですみません。Overflow以上です。adminAndroid端末の種類でGoogleカレンダの背景色が微妙に違う!?iOS系端末とAndroidOS系端末には色々な違いがありますが、アプリ開発者にとって恐らく一番と誰もが認める違いは「端末の種類」でしょう。AndroidOS系端末は現在3000種類以上(ハードの数とOSの版数の掛け算?)あるようです。した膨大な種類があるAndroidOS系で、解像度やボタン配置などのハードの仕様が違うのは当然として、ソフト面でも違うことがあり、Androidアプリを作っていると結構戸惑うことがあります。今回は、殆どのAndroid系端末にプリインストールされているであろうGoogleカレンダについて、アプリ開発者としての体験談です。ご存知の方は多いと思いますが、Googleカレンダは複数のカレンダを同時に表示したり検索したりして管理できるのですが、属性のひとつとして「カレンダ背景色」があります。原則的には自動割り当てされますが、仕事や家族や恋愛や信仰などでそれぞれご自分のイメージにあわせた色分けをされている場合も多いと思います。?はオレンジ、「創造」はピンク、などにしています。今週はどういった時間を使ったかがひと目でわかるため大変重宝しています。した「カレンダ背景色」について、Androidアプリを作成する際にもAPIを通して取得することができますが、私が所持するAndroidOS系端末の種類によって仕様が微妙に異なりました。挙動に違いについて、最初は単なるバグ(Codingミス)だと思っていましたが、そうではなく「仕様」(または「仕様の周り」)が違うのだということが追々分かってきました。ソフトウエア技術者は必要最低限の仕様については必ず守ります仕様が違うといっても、さすがに基本的な「背景色」そのものが違っているわけではありません。ソフトウエア技術者は必要最低限の仕様については必ず守ります。違っていたらそれはバグと認識されて適切に処理されます。問題は仕様には「陽に」表れなかったであろう「ふるまい」に関するものです。今回でいえばα(アルファ)要素です。「透明度」と言い換えてもいいと思いますが、これがAndroidOS系端末の種類によって微妙に違っていたのです。Codeは総取替えになりますが、これが元でテストの完了した端末にも影響がでることになりました。した違いはCodeのいたるところに存在するでしょうねこれを完全に定義するには標準的なCode例を公開したり、上記のような仕様定義の漏れを駆逐していくしかありません。iOS系であまりそうした瑕疵が見られないのは、種類が圧倒的に少ないからです。技術的な戦略が上手だからでソフトウエア開発技術が優秀だからというわけではないでしょう。定額ブロードバンドに慣れた生活をしていると、海外での仕事や旅行時にネット接続で思わぬ出費になることがあります。乏しい経験の中からですが注意すべきポイントをいくつか紹介します。モバイルというのは、ネット接続が前提で便利になっています。メールしかりTwitterしかりFacebookしかりです。モバイルの通信コストは、FTTHやADSL等の固定型の通信コストに比べて、かなりの割高になります。日本国内ではモバイル定額が当たり前になってきていますが、実速度は固定型の10分の1以下であるのが実情です。かなりの割高であるといわざるを得ません。使うのはメールやTwitterやFacebookや写真SNSという前提でネット環境を設計される方が多いのではないでしょうか。最近では、大容量のデータをネット経由で送受信するサービスの中にも、ネット種別によりサービスを制御してくれるものが出てきました。iOSでいうと「FaceTime」にしても「フォトストリーム」にしても、3GやLTEなどのモバイル通信では陽に設定しないと起動しません。ところが、WIFI経由だと有無を言わさず起動されます。Wifiのもとが定額ブロードバンドだと問題ありませんがPocketWifiなどのルータを使った海外SIMのテザリングによるWifiの場合、困ったことが起こります。フォトストリーム産経新聞の無料紙面ダウンロードの場合、WIFI経由だとデフォルトで起動されます。あっという間に大容量を消費してしまいます。私の場合、産経新聞の紙面のスナップショットを保存する習慣があるのでこれには参ります。テザリングしていると、2台構成で2倍に増幅されますので本当に注意が必要です。スナップショット自体はネットを経由しませんがフォトストリームで怒濤の転送が始まります。海外SIM経由の端末はすべて設定変更しなければいけないようです。写真を撮る端末がひとつと決まっている場合はそれだけiCloudのフォトストリームを「オフ」すれば他に転送されないので心配ありません。問題なのはいろいろな端末で写真をとって、ひとつの端末でブログなどの記事にそれらを使う場合などです。産経新聞の紙面コピー。こちらは2台構成で3倍に増幅されます。サーバからのダウンロード。スナップショットを契機としたフォトストリーム(2台分)。こちらはダウンロード自体を諦めるのがいいかと。上記のように容量の喰うサービスというのは結構3GやLTEモードのとき自動識別してネット転送を制御してくれたりしますが、サービスによっては、うまく認識してくれない場合があります。そのひとつがDropboxのカメラアップロードです。自動処理なので本当に知らぬ間に貴重なネット資源が消費されてしまいます。短時間に、しかも大量に。他にも結構あるのかも知れません。