Archive for 12月, 2010
2010/12/23
IS03でepub形式の電子書籍を電車で眺めながめる生活を数日送ってみて、改めて電子書籍について考えてみた。
１つは、やはり電子書籍をすべてIS03のようなスマートフォンですませるにはきついということだ。
でも、やはり960×640というサイズ（高解像度）は正解だったと思います。
（ほかの端末ではサイズが小さいような・・・・）
しかしながら、IS03で本気で読もうという気はおきない。（まあ、見ている本がオライリーですから・・・）
それに、PDFのドキュメントはまず、小さい端末では見る気にならない。
スムーズにズームや移動ができるからと言って、「おーすげー」とはなるが、
はっきり言って、読むことを考えると横書きで下の文字が見えているのに、右が見えないなんてありえない。
でもって、ズームや、スクロールを１画面でしていられるのは、せいぜい１，２枚が限度だ。
と考えると、PDFを読もうと思ったらある一定以上の物理的な大きさはやはり必須だ。
もしくはPDFはあきらめるか・・・・
スマートフォンみたいな小さい画面で見るためには、やはりページの概念が必須となるフォーマットはきつい。
とこれらを考えたうえで、iPadか、GALAPAGOSのタブか・・・・、それともまだかと考えてみる。
そうすると、改めて「書籍」とは何かということを考えさせられる。
私も仕様書を書くときには、そのページが右のページにくるのか、左のページにくるのかを最終的には考える。
ある程度の区切りはやはり、必ず左のページから始まるし、面倒でややこしい説明も左のページから始まる。
このような私レベルでも文章を書いている側からすると「右」か「左」かは絶対大切な物である。
それが、出版のプロともなればもっと意味は重くなるだろう。
一方、紙ではない「電子書籍」では「右」も「左」もない。
というか、読み手からは強く「右」と「左」を意識された電子書籍は読みづらい。
そして、先ほど画面のズームやスクロールなどは使いづらいので、結局は「フォント」のサイズ変更になる。
この場合には「右」「左」どころか、「ページ」がないわけだ。
だから「ページ」の概念を持ったフォーマットは電子書籍としては使いづらい。
ようはPDFだ。
こう考えると、先のGALAPAGOSは消えていく。
まあ、GALAPAGOSはXDMFというフォーマットなのですが、このフォーマットが実際どのようなものなのかはわからないのですが、
売り文句を見ていると、どうも読み手のためのフォーマットというよりは、作り手のためのフォーマットという気がします。
そして、いまあるドキュメントは結局、PDFしか選択肢がない。
あえて言えば「電子書籍」ではなく、「電子雑誌」なのではないでしょうか？
epub形式をXDMF形式に変換する方法も今のところ私には見つけられませんでした。
（印刷というレベル、つまり画像データとしてXDMFにするのではなく、文字情報として変換という意味です。）
結局、「（小説のような）書籍」が売れるとはまだ考えられていないのか、それともそれらはSony Readerのようなものでしょ。
ということなのか・・・
このあたりにマーケットの狭さの限界を感じてしまいます。
GALAPAGOSがいったいいつepubもサポートしますよということを言い出すのか・・・
（というより、いつこれって結局Androidですよ。というのか？）
言えば、新鮮みが薄れるし、言わなければ、いずれ汎用タブではサポートしだすので、そのときの優位性が・・・・
んー、何かよいものはないのか？
一度、Kindle DXの実物を見てみたい。。。。
Sony Readerにももっとおおきなサイズはないものか・・・・・
まあ、まだまだのような気もする。
ただ、ちょっと横道にそれるが技術者としての電子書籍の提供者としての使い方を考えてみると・・・・
社内において存在するドキュメントを電子書籍みたいに本棚（ちっくなUI）にならべてくれればいいのにとは思った。
社内規定は「赤」とか、マニュアル・手順書は「青」とか・・・
こんな電子書籍CMSなんてのもあっていい気がする。
まあ、書く方もドキュメントをエクセルに書いているようでは、仕組みがあってもついていけないが・・・・
Posted in 
2010/12/21
前回、オライリーの電子書籍アプリを購入してみて、epub形式にexportできるものとできない物がありました。
これをいろいろと調べてみると、アプリのファイルをzipとして解凍して、epubファイルのデータだけを取り出して、再度zipにすればよいとまでわかりました。
http://oreilly.com/ebooks/oreilly_iphone_tips.csp
の一番下に書いてあります。
で、そのためにはインストールしたアプリのapkファイルが必要になるので、
それはappMonsterというツールを使いました。
こちらのツールは、検索すればいろいろ出てくるので省略します。
でもって、これを解凍して・・・・ファイルを探して、再度zipして、epubに拡張子をかえてってのが面倒なので、AIRのアプリを作ってみました。
をインストールして、画面にロゴが出ますので、そこにapkファイルをドロップすると同じディレクトリにepubファイルが作成されるようにしてみました。
といってもたいしたことはしていませんが・・・・
2010/12/17
Androidを買ってこれは「いいぞ！」と思ったのが、この表題の件です。
最近話題になりつつある電子書籍ですが、
Androidマーケットでは洋書になってしまいますが、オライリーの本が約400円で売っているのです。
ちなみに、サイトで購入すれば$39.99となっています。（いろいろなデバイスに対応できますが・・・）
約 1/10の価格です。
洋書といえばAmazonですが、
という感じです。
実は我が家ではこんな話とは別に本棚がいっぱいになってしまい、もう本が入るスペースがなくなってきているので、
本を買うことができなくなってきているところへ、これは朗報です。
こんな感じにそこそこあります。
試しに、JavaScriptの本を買ってみました。
ただし、オライリーのサイトではeBookとして売っているのに、こちらにはないものもあります。
本と言えば、「紙」の方がいい気がしますが、
英語ですし、そして何より技術書ですから、初めから、最後までよむというよりは必要なところだけをピックアップして読んでいくという感じになるので、
紙よりはデジタルのがいいかもと思っていたところです。
（個人的に、日本語はやっぱりまだ紙のほうがいいです。内容を文字だけでなく全体の中の位置でも覚えているので・・・）
ただ、確かに小さい端末では本当に大丈夫なのかなと思ったのですが・・・
これが、epub形式にexportできるのです。
こんな感じです。
うっすらと下に本文も見えているように、あまりぱっと全体がわからないのでサンプルソースなどは厳しいですが、
epub形式にしてしまって、それをPC上から見てしまえば、そんなの関係ありません。
ちなみにepubという形式を読むにはAdobeの
http://www.adobe.com/products/digitaleditions/
というツールで見ることができます。
Firefox のextensionでもあるようなのですが、断然こっちの方が見やすいです。
ということで、この程度の値段ならばちょこちょこチェックして、こちらを買った方がいいかもと思いました。
ちなみにこのepubというフォーマット、html（のようなもの）をzip圧縮したものです。
なので、拡張子を変えて解凍すればブラウザでもそのまま見えます。
・・・と思ったのですが、どうやらExportできるものとできないものがあるようです。
Aldikoを見ると大丈夫なきがするのだが・・・・
と最後に歯切れが悪くなってしまいました・・・・
2010/12/12
今回は、Opera Mobileというブラウザを導入してみました。
というのも、WiFiじゃないときになるべくWEBのアクセスを軽くしたいなと思っていたからです。
要は、URL Filterをかけて広告などの画像やアクセスはしないようにしてしまえ！という事です。
これで見たくない画像の為に、時間もお金も節約できるという訳です。
このあたりは、最初から入っているブラウザじゃできないと思います。（たぶん。）
それ以外に、Opera Mobileはいろいろな設定ができるようでMobileではよいかもしれません。
ちなみに、OperaはAndroidマーケットから探してインストールしてください。
で、インストールしてブラウザを立ち上げて、URLに
opera:config
と入力すると、
のような画面が表示され、メニューから設定できる以上にいろいろな事が可能です。
それで、Network という項目を探してクリックすると以下のような画面が見れます。
ここで、URL Filter Fileという箇所で、あらかじめ作成しておいたファイルを設定します。
ちなみにどのような設定記述ができるかと言えば、
http://dev.opera-wiki.com/URL_Filter_List/ja
のような感じです。
これだけだと、最初はよくわからなかったのですが、以下のようにしていけばよいようです。
[include] * [exclude] http://*.ad.* http://*.ads.* http://*.ads2.* http://*.adv.*
あとは、[exclude]にサンプルにあるようなURLを付け加えていけばOKです。
これで保存を押して、再起動すれば問題無いと思います。
それほど大変ではないのですが、最初はよくわからなったので、同様によくわからない方はPC版でもあまりかわらないようなので、
PC版で設定した後に、そのファイルをコピーしていけば大丈夫だと思います。
また、これとは直接関係がないのですが、ここで「選択」というボタンで、
のように、Androidのディレクトリ構成やらファイル構成が見えたりします。
ちょっと中身がどんなかんじか見てみたいな－という程度で、SDKを入れずとも簡単に見えるのは副産物としておもしろそうだなとも思いました。
あとは、Proxyなども設定できるようなので、WiFi接続でProxyでの接続が必要になってしまう場合には使えるのかもしれません。（といっても私は使っていないので、わかりませんが・・・）
通常のブラウザはそのまま残したままでこのような対応ができるので、第2のブラウザとしてインストールしておくのもよいかもしれません。
2010/12/10
さて、今日でIS03を使って4日目です。
ちょっと、アプリを使っていてAndroidのアプリはこの辺が大変そうなんだな・・・・と思ったので記録しておきます。
アプリを使っていて、思ったのがログイン画面が多いこと、多いこと。
たとえば、mixiのアプリ。
使い始めるのに、ログインがいります。（もちろん、その前に登録もいりますが、これはすんでいます。）
そして、アプリ内でマイミクの日記のサマリーが見えます。
ここまでは、なんの問題もいりません。
しかし、詳細を見ようとすると今度はブラウザが開きます。
すると、また、ログインが出てくるのです。
見終わると、ブラウザを落とします。
（この辺は盛んに電池がもたん、もたん・・・といろいろと騒がれているので、ついついこちらも落としてしまいます。）
で、また、ちょっと時間がたって、あーこれみようと思うと・・・また、ログイン画面。
いろいろなところで、勝手にブラウザと連携するのはいいのですが、そのたびにログイン画面。
なんか、操作を間違えているのか、どこかおかしなボタンを触ってしまっているのか、
それとも、ほかの原因なのか、
さっきまでブラウザでログインして見ていたのに、また、ログイン画面。
これでは、ちょっとげんなりです。
ただ、そうなってしまう作りも、同じ作り手としてはよくわかります。
アプリとブラウザのセッションの連携は結構難しいものです。
アプリはローカルにデータをキャッシュしているので見えるので時間がかなりたった後でも、情報は見えます。
当然、利用者もデータは隠されていますので、アプリを通してサービスを使っている気になります。
でも、実際にはローカルファイルを見ているだけなのですが、いざ、ローカルにないファイルを見ようとすれば、
サーバに接続しにいき、そこで、あの「ログイン」画面です。
覚えさせておけばいいのですが、まだ、新しくまわりも興味津々なわけで、ちょっと見せてと言ったときに、
簡単にこちらの情報が見られてしまうのもいやですから、必ずログインが必要なようにしておくわけです。
ということで、作り手の理屈と、使い手の理屈の妥協ラインがまだとれていないような気もします。
このあたりはAndroidというまだまだこなれていないためなのかもしれません。
ブラウザならブラウザ、アプリならアプリと割り切って作ってあった方が使い手にとって、使いやすい部分もあるのですが、
まだ、目新しいことも価値の一つなので、そのあたりはちょっと難しいかもしれません。
iPhoneはどうなのでしょう。このあたり。うまくできているのでしょうか。
一方、これをなるべくなくと考えているのか、それがjibeのような気もします。
私はTwitterとか、jibeのjibeらしい使い方ができないのでなんなのですが、
こちらもログイン問題もあるのはあるのですが、うまく連携を考えているせいか、
今度は、連携先の機能のサブセットがちょっと小さいのです。
要するに、Androidの「Intent」の機能を消しすぎな気もします。
だから、「あれ、これができないんだ。（もしくは見つからないだけかも・・・）」と言って、Jibeを落として、Jibeの接続先のサービスのアプリを使いだすわけです。
もちろん、ここでも、ログインが再度発生してしまう訳です。
こう考えると、キャリアの公式サイトの認証はまあ、現実解としてはまあまあだったのかなとも思います。
事実上のログインIDが共通というのもどうかと思いますが、どうせ、課金関連で個人情報は最低限とられているわけですから・・・・気にしても仕方がないところもあります。
となると、シングルサインオンの仕組みがほしくなってしまうわけですが、
そうなると、当然、強力な候補がいるわけですよね。Googleさん。
いやー、Cookieといういわば匿名情報を使ったターゲティングから、
シングルサインみたいな、利用者からの能動的な通知でのターゲティングに変更できるじゃないですか・・・これは。
まあ、このあたりも取捨選択されて、アプリですべて完結できるまで作り込みが終了すれば、解決する話ではありますが・・・
時間の問題ということでしょう・・・・・
まだ、騒がれて間もないわけですから・・・・
2010/12/9
さて、IS03を使って三日目。
画面が大きくていいです。そしてきれいです。
CMでiPhoneだったらえくぼだってとやっていましたが、
そのCMがどの程度すごいのかの意味がよくわからないレベルで、
写真もすごくきれいです。字もきれいだと思います。
ほかと比べていないのでわからないのですが・・・
はっきり言って電池は確かにきびしい。
まあ、開発者向けですね。電池のもちが悪いというのは携帯アプリを作る上で必要だと思いますし。
（電池のロスがないように作るようになるということです。）
でも、今まで週に１，２回しか充電していなかった携帯と比べれば、
どれもドングリの背比べのようにも感じます。
使い方も多少わかってきました。
前回、ローマ字入力でローマ字入力なんだから、使わない（使えない）キーの反応はやめてくれよ。
という話も、
「設定＞言語とキーボード＞iWnn IME＞ローマ字キーボード補助」
という項目で設定ができました。
まあ、このあたり使い方には慣れの時間が普通の携帯よりはかかりそうです。
さて、見た目の使い勝手などはさておき話はAndroidの中身です。
そこで、あまり使わなさそうだなと思うサービスもあえて使ってみることにしました。
気になるサイトがあったので、URLをコピーして・・・ってことをしたかったのだが・・・
わからない・・・・・そして、今でもできない。。。
そして、いろいろ見ているうちに、ブラウザに「ページを共有」という機能があった。
あー、こうやってメールとか貼り付けるんだ・・・ちょっと使いづらいかも。。。。なんて思っていた。
そして、evernoteをインストールしてみた。
evernoteを使おうかなと思ったが、ちょっと？？？という感じであったが、
同じように、また、「ページを共有」を開くと、
今度は「あれ、Evernoteってのが追加されている」
ちょっとプログラムチックに考えれば、「コンテキストメニュー」に勝手に追加されたぞ。
これはどうやってやってるんだ・・・・
どういうAPIなんだ・・・
と調べていくと、これがよく出てくる「Intent」なのだと。
これが、iPhoneになく、Androidの特徴らしいのだ。
（Intentがわかれば、Androidがわかるとくらい書いてある本もある。）
この機能故に、エディタ機能しかないメモアプリも、メールのエディタになれるのだと。
これを見ていて私は、「あーこりゃpipeだな」と思いました。
cat foo.txt | grep -v fogefoge | mail -s “foofoo” hogehoge@coltware.com
みたいな話ですよ。
ファイルを開く機能と、本文を編集する機能と、メールを送信する機能はすべて別のコマンド（アプリ）で実装できるよと。
別に、grepが問題なら、awkでもsedでも、自分で作ったっていいですよ。
送信先が、mailじゃいやなら、curlとか使ってhttp通信にしてしまってもいいですよ。
さらに、httpとかで返ってくれるレスポンスを受けて、mailに流してもいいと・・・
catがいやなら、sqlでもいいですよ・・
組み合わせや、順番がかわるだけでかなりいろいろなことができます。
そして、１つ１つの動きはすごくシンプルです。
シンプル is ベスト、 スモール is ビューティフル です。
こんな考え方でUnix(Linux)はできています。
足りなければ、こうやってパイプをつなげてどんどん大きくしていけばいいだけなのです。
これをGUIの世界に持ち込んだんだなと技術的にはそう思います。
この考え方の利点がわかる人はかなりunixライクな人だと思います。
Windowsではないと思いますよ。
iPhoneも、こういった小さいプログラムの連携ではなく１つのアプリとして完結するのですよね。
（だから、マルチタスクでなくてもＯＫだった訳ですが・・・）
でも、Windows vs Linux , iPhone vs Android
どちらも、一般コンシューマ市場において勝者は知っての通り。
小さいアプリの結合って美しく、便利で、堅牢性があるが、使い方が高度だし、結果を第三者が保証することができないんだよね。
だから、結局はプロ向けにしかならない。
まあ、それでもAndroidはおもしろそうでチャレンジングなOSだとおもいます。
私が、JBoss nettyを使っているのも、そういったpipelineですべてを作っていきたいからなのですが、
かなり、自分の思考とはあっています。
まあ、実は未だに古きJCLの概念が好きなのです。
と、技術的な話もさておき、そもそもなぜこのような仕組みにGoogleはするのか？
というところにも興味があります。
パイプラインには、リピータという来た情報を変えずに、そのまま次に送るという機能があります。
もともとは、物理的な回線の信号などが弱まったのを強めるのがその目的だと思うのですが、ことソフトウェアになると違います。
送り出すアプリにも、受け取るアプリにも意識されずに間に挟むことをするのです。
なので、いつだって処理が面倒で必ず必要な「ログイン」画面が簡単にはさめるという訳です。
とこれは作り手が作りやすいですよという話でいいことではあるのですが・・・・
でも、Googleがわざわざやるからには・・・・と考えると
商業的には「広告をはさみたいんじゃないの？」と思ってしまいます。
電話がかかってくると、その電話をとる前に広告主である競合の広告がポップアップされますとか・・・
新しい概念が出てきても、OSレベルでイベントをとられちゃ・・・
ロングテールっていうか、もう毛細血管のレベルで張り巡らせれているよってきもします。
今は広告を挟むのに作り手の協力がどうしても必要になってしまいますが、
これがうまく機能しだせば、作り手の意志とは関係がなく広告を挟めるようになりますからね。
そのうち、映画の作り手とCM側との間でトラブルがあるように、アプリの作り手と広告側の間でトラブルがあったりして・・・・
2010/12/8
さて、自分のサイトを自分のIS03で見るのが面倒だということで、Wordpressのプラグインを使って、スマートフォン対応をしてみました。
そこで、WPtouchというプラグインをつかってみました。
しかし、便利です。
こういうあたりが、CMSなんかよりもブログシステムの方が便利なのかもしれません。
画面からのプラグインインストールというボタンだけですんでしまいますし・・・・
プログラムのところはさすがに、激しく改行されてしまっているので決して見やすいとは言いませんが、
それでも、ちゃんと色づけされてますし、まあ、見て見られないことはないというレベルでしょう。
ここまで、自動でやってくれれば今のところ言うことなしというレベルではあると思います。個人的に。
2010/12/7
IS03を発売後、店頭でちょっと触ってみて、そして、Androidで何ができそうかな・・・・
と思いつつ、11/30あたりに予約をしてみました。
まあ、当分届かないとあるし、それまでにいろいろ見てみるか・・・とおもいつついたら・・・
予約しても、キャンセルすればいいし・・・と。
そしたら、昨日さっそく、届きましたと。
「あれ？年内は厳しい」なんて言っていたから、どれだけまつ必要があるんだ。
まあ、いいか、逆にそれまで時間もあるし・・・と思っていたのに。
で、よい点も、悪い点もふくめて気になった点。
１）店頭での注意点。
アプリをいれておかしくなっても、故障あつかいの修理になるよ。
これは、結構一般ユーザにとってはきつい一言ですよ。
それを言われて、じゃ安心してアプリを入れられますね。とは思いませんから。
結局は広まるためには「プリインストール」のアプリがそろってからということでしょう。
このあたりは、PCは自由にカスタマイズできます。という文句と同じです。
いれればメーカーに質問しても「？？？」ばかりになるので、出荷時のアプリ以外使わない。
iPhoneは知りませんが、審査が厳しいのでこのあたりのいいわけ文句を言われることはないのかな？
２） ローマ字入力は打ちやすい。
携帯の、数字を何度も押して文字を決定していく・・・という方法確かに不便でした。
だけど、ローマ字入力にして両手で打てるので確かにかなり文字が打ちやすくなります。
でも、ちょっと希望を言えば、ローマ字としてあり得ない綴りがないような配慮もしてくれると助かる。
母音＋子音になっているのだから、母音がきたら、子音としてのあり得るケースが多少絞れるのだから、
ボタンの反応ぐあい（ゲーム風にいえばあたり判定？）を変えてくれたら、もっといいのだが・・・・
３）ボタンの打ち間違いが激しい
iGoogleのスマートフォン用のページでさえボタンが・・・
gmailのアプリも・・・
入力しやすくなったのはよい点だが、入力間違いも多くなりました。
結果的に早くはなっているかもしれませんが、ボタンを押している回数はあまりかわらないのかも・・・
メニューで、アコーディオン形式をよくみかけるのですが、詳細でボタン・リンクが下に表示されているので、
まちがって、次のアコーディオンなり、記事にいってしまう。
このリンク、右なり、左に大きく表示してもらえると助かります。
４） WiFi接続はいい
落ち着いてつかうところは、家、喫茶店。などと考えれば、3Gの通信の遅さは気にならない。
そして、WiFiの早さは確かにいい。
PCのように無駄な情報がたくさんこないので、余計早く感じるのかもしれない。
私はYouTubuも見ないのだが、これならちょっとした時に見る気にもなるのかもしれない。
５）Jibeがよくわからない
いろいろなサービスを横断してくれるみたいので、登録してみたが、
さいど、いろいろなサービスを使うにはログインが必要。
でも、アカウントをもっていないと当然ログインができない。
でも、アカウント作成画面にはいけない（と思う。わからない）
これも、今はディープなユーザによってそれぞれの機能を使われているので、これはこれで利用者の利便性を考えているのだと思うが、
私は、１つのアカウント登録ですべてが使えるのだと思ってしまった。
これから使う人は、すべてのサービスにそれぞれ行き、そしてアカウントを登録し・・・Jibeに登録し・・・・
という使い方は想像できない。
これも、本当にスマートフォンが一般利用者に広まったときに、これらのサービスを統合的に使えるサービスに乗り換えられてしまうにちがいない。
もしくはそれほど使われないだろう。
まあ、もうちょっと使っていると感想もかわるかもしれないが・・・
2010/12/6
TextLayoutFrameworkを使ってエディタを作成するのと、
HTMLを使ってエディタを作るのではどちらがいいかと思っていました。
まあ、たいしたエディタでもないのでどちらでもいいのですが、
より自由にやりやすそうなTextLayoutFrameworkを試していたのですが、
画像のalign(float)がサポートしておらず。。。あれれ。。。
これは面倒だなというように思っていましたが、Flex4.5を試してみたら、
var img:InlineGraphicElement = new InlineGraphicElement(); img.source = url; img.float = "right";
のようにfloatがつくようになっていました。
これでメーラのエディタはようが足りそうです。
いつも悩むのが、待つべきか、作るべきか・・・
今回はあまり深く突っ込みたくないところだったので、待っていましたが、
よかった。よかった。
これで、テーブル見たいのもサポートしてくれれば、かなりベター。
2010/12/5
AdobeのAIRもAndroidに対応していきそうですし、ちょっと前知識でもつけておこうかなと思い始めました。
といっても、まだソースも書いていませんし、サンプルコードも見ていません。
単に、Androidの仕組みというか、関連情報を見ているだけです。
あとは、アプリのカタログ。
これを見れば何ができるか雰囲気がわかります。
AndroidのアプリのコードはたいていJavaで書かれていますが、
JNIというネイティブとの連携についてちょこちょこと書かれていたりするんですが、
そこで、改めて思ったことが、AndroidはLinuxなんだ。と。
そして、その領域まで触ってよいのだということ。
そう思うと、ちょっと、AndroidアプリをAIRで作ってしまうのはちょっともったいない気もしてきました。
だから、Linux上での蓄積されたライブラリなんかもつかえるのかと。
JNIは2000年くらいにやったなー。Javaでライブラリがない、もしくは使い方がわからないと、
JNIで作ってしまう人がいて、それを見ていたものです。
今更ながら、「あー、別にPure Javaでなくて、JavaとCをくっつけてやってもいいな」と思い始めました。
そうすれば、かなりいろいろな制約に悩まされずにいろいろなことができそうです。
ただ、AIRも、Java(別にCでもいいが・・・）とくっつける方法があるとよいと思います。
あとは、Androidのちょっと面白いプロセス（アプリ？）管理。
終了とは必ずしも、プロセルの終了とは言えず、開始とはかならずしも、プロセスの開始とは言えずと。
電池とメモリを考慮するとこうなるのかと。
だから、強制的にアプリを完全に落とすなんているアプリがノウハウとしてあるのだと。
だから、JNIでライブラリをロードする処理に気をつけなければならないのかと。
まあ、携帯電話上のWEBアプリもどきではなく、電話アプリも作れるので確かに面白そうです。
メールもSMSをトリガーとしてPUSHイベントの通知みたのがあるようで・・・・
このSMSトリガー。ほかにもいろいろなところで使えそうです。
