Posts Tagged ‘WebApp’

[iPhone|iPad]iOSにおけるhtml5::manifestの削除について Vol.2


2011
06.02

さて皆さん、早速ですが manifest は結局どう言う仕様なのよ?と言う事を私なりに解釈した解説を実機スクリーンショットを交えて紹介して行こうと思います。

 

最初は公式シミュレータでやっていたのですが、Mac の HDD を参照してしまうので容量 1TB とかあってキャッシュして数値を動かすのが非常に困難だったので実機にしました。実機は 16.9GB みたいな感じで 100MB 単位で動かせるので都合が良いです。

 

まずはこの manifest とやらはどれぐらいのキャッシュを許可出来るんだろうかと言う所から、仕様書によるとデフォルトは 5M だけど拡張可能との事。

検証方法は 3.2MB のm4v ファイル(何でも良いんだけどね)を複製しておいて、それのパスを追加しては更新の繰り返しと言う作業です。

適当な要素に #console 的な id を書いて、イベント拾って出力しながら経過を見守ります。

 

まず最初に警告が出たのはキャッシュが 10MB を超えた時でした、

10MBを超えた時に即座にアラートが出現

なんだか良く解らないのですが、「増やす」を選択しても「キャンセル」を選択しても unknown error が出力されてキャッシュが止まってしまいました。

コンソールにログを非同期に出力

取りあえず例外が投げられたらキャッシュをやり直す処理を追記して、さらにパスを増やして行くと…

25MBでも確認した

今度は 25MB を超えた時点でアラートが発生した、同じくエラーが発生したようで再びキャッシュをし直す処理が走りました。

取りあえずもうチョット容量欲しいかなと思うので、更にパスを追記。

50MBも確認した

おお、50MB 行けたね!凄い凄い、普通のサイトならデフォルト 5M で余裕だけど WebApp だと結構リソース多いからね。取りあえずこれぐらい有れば十分かな?

ここから先は試していませんが、50MB は確実に行ける事が分かりました。

 

しかしこれ…10-25-50 の度にいちいち聞かれるんだろうか、アプリに合わせて任意に指定出来ればスマートなのになぁ。

 

さて、ココからが本題。HDD どうなった?な部分ですが、48MB キャッシュした時点で下記のように変化がありました。

befor

after

使用可能の項目の値が 12.9GB から 12.8GB に減少しているのが確認出来ます、まぁローカルにキャッシュしたのだから当然ですね。

で、ここで放置してしまうとユーザーはこの消せないキャッシュの積み重ねでいつか苦しむ事になります。

なんとかこの値を 12.9GB に戻す事が今回のミッションと言う事です。

 

まず manifest から先ほどから追記しまくった m4v のパスを全て消しました、これでそのページにはキャッシュしなくても良いファイルに変わる筈です。更新を完了させてから容量を見ても…変わって無い。

Safari をタスクから切って OS を再起動しても駄目でした、一体どこに保存されているのやら。

通常キャッシュとは別物だと思っていたのですが、設定から Safari のキャッシュをクリアして、Safari を再起動してみたら…

キャッシュを消去

容量復活!

見事容量が復活しました!

これで何とかユーザーを救えそうです、キャッシュクリアの操作をさせるのは難しい事ですが manifest からパスを外してあげるアンインストール的な操作方法を用意してあげるのが良いのでは無いでしょうか。

キャッシュ自体はほっとけば何かの拍子消えるモノですし、多分。(もしかして消えない?)若しくはアプリサイトにその旨を記載しておくとかでも体裁は保てるのではないかと思います。

 

まとめ

  • manifest 自体は削除出来ない(今の所)
  • manifest からパスを外したファイルは通常キャッシュ領域に移動される、又は同じキャッシュ領域だが manifest に書かれていると削除されない仕様のどちらかである
  • manifest からパスを切ったファイルは Safari のキャッシュクリアで消せる
  • manifest 対応サイト乱立によるユーザー資源の浪費を食い止める操作を提供してあげないと大変な事になる
  • Apple が設定画面から消せるような機能を追加してくれるのに期待する

と言った感じですかね、細々したファイルなら然程気にしなくても良さそうですがやはり消せないゴミファイルが溜まって行くのは気持ちが良いモノではありません。

大きなキャッシュを残したいのであれば、削除出来る機能を提供してあげるのがマナーとなりそうですね。

今回は中々興味深い結果となりました、今後の仕様変更に注目して行きたいですね。

 

