Posts Tagged ‘iPhone’

[CSS3|jQuery|Webkit]translate3d等のtransformで設定した現在値を取得したい


2011
09.26

皆さんご無沙汰しております、Web屋の中の人です。

手術やらリハビリやら、少々複雑なシステム開発案件等でお勉強の方を長期に渡り休止しておりましたが久々にやってみようと言う事でインターフェイスの調整やバグ取り、むしろソースの整理なんかをしているとタイトルの状況になりました。

iPhoneiPad 上でアニメーションしたい時は、jQuery.animate は原則使い物になりませんので CSS3transform を利用してグリグリします。

 

ちなみに今回はタイトルに記載している通り「webkit」ブラウザのみ対象としていますのでご注意ください。
※Safari、Chromeなどなど。

 

ありがちな例を挙げると、js でスライダーなんかを作っている時に「この要素の x 座標は今ナンボ程動いてますか」と言う状況です。
jQuery を使っているなら簡単ですよね、

1
alert($('#hoge').css("left"));

これでパパッと解っちゃう訳で、非常に便利です。

所が CSS3transform で設定する時は、

1
2
3
#hoge {
    -webkit-transform: translate3d(237px, 5px, 0px);
}

こんな感じなので、x 座標ってどうやって書けば取得出来るの?となった訳です。

1
alert($('#hoge').css("-webkit-transform"));

取りあえずこう書いてみると、下記のように出力されました。

matrix(1, 0, 0, 1, 237, 5)

うーん、4番目が x で5番目が y なんだろうな…じゃあ z はどこに出るんだろう。

 

ブラウザ限定の強み、と言う事で素直に WebKitCSSMatrix で分解する事にした。仕様書通り使うと

1
2
3
var obj = document.getElementById('hoge');
var m = new WebKitCSSMatrix(obj.style.webkitTransform);
alert(m.e);

こんな感じになりますが、折角 jQuery を使っているので…

1
2
var m = new WebKitCSSMatrix($('#hoge').css('-webkit-transform'));
alert(m.e);

こんな感じでも取得可能です、結構乱暴に使えますね。
取得出来る値はコチラの仕様書に網羅されています、かなり色々設定出来るだけに複雑ですね…単純な物は a〜f って覚えておくのが良さそうです。

 

 

それではまた。

 

 

[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]iOSにおけるhtml5::manifestの削除について Vol.1


2011
06.02

暑くなったり肌寒くなったりで体調を崩しそうな大阪ですが、皆様の周りは如何な具合でしょう?

 

さて、今回は結構重要な話しです。

 

今後隆盛を迎えるであろう WebApp はもちろんの事、これから先は PC ブラウザで閲覧する html5 コンテンツも快適性を追求して当たり前のように使われる事になると思われる manifest の仕様についてのレポートを作りました。

実は私は色々開発はしているものの、オフラインで動かすための manifest 指定と言うモノに少々気持ち悪さを覚えています。

理由は単純に「良く解らない」からです、これが凄く気持ち悪い。

 

manifest とは、非常に強力で有用な技術です。簡単に言えば超強力なキャッシュ機能と言うとしっくり来ますね。manifest ファイルにそのページで使われるリソースのパスを書いておくと、ローカルにそれらを保存して Web にアクセスする事無くそれらを利用する事が出来るようになります。

その性能はと言うと、大げさでも無くネイティブアプリに迫る高速読み込みが行え、おまけにオフラインでも何の問題も無いと言う高性能っぷり。

 

初めて知った時は「これはもう使うっきゃ無いよね!」と思いました、だって凄いでしょう?

所が使うに当たって当然出てくる疑問があります、それは「これってどうやって消すの?」と言うシンプルな疑問。

導入方法は数多くのサイトで語られていますが、manifest を消す方法、特に iOS では未だに確立されていません。唯一消す方法は復元を実行すると言う超力技だけと言う現状。

 

本当に消えない、と言うか消せないんです。後述しますが、私も実験中に順番を誤り個人的に所持している iPhone から二度と更新出来ない URL を作ってしまいました。

※これを回避する為の準備も紹介します、絶対にこれは守らないと泣きを見ます。

PC の方は結構なんでもありなので消せる見たいですが、我々が目を向けなければならないのは一般ユーザーの方達です。

 

例えば、こんなケースが想定出来ます。

  • 色々なサイトで manifest を使った高速ブラウジングが次々と実装される
  • ユーザーは色んなサイトを閲覧し続ける
  • なんだか iPhone/iPad の HDD 容量が凄い事になってる
  • 消せない助けて

 

如何でしょう、何とも無惨な事になると思いませんか?ここで彼等に「復元しろ」とか「初期出荷状態に戻せ」なんて言える筈ありません。

この問題の指摘は Apple 社にもメールしておこうと思います、設定の Safari から manifest を個別削除出来る機能をつけないとえらい事になるんじゃないのか?と。

 

さて、取りあえず今の所 manifest 自体は「消す事が出来ない」仕様のようなので、せめて「容量を解放する方法はあるのか?」と言う方向で検証してみましょう。

 

まず manifest を触る際に、絶対に準備しなければならない事があります。

それは Javascript による manifest のチェック機能です、これを必ず最初に作る所から始めましょう。

これが無いと、そのページを開いた瞬間「消す事が出来ないキャッシュが生成されて、以後そのキャッシュしか見ない」と言う状況が発生します。

そうです、永久にそのデバイスからはその URL の情報を更新出来なくなります。先ほど少し触れましたが、私は個人所有の実機でこれをやらかしました :(

 

Javascript ソース

1
2
3
4
5
6
7
8
9
10
var appCache = window.applicationCache;
var checkUpdate = function() {
    if(navigator.onLine) appCache.update();
    else alert('Please update for online.');
}

appCache.addEventListener('updateready', function() {
    appCache.swapCache();
    location.reload();
}, false);

html ソース

1
<input onclick="checkUpdate()" type="button" value="update" />

 

簡単に要所だけ書くとこんな感じのソースになります、ここでは挙動を調べる事に集中するので詳しい設置方法や、細かいイベントの返り値なんかは、凄く丁寧に解説して下さっているブログがあるのでそちらを参照してください。

ちなみにこの appCache.update() はロード完了後に自動的に一回だけ呼ばれますが、記事を読んでると絶対じゃないそうなので念のため適当なボタンからアップデートをチェックする関数を実装しています。

 

そして manifest ファイルを準備して html 要素に manifest=”ファイル名” を追記すれば晴れて「何度でも更新出来る manifest 付きページ」の完成です。やったね!

 

次回は実機のスクリーンショットを交えて、HDD の容量変化を見ながら実際に manifest キャッシュを行ったモノを紹介します。

 

それではまた。

 

1 | 2

 

[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