Android: 2011年4月 アーカイブ

　米アップルは何かと世間の関心を惹く。今日は、二つの報道が衆目を集めた。
　一つは、しばし延期となっていた日本での "iPad2" の発売。(参照　＜"iPad２"は薄型,軽量,カメラ付／処理速度2倍,画像表示性能9倍の新型半導体搭載（当日誌 2011.03.04）＞)
　もはや恒例(?)ともなった感がある長い待ち行列もできていたとか......。

　このところ、当ブログの "携帯向けサイト／SmartPhon向けサイト" の立ち上げやそれ向け "QRcode" の掲載......と、"携帯/SmartPhone" といった通信モバイル分野に関心が向いているかのようである。
　しかし、これは今に始まったことではない。以前から "携帯(i-mode)／SmartPhone" による便利な "ネットブラウジング＆メール機能" は、もっと徹底的に活用されて良いと考えて来た。
　ただ、ここに来て "再" 注目する理由があるとすれば、"携帯(i-mode)" の実用的機能性に加えて、"SmartPhone" には魅力的な "表示性／操作性" が加味されたからなのかもしれない。
　たとえ便利な機能であっても、その使い勝手が良いのとそうでないのとでは大きな開きがありそうだ。その点、"SmartPhone" での "表示性／操作性" は、小さな面積の通信モバイルとしての窮屈さをさほど意識させない。
　そうなると、 "いつでも／どこでも" という通信モバイルとしてのメリットが最大限活かされることとなるわけで、そこに着眼しつつ "実用的活用法" を大いに追及して良いのではないかと思う。
　しかも、ここでも、"電子書籍" 分野がそうであるように、受け身から転じて、"インディ・スピリッツ" に則って、この "実用的活用法" を "提供する側！" に回ってみてもいいのではないか......、と思うのだ。
　つまり、その "実用的活用法" を "マイ・ビジネス" などにおいて活用してみるということだ。

　システムの構築や改修で役に立つのが、いわゆる "コンポーネント" 方式だ。優れた全体システムになると、それぞれの機能が、"着脱" 可能なかたちで部品化されているものだ。そして、その部品は "コンポーネント" と呼ばれている。
　ユーザーが、使いたい機能を付け足したり、不要となった機能を取り除いたりしたい場合には、この "コンポーネント" を簡単に "着脱" するだけで済む。

　昨今では、ＰＣジャンルでも "ウィジェット／widget" と呼ばれる、まさにこの "コンポーネント" 方式が重宝がられている。

＜ウィジェット 【widget】
　パソコンのデスクトップ画面やWebブラウザのスタートページなどの中の好きな場所に表示できる単機能の小さなアプリケーションソフトのこと。「ガジェット」(gadget)と呼ばれる場合もある。
　カレンダーやメモ帳、地図、最新ニュース表示など様々なアプリケーションが開発され、公開されている。個々のウィジェットは、XMLやJavaScriptなどの簡単なソースコードで開発されており、表示するには動作環境であるウィジェットエンジンが必要となる。......＞（＜「IT用語辞典 e-Words」＞）

　別に "やましい事" がなくても、自分が保持する "携帯電話" が勝手に自分の "位置情報" を外部に発信するという事態には、注目かつ警戒すべきことなのかもしれない。"個人情報の漏えい" 問題の新たなケースとも見なせるからだ。
　下記のような、ちょっと気になるニュース報道があった。

＜携帯利用者の位置情報を収集か　グーグルとアップル
　【ニューヨーク共同】米紙ウォールストリート・ジャーナル（電子版）は２１日、米アップルの携帯電話ｉＰｈｏｎｅ（アイフォーン）と米グーグルの基本ソフト（ＯＳ）を搭載した携帯電話が、定期的に利用者の位置情報をそれぞれ両社に送っていると報じた。日本でも同様の情報が集められているかどうかは不明。
　集積したデータベースによるサービス向上が狙いとされるが、個人情報の漏えいに懸念が出そうだ。
　同紙によると、グーグルのＯＳアンドロイドを使った台湾ＨＴＣ製の携帯電話では、利用者の位置情報を１時間に数回、グーグルに送っている。＞（＜携帯利用者の位置情報を収集か　グーグルとアップル／【共同通信】／2011/04/22 12:48＞）