それではまた。

 

1 | 2

 

[iPhone/iPad]WebApp制作における読み込み時間/オフライン問題


2011
05.18

皆さんこんにちわ、最近随分日が長くなったなぁとしみじみ思います。

そして随分書きかけのエントリーが溜まって来たなぁと思います。

消化しないとただの豪華なオンラインメモ帳になってしまいます、これはいけません。

 

そう言う事も踏まえてなお、単発ネタです。

iPhone / iPad をターゲットにした WebApp でネックになるのは読み込み時間とオフライン時の挙動です、普通にブラウザアプリを作る感覚で行くと下記のような問題にブチ当たります。

  • ページ遷移の度に読み込んでたらストレス溜まる
  • かと言って全部最初に読み込んでおいてメモリに展開すると色々と苦しい
  • そもそもオフラインだとページ遷移とか非同期通信自体不可能じゃない

ネイティブアプリは全てローカルにリソースを置く事で回避出来るのですが、Web ブラウザを使っている以上このような問題が起こります。

 

困りました、調べました、解決しました。

 

なんの事は無い、iOSAndroidWEB Database API を実装しているじゃないか。良く考えると双方 Webkit 系だもんね、今更気づいたのかよ!と言わざるを得ません。てへ。

この API はブラウザの JS から双方のネイティブアプリを触っている方はお馴染みの SQLite3 へとアクセスする事が出来ます、つまり始まる前に全部ローカルにデータを保存しておく事が出来ます。ちょっと試した事が無いのですが blob 型が有るのでバイナリも突っ込めるはず。

そしてもう1つの問題、オフライン時にページを開こうとしたりリロードしたりしようとすると「ページを開けません。インターネットに接続していません。」みたいなエラーが出るのですが、これも .manifest を使えば回避可能です。

オフラインだとこうなります

これは強力なキャッシュ機能で、指定したファイルを全てローカルに保存して次回からはとにかくここから読み出すようです。中身を更新したい時は .manifest の中身の文字を1文字でも変えれば再構成されるようなので、ページの要素を読み込む前に .manifest のチェックが先に実行されているみたいです。

要するにバージョン管理をきちんと行い、.manifest にはそのバージョン名を入れておけば常に最新の状態をユーザーに提供出来ると言う訳ですね。

 

さて、これで…かなりネイティブアプリに迫る事が出来るようになったハズです。

思っていた以上に私は WebApp について解っていなかったのがショックですが、これで同じ土俵には上がれたと思うので益々精進したいと思います。

 

それではまた。

 

 

[iPhone/iPad]WebAppのクラス設計について


2011
05.17

 

皆さんこんにちわ、お久しぶりです。

GW 以降バタバタしておりましたが一段落したと言いたい所ですが、この業界の三大職業病「肩こり」「腰痛」「イボG」のウチ、堂々の二冠達成と言う偉業を現在進行形でございます。

 

ちょっと単発ネタです。

先週は在宅勤務で引きこもっていたのですが、何もただ単に引きこもっていた訳ではありません。

仕事や家事や PSP でミクさんを愛でる時間の合間をぬって、iPhone / iPad 用の WebApp の開発を行っていました。今回構築しているアプリのベース部分が完成して、初代 3G なんかも引っぱり出して来てニヨニヨとしていたのですが…ここからエフェクト系を山盛り入れるには、とてもじゃないけどメモリが足りない事に気づきました。

 

だって既にちょっと重いもん。

 

画像や音声ファイルのロードは最初からネックになる事は解っていたのですが、JS で生成しているオブジェクトと我らの味方の jQuery が重たくてしょうがないのです。

 

安定性を欠くようではリリースなど片腹痛い訳で、これはもう基礎部分から再設計を余儀なくされた状況です。

リソースをふんだんに使うタイプの WebApp 開発にあたり、今回解った事は下記。

  • jQuery は使わない方が良さそう
  • prototype 定義を最大限使わないとキツい
  • Ajax による リソースの loader 部分がかなりマゾい
  • ダイナミックな動きは全部 CSS3 で賄う

1つ目は単純にライブラリよりネイティブの方が早い、当然ですね。クロスブラウザ対策が必要ないのでそこまで恩恵がある訳では無いので外す方向で行こうと思った。
そうなると要素に対して CSS3 を適応させる部分は大丈夫なんだろうか、とかの不安が残る。

 

