デザイン

WordPressのiPhone用テーマをカスタマイズ

高橋文樹

2010 年 9 月 11 日
読了4分（2,442文字）
HTML5 iPhone WordPress 電子書籍

この投稿は 14年前に公開されました。いまではもう無効になった内容を含んでいるかもしれないことをご了承ください。

新しいiPhone用テンプレート

せっかくiPhoneのことなのでWordPressのiPhoneアプリから投稿しようとしたら、保存できずに落ちてしまいました…ということで、MacBookから書き込みです。iOS4.1になってまともに動くようになったと思ったらこれだよ…

さて、このブログはガラケー（携帯電話）とiPhoneの場合にテンプレートを切り替えるという地味な機能を持っているのですが、携帯の場合はKtai Styleを、iPhoneの場合はIWPhoneというプラグインを利用しています。

実はWordPressのiPhone用プラグインはWP Touchというのが有名で、有料版もあったりするほどなんですが、iPhoneが出たばっかりの頃はどのプラグインは生き残るのかわからなかったんですね〜。IWPhoneは開発止まっちゃいましたよ。まあ、柄ケーと違ってiPhoneはシンプルなので、テーマファイルを切り替えてくれるだけ十分かと。

そんなこんなでiPhone用のテーマを作成し終えたんですが、気になったところを幾つか。

SafariとMobile SafariはCSSのレンダリング結果がけっこう異なる。あと、text-align:justisyをとっとと実装してほしい。やはりWebkit開発チームに入るしかないのか…
マニフェストファイルでローカルキャッシュできるけど、「完全にオフラインでも使えるサービス」というのは結構難しい。詳細は後述。
やはりUIが曲者。iPhoneヒューマンインターフェースガイドライン(PDF)とか読んだけど、既存のWebサービスから類推だとちょっと厳しいか。
PC用のブログだと、写真のサイズとかYoutubeのエンベッドタグとかが大きいので、それを直すのがちょっと面倒。

CSSもまともに表示できずJavascriptも動かないガラケーと比べるとテンプレートを作るのは楽ですけどね。

iPhoneをオフラインで動作させる必要性

さて、上に上げた2なんですが、なんでiPhoneのテーマを直そうと思ったかというと、破滅派（電子書籍サービス）やミニコme（通販）をiPhoneに展開していったとき、先日あったiPhoneの規約変更がもしかしたら枷になるのでは、という懸念がきっかけです。

fladdictさんという有名なiPhoneアプリ開発者（Flasherでもあり、星海社の技術顧問的なこともしているらしい）のブログ記事によると、こんな記述が。

11.1: AppStoreを経由せずに、新しい機能やコンテンツをアンロックしたり追加するアプリはリジェクトされる。

11.2: InAppPurchaseを用いずに課金する機能やサービスはリジェクトされる。

11.3: InAppPurchaceで、リアルなモノや、アプリ外のサービスを販売するアプリはリジェクトされる。

iPhoneアプリ審査での111の禁止項目（意訳）

僕は現在、色んな電子書籍アプリをダウンロードしては書籍を購入しているんですが、コミックRentaのようなアプリはクレジットカードを登録してAppStoreを介さずにコンテンツを購入する仕組みを採用しているみたいです。

となると、InAppPurchageを使わないといけなくなると思うんですが、そうすると3割をAppleに持っていかれます。Rentaもそうなるんでしょうか？　もしそうなったら、とてもじゃないけどやっていけないと思うんだけどな…　コミックRentaの取り分って、たぶん5割か4割のはずで、オーサリングフィー貰ってるかどうかはわからないけど、3割抜かれたら相当キツいと思うんですけどね。どうなんでしょう。

とにかく、こういう場合、iPhoneアプリとしてではなく、自前のWebサイトとしてサービスを展開し、iPhoneのSafariから見てもらえば、AppStoreがどうたらというのは関係なくなります。

「わざわざObjective-Cで作らなくても、HTML5+CSS3+Javascriptでよくない？」ということを行っている技術者さんはけっこういます。

こうしたことをふまえると、「HTMLでiPhoneアプリを作る」ということは、ルック＆フィールだけでなく、ネットワークにもきちんと対応したものを作る必要があります。電子書籍で考えてみたらわかるんですが、地下鉄に入って電波が途切れた瞬間に読めなくなるようなサービスではまずいです。

マニフェストファイルの書き方

で、どうやってオフライン対応するかというと、こんな感じです。マニフェストファイルというのを用意します。テキストファイルでもいいみたいですが、PHPとかで出力した方が楽です。

HTML

<!DOCTYPE html>
<html manifest="/path/to/manifest.php"> <!-- htmlの属性に書く-->

マニフェストファイル

$files;
//scandirとかで取得したファイルパスの配列。
//ファイルへのパスはマニフェストファイルからの相対パス。
//絶対パスでもオーケー

$hashes;
//ファイルに変更があった場合、ハッシュが変わるようにする。

//出力する
header("Content-Type: text/cache-manifest");
echo "CACHE MANIFEST\n";
foreach($files as $f){
   echo $f."\n";
   $hashes .= md5_file($f);
}
echo "# hash: ".md5($hashes);

こんな感じで作ると、マニフェストファイルに変更がない限り、iPhoneは以前にダウンロードしたコンテンツを使い続けます。

ただし、昨今のWebサイトはRESTフルというか、 http://example.jp/action/method/argument/ のURLに来た場合はactionコントローラーのmethodに対してargumentを渡すというような作りになってます。WordPressも似たようなもんですね。

画像やらJSやらをローカルキャッシュに入れることは多いに構わないのですが、くだんのURLが最終的に吐き出すHTMLも保存しておかないと、Webアプリケーションとしては起動しないので、ここら辺をどうするかについてしっかり考えないと駄目だなと思ったりしました。

というわけで、もう眠いので終わります。参考になるのはこの本でした。ペラッペラなのですぐ読み終わります。

[429] [429] Client error: `POST https://webservices.amazon.co.jp/paapi5/getitems` resulted in a `429 Too Many Requests` response: {"__type":"com.amazon.paapi5#TooManyRequestsException","Errors":[{"Code":"TooManyRequests","Message":"The request was de (truncated...)