　とりあえず、"携帯/SmartPhone" 向け自サイトの最適化改造とでも言うべき作業が一段落した。
　あとは、しばらくこの状態の仕組みを使い続けながら様子を見てみようかと思っている。そんな中で、細かな改善点の洗い出しやら、とりあえずの表示デザインの見直しなどを順次進めて行こうかと......。
　これまでは、このブログを "iPod touch" 、"Safari" で「フルブラウザ」ベースで閲覧していても "字の細かさ" にさほど "辛い" 思いをするわけではなかった。が、今回の「iPhone テンプレート for MT」の表示を試すようになると、やはり "この位の文字サイズ" でなければスムーズな閲覧とは行かないな......、と再認識させられている。

　また、これまでは専ら「フルブラウザ」ベースしか念頭になかったため、画像サイズについてはことさら気にしてこなかった。しかし、"iPhone/iPod touch" 向け最適化システムとなると、サイズ自動調整という手もあるにはあるが、とりあえず "横幅サイズ" は "320 px" までとしなければレイアウト崩れの生じることも了解できた。こうしたことも、実際に体験してみるとにわかに実感させられるものである。

　この間、当ブログサイトの "自然な閲覧" が、各種モバイル・デバイス（携帯/iPhone/iPod touch/Android系デバイス）からも行えるよう、いわゆる "最適化" の試みを進めてきた。新規システムの作成というよりも、当ブログサイトのこれまでの累積エントリー(データ)がそのまま活用できるような "部分改造" だと言ってもよい。
　改善点その他の積み残しは多々あるとは認識しているが、その枠組み水準のかたちが取りあえずカバーできたかと安堵している。

　"スマートフォン対応" に向けの現行の "Movable Type"ブログシステムを "改造(?)" しようとしたが、先ず、第一弾は失敗に終わった。昨日の紹介で言うと、◆(2) ＜Smart Phone テンプレート for MT＞サイトの方の "テンプレート" の話である。
　失敗の原因は、当初から懸念していた "Movable Type" ブログシステムの "Version" 差異の問題だと推定している。
　前述の公開サイトには、＜MT 5＞限定対応とは明記されていなかった点が災いした。自サイトの現行 MT "Version" は＜4.1＞であり、これを立ち上げ時からそのまま継続して愛用しているからだ。
　が、ひょっとしたらという期待を抱いた。また、当テンプレート稼動の必須前提とされる＜プラグイン＞ソフトには、指定されていた＜MT 5＞向けのほかに＜MT 4＞向けの "Version" もあったものだから、これで行けたら......、と勝手な期待をしたのであった。

　昨日は、"MovableType" で構成している当ブログサイトの "携帯Version" の立ち上げについて書いた。
　その "携帯Version" のメリットは、これまでのエントリーがそのままデータベースとして活用できる点や、ＰＣでの「フルブラウザ」向け構成画面に比べればスマートフォンでもいくらかは読み易くなる点であろう。
　そんなことから、"携帯Version" はそれはそれで有効だとは思えるが、やはり関心と興味は "スマートフォン対応サイト" に向いてしまう。"表示や操作の最適化" という観点が捨てがたい、と......。

　かと言って、新規に "スマートフォン対応サイト" を構築するのも今一つ気が重いと感じたりしている。
　現行のサイト、それもブログサイト("MovableType" のブログ......)であることが望ましいわけだが、これをベースにしつつ "スマートフォン対応サイト" 化が図れないか、と虫の良いことを考えたりしているわけなのである。
　そんな動機で、ネット検索をしていたら、興味深いサイトに遭遇することになった。
　近日中に試してみようと考えているが、とりあえず、以下二つのサイトを記載。紹介しておきたい。