2つ目は調子に乗って何個かインスタンスを作っているとメモリがアワワな事になる、昔 prototype 汚染にトラウマ級の悪さをされて以来食わず嫌いになっていたがそんな事言ってられなくなった。
これは私の設計の甘さもあるのですが…ガベージコレクションを使う手もあるんだろうか。

 

3つ目は WiFi 環境なら余裕で無視出来るレベルなのですが、貧弱な 3G 回線だとメディアファイルの load 時間がかなりストレスになる。しかし全てのファイルを始めに読み込んでおくのは 3G や 3GS のメモリ量だと厳しい感じがするので、先読みアルゴリズムを極限まで詰めて解放/読み込みをこまめにやるべき…?
逆にキャッシュの限界量に合わせてリソース側に制限をかけるべき…?

 

4つ目は jQuery を解雇するなら当然変わりにアニメーションを担当するものが必要になる、これは使ってみた感想だけど CSS3 でアニメーションさせると jQuery の何倍も何十倍も綺麗に動くので他に選択の余地は無いと思った。
canvas を使う手もあるのだけど、html5 で組むからこそ意味があると思っているので FLASH 的な動き(むにゃむにゃ動く背景とか)の時だけ使うのが良いと思う。

 

世界的にまだまだ開拓途中のこの WebApp と言う世界、今後のスマートフォンの主力コンテンツとしての活躍が期待されているのでやり甲斐があって楽しいのですが…

 

WebApp は開発サイクルが短くて予算節約になりますよ!

 

と言う売り文句を言えるようになるまでが大変そうです、セオリーは俺が作る!ぐらいの気概は必要ですね。

 

それではまた。

 

 

JavaScript のソースは隠蔽するべきか? Vol.1


2011
04.19

さて、皆さんは Web App にどんな印象をお持ちだろうか?

平たく言えば Web ブラウザ単品で、ネイティブアプリみたいな事しちゃおうぜ!みたいなノリのアプリケーション(Web サイト)です、個人的にも今最も HOT で KOOL な技術と言う位置づけなので、会社のリソースを少し使わせて貰いながら開発を進めています。

実際にメスを入れてみると、当然の事ながら色々な問題や懸念点が出てきました。

なんのプラグインも使わずに Web ブラウザ単品でネイティブアプリに近いモノを動かす、と言う事は JavaScript に依存すると同義である事は議論の余地がありません。

しかしこの JavaScript と言うものはローカルサイドスクリプトと言われるだけあって、ユーザーの手元にあるマシン上で全ての処理を行います。とどの詰まり、ソースやら何やらが全てユーザーのローカルマシンにダウンロードされると言う事になります。

結果 Firebug 系のツールで挙動を見放題ッ!ソースそのものも保存可能ッ!!

いや、もうそれは仕方ない事だと思うのですが…サーバサイドスクリプトを普段から使っている我々からすると、何だか底知れぬ恐怖があります。

 

だってあんなトコやこんなトコも全部見られちゃうって事でしょ!?

 

オー、ジーザス。頭痛で頭が痛いです、これは。

と言う訳でちょっと抵抗してみる事にした。

 

前提条件

  • JavaScript のソース隠蔽を試みるよ
  • サーバサイドスクリプト使うよ(PHP)
  • 今回保護を試みるデバイスは iPhone だけだよ
  • iApp にも Firebug 的なアプリがあったらお手上げだよ

一言で言うと iPhone 専用のコンテンツを作って、とにかく Firebug 系のツールや単純ダウンロードから逃れてみよう!と言った感じです。

 

まず条件を整えてみる

どう言う状態になれば目標を達成出来るのか、まずはこれをリストアップしてみよう。

  1. 最強の脅威である PC の Web ブラウザ各種で見ているときはソースを出力しない
  2. 猪口才な UserAgent 偽装を見破り容赦なく例外処理を叩き込む
  3. 唯一の対象機が来た時のみ非同期にソースを出力する
  4. 隠蔽は解るけど開発効率もちゃんと考えた作りにする

こんな所だろうか、ざっと見た感じでは偽装さえ見破ればどうとでもなりそうですね。フローチャートはこんな感じで単純明快です。

 

フローチャート

 

ちなみに携帯ブラウザは無視しようと思う、奴は四天王の中でも最弱のうんたらかんたらだし、詳しく知らないけどきっと何も出来ないでしょう。大丈夫だ、問題無い。

と言う訳で次回は UserAgent の偽装について調べてみようと思う。

 

1 | 2 | 3 | 4