Blogger Glass (以下、BG)を作ったのは「Blogger で作ったブログを Blogger とは独立した表示システムで見る」ためだ。そもそもそんなことを考えるようになったのは、Blogger のブログ表示用テンプレート(とスタイル)の構造が複雑だったから。御仕着せのスタイルはどれもしっくりこない。かといって自前でスタイルを定義しようとすればテンプレートの複雑さが立ちはだかる。
それでも複雑なテンプレートと格闘し、どうにか自前のスタイルで見られるようになり、iOS デバイスにも対応した。が、そこで力尽きた。同じことを繰り返す気力が失せた。けれど、この先きっと、デバイスは増えるだろうし、スタイルにも飽きるに違いない。いずれ、また、どうにかしたくなるときが来る。
やがて BG に至る「アプリのかけら」を作り始めたときには、ただのプログラミングの練習のつもりでしかなかった。Ruby で書いてみて、Python に書き直し、せっかくだから GAE に載せた。
記事の内容が表示でき、ラベルで検索もできる。iPhone でアクセスすれば、iPhone アプリっぽく見えるように外観も整えた。ここまで来れば、BG だけで自分のブログを読むことができる。実際、最近は LOG+REPO の記事を探したり読んだりするのに BG だけで済んでいる。
しかし、まだ 1 つ、機能が足りない。BG だけで(つまり、blogspot にアクセスすることなく)ブログを読むためには、どうしてもあと 1 つ欲しい機能がある。それは、ブログの記事本文に置かれた内部リンク(同じブログの他の記事へのリンク)の貼り替えだ。
(ラベル検索の結果をふくむ)一覧表示画面から記事の内容を表示させることはできる。しかし、その記事本文に張られた内部リンクは blogspot のエントリ(すなわち permalink)を指したままだ。記事表示画面から関連記事を開けば blogspot に行ってしまう。BG だけで読み続けることができないのだ。
そう、最後に残る(基本)機能は、記事中の内部リンクの置き換えになる。
デザイン (意匠と設計)
この機能は外観には影響を与えない。記事中の一部のリンク先が変わるだけだから。よって意匠的には付け加えるものも、変更になるものもない。
一方、仕組みの設計としてはいくつか(これまでにない)考慮点がある。
記事の permalink と (BG が記事表示に利用する) ポスト ID については、どちらも Blogger から取得できるフィードにふくまれており、GData Python ライブラリを使って簡単に取り出すことができる。ポスト ID は一覧表示画面でフィードから取り出し記事表示画面へのリクエスト URL の作成に使っているし、permalink も記事表示画面中で記事タイトル部分にリンクとして貼り付けてある(つまり BG の記事表示画面で記事タイトルをたどると blogspot の同じ記事が開く)。記事本文から permalink に張られたリンク要素を抽出し、href 属性の値を /post/?id=1234567890 のようなもので置き換える。これも正規表現を使うなどすれば難しいことではない。
ここまでは問題ない。問題なのはここから。
問題は大きく 2 つある。すなわち、(a) フィードをいつ、どうやって取得するか。(b) permalink とポスト ID の組み合わせを、どこにどのように(そしていつまで)保持するか。この 2 つだ。
簡単なのは (b) の方。こちらは主に選択の問題。GAE ではデータの保存先は memcache かデータストアの 2 種類だ。どちらを使うかは容量と保存期間で選ぶことになる。あるいは、両者を組み合わせるか。いつまで保持するかについては、ユーザに管理させる(設定画面にクリアボタンを付ける等)か、アプリ側で適当な時期に消すか。データ量としては大した量でもないから前者もアリだが、アプリ(の管理者)にとっては後者の方が良い。
(a) が難しい理由はユーザ体験に関わるから。ブログの全記事を毎回取得するという方法は設計と実装が単純になるが、取得に時間がかかる可能性がある。今の LOG+REPO 程度の記事数(300足らず)なら体感するほどの遅れはないかもしれないが、対話型システムにとって大量のデータを同期的にやったり取ったりするのはできるだけ避けたいもの。それに、iPhone で 3G 回線を使っているときのことを考えれば転送量は少ない方が良い。
今、考えている方法としては、(a1) 他の目的で取得したフィードにふくまれている分だけを記録していく方法、(a2) ユーザに明示的に全取得を指示してもらう方法、の 2 つ。(a1) では一覧表示画面や記事表示画面を作る際に取得するフィードから、そこにある分だけ permalink とポスト ID の組み合わせを拾い出して記録しておき、リンクの置き換えに際しては記録にある分だけを対象とするというものだ。(a2) は設定画面等で記事データの取得ボタンを付けるというようなもの。
(a1) の場合、データの取得は、これまでも内部リンクの置き換え機能の有無に関係なく行っていることで、ユーザ体験として変わるところはない。一度も取得していない記事へのリンクは置き換えられないことになる。とはいえ、記事の内容とは違い、permalink とポスト ID の対応は通常変わることはないから、BG で一度でも表示していれば(一覧表示でも、検索結果表示でも良い)情報が記録されることになり、実用上はこれで十分と言えるかも。
まずは、(a1) 方式で作ってみよう。この場合、むしろ「いつ消すか？」の方が難しいか。「適当な時期」っていつかな。単純に経過時間で切るか。あるいは、参照頻度を加味するか。まずは「消さない」ように作るか(というより「消す」コードを書かないって表現すべきだな)。
追記@2010-12-08
「内部リンク置き換え」機能の実装については、以下の後続記事を参照。
関連リンク
- Blogger Glass (GAE アプリ)
- mnbi/bloggerglass (github)
0 件のコメント:
コメントを投稿