　"余震" が途絶えず、また頻繁に "緊急地震速報" が発せられる状況では、"緊急事態" がまさに日常化しているとさえ言えそうだ。
　そんな中で、"緊急時" に家族・友人との "連絡方法" への関心が否応なく高まっているようである。
　が、心配の種は、いざという場合に、"ケータイ" が役に立たないケースなのかもしれない。今回の東日本大震災時においても、現地の被災者をはじめとして、いわば日本中の人々が "ケータイ" の "不通" でヤキモキさせられた。

　こうした状況下で、次のような報道記事が目に留まった。

　昨日は、"自作ePub電子書籍" のダウンロード配布という観点から、"Web/Blogサイト" の整備充実が望まれるといった点について書いた。
　自分が、"自作ePub電子書籍" に対してはそこそこマメに対処しているのに対して、"Web/Blogサイト" の "お手入れ" については結構 "放ったらかし" 状態である後ろめたさが災いしたからなのか、やや焦点の合わない記述で終わった感がある。
　ところで、もし "ePub 電子書籍" と個々の "Web / Blogサイト" との "コラボレイト"／"シナジー効果" という点を強調するのであれば、もっと単刀直入な "切り口" があったことに気づいたりした。
　"iPhone＆Android／スマートフォン対応サイト" を構築してみるという試みのことである。

　"縦書き" 仕様で "青空文庫形式" を読ませる "i文庫HD"(for iPad)／"SkyBook"(for iPhone)などが、実に快適な "eBook" 読書を味わわせてくれるものだから、長らく "ePub 電子書籍" の "縦書き" 仕様にこだわったものだった。
　"青空文庫形式" は "ePub" 仕様ではないので、何とか "ePub" 仕様で "縦書き" 表示ができないものかと......。
　このブログをざっと振り返っても、"縦書き" 云々については、以下のように幾度となく書いていたのに我ながら驚く。

　Ｗｅｂページ上に置いた "ePub 電子書籍" は、その前提作業としての＜.htaccess＞ファイル設定（ 参照　◆＜Android SDK エミュレータで"自作ePub電子書籍"をダウンロード配布する試み成功（当日誌 2011.04.10）＞ ）さえしておけば、"iPhone/iPod touch" のみならず、"Android" 系スマートフォンからでも、各々のインターネットブラウザを通じて "ePub" ファイルとしてダウンロードさせることが可能である。
　その点を "実感" していただくために、以下のようなサイト環境を設えてみた。
　二つのサイトの "末尾" で、"自作ePub電子書籍" （量的比率がほぼ60％程度の "Sample" 版。）のダウンロード配布をご案内している。
　"iPhone/iPodtouch/Android" といった各種端末でダウンロードしていただくことが可能となっている。興味のある方は試してみてはどうでしょう......(ＰＣのブラウザからのダウンロードも可。)

　"Android SDK エミュレータ" の環境をわざわざ作って試したかったのは、"iPod touch/iPhone" 向けに制作した "ePub 電子書籍" が、"Android" 系のスマートフォンでも問題なく表示されて通用するのかどうかという点であった。その思惑についてはこの間も何度も書いてきた。
　先ず、"表示のされ方" 自体に変わりがないかという点がひとつであり、もうひとつは、 "画面サイズ" の点から "レイアウト" が併用し得るのかどうかという点である。

　既に、自作 "ePub 電子書籍" で "iPod touch 向け" レイアウトで制作したもの（下記の図◆３、◆４の自作 "ePub 電子書籍：『海念と保兵衛』for iPod ）に関しては、一昨日のブログで紹介したとおり、"Android SDK エミュレータ" で問題なく表示された。
　それによって、一応 "検証" できたと思われるのだが、念のためにということで、もうひとつ別の作品についても例証することにした。
　下記の図◆１、◆２の自作 "ePub 電子書籍：『かもめたちの行方』for iPod がそれである。

　果たして、"ePub 電子書籍" は "ePub" リーダーの差異を超えて適切に表示されるものであろうか？　その疑問が、"Android SDK エミュレータ" で "自作 ePub電子書籍" を表示させてみようと考えた理由であった。
　"iPod/iPhone" と "iPad" との間にある歴然とした "画面サイズ" の差異なども大いに気になるところであったため、このブログでも過去幾度となくレポートしてきた。
　しかし、"差異" を言うならば、サイズについてよりも "ＯＳ" が異なるデバイス間の
"差異" についてこそ検証する必要があった。
　ということで、アップルの "iOS" とグーグルの "Android OS" という差異を背負った "iPod / iPhone / iPad" 系と "Android" 系デバイスとの間の差異が、"ePub ファイル・電子書籍" にどう異なった対応をするのかを調べようとしたのである。

　そこで、スマートフォンサイズの "iPod touch/iPhone" 向けに制作した "自作 ePub電子書籍" を、"Android" 系スマートフォンのエミュレータである "Android SDK エミュレータ" にダウンロードして表示させた上で、その結果を吟味してみようとしたのだ。
　この間も書いてきたように、"Android" 系実機デバイスではないことによる制約（ "Android Market" からのダウンロードは不可！）があったり、ダウンロード元サイトのサーバ設定（ "ePub" を "MIME" 設定でオーソライズする！）を行う必要が生まれるなどといった伏兵も潜んでいた。
　が、とにかく下記のサンプル画像で示すとおり、予めインストールしておいた "ePub リーダー" アプリの "Copper Reader" によって、今後詳細に検証してみるに耐える高画質の表示を得ることができたのである。
　詳細はおくとして、先ず確認できる点は、"iPod touch/iPhone" 向けレイアウトで制作した "自作 ePub電子書籍" は、ほとんど再調整することもなく "Android" 系スマートフォンで適切に表示されそうだという点である。（"Android" 系実機デバイスが手元にないため、現時点、実機では未確認である）

　"Android SDK エミュレータ" を使って、自サイトに置いた "ePub電子書籍" をダウンロード配布しようという試みを、漸く "成功させる！" ことができた。
　要するに、サーバサイドのファイル・システムの一角に、 "MIME" に関する「.htaccess」ファイルといういわば「御触書(おふれがき)」のような特殊ファイルをかませること。それによって、自サイト内に置いた ".ePub" という拡張子のファイルを取り扱う際には、何はともかく "ePub ファイル" なんだ！　と心得なさい、と周知徹底させるのである。くれぐれも、怪しい者と見間違ったり、勝手に "text ファイル" や "zip ファイル" と取り違えてはなりませんぞ、と。

　おかげで、"ePub ファイル一行" としてのお墨付きがあったためか、"Android SDK エミュレータ" 側も、
「"ePub ファイル" 様のご到着ですぞ、くれぐれも粗相がないように "ダウンロード屋敷" にご案内しなさい」
とばかりの丁重な対応を返すのであった。
　この点では、昨日まで、"ePub ファイル" を "zip ファイル" としてダウンロードしていたブラウザの "InternetExplorer7" までもが、
「これはこれは、"ePub ファイル御一行" 様でございましたね。どうぞどうぞこちらへ......」
と手のひらを返すように、"ePub ファイル" と再認識しての出迎えに転じたのである。

　この間、"Android SDK エミュレータ" でトライして来た案件は、結局、「自分のWebサイトから "ePub電子書籍の配布" を可能とする"サーバ設定"の方法」という問題に収斂(しゅうれん)しそうである。
　"Mozilla Firefox" を常用ブラウザとして使って来たところから、"ePub ファイル" をダウンロード配布するということを、若干イージーに受け止めていたようだ。
　確かに、"ePub リーダー" の役割まで果たす "Mozilla Firefox" は、"ePub ファイル" に対して的確な対応をしてくれる。アドオンソフトの "ePub リーダー" ではブラウザ上で "ePub電子書籍" をほぼ問題なく閲覧させるし、また、ダウンロード保存に関しても小気味良くウィザード画面を出して "開く or 保存" のお伺いをしてくれたりもする。
　そんなものだから、自分のWebサイトにリンク形式で "ePub ファイル" を並べておきさえすれば、ユーザは直ちにダウンロードできるものと思い込んでいたわけだ。

　しかし、今回、"Android SDK エミュレータ" をダウンロードのデバイスとして試用してみたことで、"ePub ファイル" をそれとして扱い、ダウンロードさせるという手順が、これはこれとして一つの "ジョブ" なのだということに気づかされた。
　ちなみに、"Android SDK エミュレータ" でのこの点の途中経過としては、"Mozilla Firefox" のブラウザでは、しっかりと "ePub ファイル" としてダウンロードされるものが、"エミュレータ" ではダウンロードはなされるものの、何と "text ファイル" として扱われてしまうという珍事に見舞われたりしている......。

　"ePub 電子書籍" が読める "Copper Reader" をインストールした昨日の作業の流れからすれば、今日は、いよいよ "自作 ePub電子書籍" を "Android SDK エミュレータ" に転送して、フムフムとその表示具合を確認するはずであった。
　"エミュレータ" へのアプリなりコンテンツなりの転送は、昨日も書いたとおり、ブラウザを通じてのダウンロードという "隘路" しか存在しない。
　そこで、自サイトに "自作 ePub電子書籍" がダウンロードできる "仕掛け" を作り、"Android SDK エミュレータ" からアクセスしてダウンロードしようとしたのであった。
　ところが、その "自作 ePub電子書籍" を "Android SDK エミュレータ" はスンナリとはダウンロードしないのである。馬鹿げたことに、 "文字化け" だらけの "テキストとして開く" という "無作法" をやってしまうのであった。

　"Android SDK エミュレータ" で "ePub 電子書籍" を読むとどんな感触であるのかを確認する "お膳立て" をようやく達成することができた。
　昨日も書いたように、今自分が試みていることは、"Android" のデバイスが、スマートフォンや電子端末ではなくて、とりあえず立ち上げた "Android SDK エミュレータ" という特殊環境での試行錯誤なのである。
　"iPod / iPhone / iPad" での作業では、"iTunes" を通じてホイホイ、スイスイとコンテンツを同期(転送)させていたのに対して、この環境では何とも "転送インターフェイス" がぎこちないのである。問題点はひとえに次の点にあった。

＜ただ、残念なことにエミュレーター用の実行イメージには、Android Marketへのアイコンが含まれていない。このため、Android Marketで配布されているアプリケーションをダウンロードしてインストールすることはできない。＞（＜ASCII.jp：端末は無くとも、Androidのエミュレーターは動かせる！＞）

　いわゆる "アプリ" やコンテンツの転送のルートは、"Android Marketで配布されているアプリケーション" 以外の、在野のサイトから "apk ファイル" を探し出し、これらをインターネットからダウンロードする以外にないのである。
　当初、"ePub" に対応しているとされる "Android向け電子書籍リーダー Copper Reader" に目を付けていた。これを何らかの形でダウンロード & インストールができるならば、かなりの "前進" となるに違いない......、と。
　しかし、この " Copper Reader" というアプリは、公式の "Android Market" に登録されていて、たとえＰＣからそのサイトに入ってダウンロードを試みても "Android デバイスが見つかりません" と警告を受けて不可なのであった。
　もはやお手上げ状態かとあきらめかけたものだった。で、しかたなく、 "Copper Reader" のベンダーサイトを覗くことにした。以下のような解説がなされている。

　昨日立ち上げた "Android SDK エミュレータ" を早速使いこなそうとあれこれ試行錯誤をしてみた。
　関心を向けている点は、"iPod / iPhone / iPad" 向けでこの間行って来た "ePub 電子書籍" 制作に関する種々の経験ノウハウが、"Android" 系の "携帯・端末" 向けの場合には、何が共通していてどこがどう異なるのか、またどんな伏兵が潜んでいるのか、そうした点を調べることである。"ePub" 仕様は、"汎用性" が目指されているため、共通する面が少なくないはずだとの読みはしているものの、やはり実体験的な確認が欠かせない。

　それはそうと、先ずは "Android" 系の "携帯・端末" に馴染んでみなければ何も始まらない。しかも、その "実機" が手元にあるわけではないために、ＰＣ上での "Android SDK エミュレータ" を代用しようと事を始めたわけなのである。
　それにしても、この "エミュレータ" はその動作がかなり "重く" て扱い辛い......。まさか、スマートフォンに適用されている "Android" システム自体がそうした性格なのだとは思えないが、それにしても "重い" ......。
　日頃常用しているノートＰＣは、"CPU 1.79 GHz、 2.62 GB RAM" であり、ちょっとした開発作業であってもさほど苦にしていない。だが、この "エミュレータ" を動かしてみると、たっぷりとストレスを感じさせられたのだ。"メモリ" の "割り当て" 設定がどこかにあるのかもしれないが、今のところ了解していないので、その動きのたどたどしさ、纏わり付くような動きには閉口させられた。
　そこで、思い切って、やや性能の良いＰＣ（ "CPU 3.00 GHz 1.99 GB RAM" ）環境へとこの "エミュレータ" を移動させなければならなかった。幸い、こちらの環境では、サクサクとまでは行かないまでも、ようやく順当な操作が可能となったのである。

　と言っても、未だ正体が分からないにもかかわらず、"アンドロイド携帯" を "買っちゃえ！" というほどせっかちな人は先ずいないだろう。

　そこで、ちょいと気の利いたユーザーならば携帯などには "エミュレータ" というＰＣ上で "疑似デバイス" として動くシミュレータなるものがあることに目を向ける。

　現に、"アンドロイド携帯" には "Android SDK エミュレータ" というものが用意されている。
　そこで、"アンドロイド携帯" への好奇心が向かった先は、この "Android SDK エミュレータ" をＰＣ上で実行してみるということであった。

　＜鈴木貴博の「舞台裏から分析！流行のメカニズム」 アンドロイド普及ツールになりかけている「iPod touch」/NIKKEI TRENDY NET/2011年03月28日＞という記事は、"携帯端末" 市場動向の状況における "微妙な皮肉(?)" を、興味深く紹介するものとしておもしろく読ませてくれた。

　個人的に言っても、かねてより "iPod touch" には人一倍関心を寄せ興味津々で愛用して来た。それでいて "携帯電話" の方は相変わらず "ドコモのユーザー" に旧態依然として留まっていた自分としては、「フーン、ナルホドねぇ......」という "微妙な心境" にもなっているのである。

　"iPod touch" が気に入っているのなら、 "携帯電話" の方も速やかに "iPhone" のユーザーに移行すればいいじゃないか......。それが、"iPod touch" を "iPhoneの補助輪" つまり、 "iPhone" ユーザーへの "橋渡し役" と豪語したスティーブ・ジョブズによる「補助輪」論の "教え(?)" のはずであっただろう。

＜外見はiPhoneとよく似ていて、最新の第4世代は（1）電話がない、（2）GPSがないということ以外はほぼiPhoneと同じことができる。つまり、音楽やビデオクリップ、写真や動画撮影を楽しめるだけでなく、iPhoneアプリをダウンロードしたり、ゲームしたり、電子書籍を読んだり、無線 LAN経由でインターネットにつながったり、メールをチェックしたりと、およそスマートフォンユーザーがやりたいことは、iPod touchでも大体できるのだ。iPadと違って、iPod touchなら産経新聞も無料で購読できる。価格も8GBで2万900円からと、iPhoneよりも手ごろである。＞(前述サイトより)
＜図式にすれば、（1）スマートフォンのアプリが増えて利便性が向上→（2）まずiPod touchを購入して、アプリを試す→（3）便利だとわかる→（4）スマートフォン購入を検討する、という手順になる。＞(前述サイトより)
という流れで......。