「iPhone」タグアーカイブ

2010-10
26
00:40:55
Titanium mobileが盛り上がっているようで何よりだ


実はしばらく前にTwitterのTLで流れてたのを見て触りだしてからはまっていたので、最近の盛り上がりは嬉しく思います。なんたって一時期は日本でTi mobile使ってるのは数人ぐらいしかいないんじゃないかとか思ってたぐらいなので。
へえまだアルファブロガーっているんだぁと思った次第。

実は既にそれなりにまともなiPhoneとAndroidアプリをTi mobileで作ってそれぞれAppStoreとAndroidマーケットで公開していたりします(本名で出してるからここでは紹介しない)。
ということで僕も別にそんな経験あるわけではないけど使っていて感じたこととかつらつらと書いてみますよ。

因みにTi mobileの日本での先駆者と言えばまとめサイトも作られてるdonayamaさんとかyuichi_katahiraさんとかですかね。また Yuichiro MASUIさんはAdMob用など幾つかiPhoneモジュールを公開されていらっしゃいます。

iPhone版は優秀だけどAndroid版は発展途上

僕の経験で言うと一週間でiPhoneアプリは出来てしまったんですがそこからAndroidに対応させるのに二週間かかりました。原因はAndroidでのバグ?らしき挙動とiPhone版さの差異のためです。
iPhone版は非常に優秀でJavaScript好きの人ならさらさらと簡単にアプリを作れてしまうと思います。ただそれと同じつもりでAndroid版に拡張し始めると要領があまりに違っていてかなりはまりました。
例を挙げると、何故かiPhoneでは当たり前に取得できるresponseXMLがAndroidではRSSフィードによっては文字化けしたり(結局最後まで原因はわからず、responseDataを使ってパースした)、windowのxIndexがwindowのlayout指定によって順序が異なったり、WebViewで取得したHTMLは外部からは取得できなかったり、windowのblur/focusイベントは動作しなかったり・・などなど。
「iPhoneとAndroidでは画面サイズとかが異なるからコードを分けないといけなくなる」程度の話が流れていますがそれどころではないです。僕はかろうじて同一レポジトリに閉じ込められましたが、現時点ではコードの規模によっては別々に開発することも考えた方がいいこともあるでしょう。
Titanium Developer製品(Ti mobileはその一環)はOSSで開発が進められているのですが、チケットを見てもAndroidのissueは多いように見えます。
まだまだ開発途上の製品なのでそれにうまく付き合えるかどうかがポイントになります。

iPhoneとAndroidのJavaScriptの解釈が異なる

恐らく先のAppleによる「AppStoreからの開発ツールの締め出し」騒動に関係していると思われますがiPhone版ではコンパイル時にネイティブコードに変換します。対してAndroidではJSエンジン(恐らくGoogleのV8?)でリアルタイムにインタープリターもしくはJITで実行しているようです。つまり解釈されるエンジンが異なるのです。これが前項の原因でもあり、また両者での違いを経験から読み取っていく必要があるでしょう。

メモリ管理しなくてもいいということはメモリ管理できないということ

僕もTi mobileを一番気に入っているのはメモリ管理を気にしなくて良いと言うこと。特にiPhoneでは顕著ですよね。しかし一方ではそれはメモリリークなどの管理をできないということも意味します。
開発元のAppceleratorでは「メモリリークはうまく回避しているよ」と言い切っていますが 実際に試してみると細かなメモリリークは発生し得るようです(特にネットワーク周り)。
あまり問題にはならないレベルとは思うのですが、JavaScriptに書き慣れていないとGCを意識できずオブジェクトを残し続けてしまいがちです。ブラウザでもよく話題にはなるのですがかなり巨大なコードにならないとあまり気にしない部分かと思います。しかしTi mobileではGCを意識した変数設計をしておかないと簡単にメモリを食い潰すアプリができてしまいます。
こういう時は逆にGCに頼るのではなく自由にメモリ管理も出来る仕組みがあるといいですね。

ドキュメントを信じるな、アンドキュメントな仕様が多すぎる

これはAppceleratorが基本的にはOSSで無償で提供しつつビジネスとしてサポートを有償にしていることと関係していると思うのですが、ドキュメントがあまりに杜撰です。
そもそも返値とパラメータが全く異なっていたり(多分コピーミスなど)、ドキュメントだけではちょっと複雑な仕様を実装しようとすると悩むことが多いかも知れません。
他の方もおっしゃっているように、APIドキュメントよりもサンプルアプリであるKitchenSinkを最大限利用しましょう。特にiPhoneとAndroidの実機に実際インストールして動作を確認することをお勧めします。
またドキュメントはあまり参考になりませんが、ディスカッションフォーラムは割と参考になることが多いです。凄く盛り上がっているとは言えないけど みんな同じ事で悩んでいるのです。

拡張モジュールを作るならObjective-CとJavaは知っておいた方がいい

Ti mobileでもiPhoneとAndroidのすべての機能に対応しているわけではありません。また世には様々な便利なライブラリが公開されていますが、当然それらはObjecive-CやJavaで書かれています。Ti mobileにはそれらネイティブコードを取り込むための「モジュール」という仕組みが用意されているのですがそのためにはObjective-CやJavaでもコードを書けなければなりません。更に言えばiPhoneやAndroidでどのようにアプリを開発するかの知識が必要です。
因みに僕は広告を掲載したかったのですが当然Objective-CやJavaのライブラリやサンプルしか提供されていないので、独自にiPhoneとAndroid用にモジュールを作成しました。広告程度なら表示するだけなのでそんなに難しくないです。但しiPhoneやAndroidの経験がないとかなり難しいと感じることでしょう。
なのでTi mobile自体は単に「Objective-CやJavaを知らなくてもJavaScriptを知っていればiPhone/Androidアプリを作れる」ツールなのではなくて、まずはやはりiPhoneやAndroid開発をある程度経験してからの方が相応しいツールなのではないかなぁと思います。

最後はコードを読もう!

先に述べたようにTi mobileはOSSとしてすべてのコードが公開されています。実際現時点でのコードをgithubから取得して自分でコンパイルして使うことも出来ます(Androidの拡張モジュールはそのようにして開発します)。
なのでどうしてもバグなのか仕様なのか回避のしようがなかったら最後はコードを読んでみることをオススメします。
個人的な例では、どうしてもAndroidの実機で位置情報が取得できない問題がクリアできなかったのですが、コードを読んでみるとgetLastKnownLocation()のみで取得していることが分かりました。これは時々ディスカッションでも話題になっていますが初回には位置情報は取れないのです。
ということでプロバイダーをNETWORKにして回避したのですが(これはこれでどうかと思いますが)、こういう部分もOSSとして提供されている利点であり、活用しない手もないでしょう。

といったところでしょうか。
何やら文句と愚痴が多くなった気もしますが(笑)、個人的には大変気に入っています。特にJavaScript好きには堪らないツールとなることでしょう。
一方で「初心者でも簡単にiPhone/Androidアプリが作れる」風のイメージには疑問を感じていて、どちらかと言えば現時点でiPhone/Android開発をバリバリされてらっしゃる方にこそ効率を上げるためにぜひオススメしたいツールです。
まずは使ってもらって、少しでも日本で広まるといいなぁ。

2010-03
30
01:11:50
結局SIMロック論議もオープンプラットフォーム構想も端末IDの話に尽きるのかも知れないなぁ


総務省がSIMロックの解除要請の方針を打ち出したと言うことで少し話題になっている。

携帯端末、全社対応型に 「SIMロック」解除要請へ

個人的な立ち位置を先に表明しておくと、僕は「SIMフリーも選択できるようにして欲しい」という立場。別にSIMロックを前提にしたビジネスモデルがあってもいいけど、ビジネスモデルを阻害するというキャリアの身勝手によって消費者がSIMフリーを選択できないのは問題だ、ということです。
「果たしてSIMロックがガラパゴスの元凶か」というのも論点になっているがそれは後として、 面白い論評をソフトバンクモバイル副社長の松本氏が述べているので先に簡単に触れておきたい。

携帯電話におけるSIMロック論争 – 松本徹三

皮肉なことにこの論評が述べているのが実は「キャリアがSIMフリーを排除したい」理由にもなっているという点だ。特に自身らのビジネスが如何にSIMロックを前提にしてしまっているか、気付いてか気付かずにか、大変に分かりやすく説明されている。

中段のさて、ここで問題の核心に入ります。というところまではいいだろう。ここまではまあまあ僕の上記の意見とも実は合致していて、「SIMロックもあればSIMフリーもある状況なら受け入れられる」という結論もまあ妥当だ。
しかしここから何故か「如何にSIMフリーは悪か」について説明が始まる。なお氏は「SIMロック解除がすべての端末で強制されれば」の前提で書かれているようだが本質的には「SIMフリー端末がキャリアに与えるインパクト」とも読み取れる。また先の読売の既報によれば契約から一定期間が経過した端末に限るとされている。
氏の論に依れば、日本のキャリアの端末・サービス・ 通信回線が三位一体で始めて現在のサービスが提供できるのだという。そしてそれが伴わなければ(1)各端末メーカーの互換テストが大変になる(2)キャリアにより使えないサービスが出てくる(3)3GよりWi-Fiを優先するなどの通信帯域を必要以上に使わない仕様に端末をしてもらう必要がある(4)端末助成金が無くなるので高くなる(5)(自由に使えると)不正に入手した端末の犯罪利用が増える のだそうだ。
しかし一読してもこれらを「SIMフリーが行えない」理由にするのは氏の立場を考えてもおかしいだろう。
まず(2)(4)は完全にキャリアの都合の話だ。キャリア間で互換性のないサービスを作り出してきたのはキャリア自身だ。また助成金はキャリア自身が生み出した仕組みだ。それをフリー化できない言い訳にすり替えるは厚顔無恥としか言いようがない。また(1)(3)も、では何故御社ではiPhoneを提供できているのだろう。そうであればAppleはiPhoneの計画段階からSoftbankにパートナーを決めていてテストを繰り返していたことになるが事実だろうか。決してそうではあるまい。更に言えばではこれらのことが他のSIMフリーを導入している国で問題になっているのだろうか。互換性と言うことで言えば、では何のために標準仕様(実装のためのノウハウも含む)が存在しているのだろうか。
こうした稚拙な論の最後に必ず持ち出されるのが(5)だ。「幸いにして」窃盗された端末が犯罪に使われた事例は当時大きく報道され問題化したので論としても張りやすい。しかし犯罪抑止というならそもそも携帯の存在自体が犯罪に使いやすい側面こそがあるわけで、それをSIMフリーのみに理由付けするのはおかしい。またであるなら、そもそも(PDCのような)「SIM脱却論」に発展させないのは何故なのか。つまりそこまではコストをかけたくない程度の問題意識でしかないということだ。であればSIMフリー論の足枷になるレベルでもないだろう。

ところでこの記事は「アゴラ」に投稿されている。池田信夫氏によればアゴラとは「Huffington Postのような「言論プラットフォーム」をつくる試み」であり「専門家が実名で発言することによって、政策担当者やジャーナリスト、あるいは一般市民との交流をはか」るのが目的とある。ある程度立場のある人々のあつまりであればある程度のポジショントークもやむを得ない面もあるだろう。しかしこうも露骨な「自社利益への誘導」を目的としたエントリーも許しているのだろうか。そうであればその言論プラットフォームとは何を目的としどこへ向かおうとしているのか、はなはだ疑問だ。

さてどうやらSIMフリーというのはキャリアにとっては随分嫌なもののようだ。恐らくその理由は「自らのビジネスモデルを阻害する」からだ。そして総務省が進めようとしているオープンプラットフォーム構想も随分とキャリアからの風当たりが強いようだ。これも同じく彼らのビジネスモデルを阻害するから、ということになるだろう。
ではそのビジネスモデルとは何なのか。その根本は何なのか。
そのためには少し日本のガラパゴスと呼ばれるビジネスモデルと技術的な背景の成り立ちについて考えてみる必要がある。

1999年にiモードが誕生した時1つの「発明」が生まれた。それが「端末ID」だ。サブスクライバIDや個体識別番号などとも呼ばれる。物理的にはSIMカードと紐付き論理的には契約単位や電話番号と紐付けられ、どの端末(または契約単位)からのアクセスであるかをWEBサーバー側へ知らせるために使用される。機能的にはただこれだけの単純なものだ。
しかしどの契約と紐付いているかは当然キャリアは把握できる。そして契約は当然口座やクレジットカードと紐付いている。そこで「端末ブラウザからのアクセスによる購買をキャリアが保証する」ビジネスモデルが生まれた。これが今日まで大成功と言わしめiモードの名を世に轟かせた「モバイルEC」の姿だ。その根本原理はその後10年間実は何も変わってきていない。発信された端末IDをキャリア(または公認され端末IDを受信できる公式サイト)がただ受け取り購買行為としてまとめられているだけだ。docomoに限らずその後現Softbank、現auまたイーモバイルも同様の仕組みを取り入れ公式サイトを中心に取り込んだ。
この仕組みは単純でHTTPやWEBアプリとの相性も良かったので簡単に広まった。またユーザーは4桁の暗証番号を入力するだけで(あるいは入力しなくても)購入が可能でまたキャリアの請求に合算されるのでECの付きものの敷居が低く受け入れられやすかった。
結果、日本は 世界で類を見ないほどの「モバイルEC大国」となった。
また購買に関わる以外でも端末IDは認証などに転用され、現在ではモバイルサービスを支える基盤となっている。

国際的にはこうした「端末ID」という考え方は(僕が知る限りでは)存在していない。キャリア回収モデルとしてはSMSで支払いをする、などのケースもあるようだが、多くの場合はモバイルECとはPCと同じように例えばクレジットカードを入力して行うもののようだ。
その点ではこの「端末ID型モバイルEC」のビジネスモデルは非常に優秀だったと言える。

しかし単純であると言うことは偽造も簡単だと言うことだ。例えば他人の端末IDを知り得てそれをECサイトに送り込めれば簡単に偽装可能となる。
そこでこの端末IDを完全なものにするには3つの条件が存在する。

(1) そのアクセスがそのキャリアの携帯網からのみであること。携帯網以外からのアクセスの場合には端末IDは偽装されている可能性がある。そのため各キャリアは端末がアクセスしてくるSRC IP(発信元IPアドレス)の一覧を公開している
(2) 携帯網は端末IDが偽装されていないことを保証しなくてはならない。すなわち端末IDはキャリア側ゲートウェイが付加すべきであり、例えば端末IDは通常HTTPメッセージ上に現れるがあらかじめ端末IDが付加されていた場合にはキャリア側ゲートウェイはこれを削除するか正す必要がある
(3)  端末の自由度が低いこと。例えば自由にユーザーがアプリを導入できる端末であれば端末IDの偽装を試みるアプリが開発されるかも知れない。(1)(2)を満たしていればほぼ偽装は出来ないと考えられるが、自由度を低くできればその危険性も低くできる

気付いて頂けるだろうか。この(1)から(3)を完全に満たすには、奇しくも松本氏の言うように「端末・サービス・ 通信回線が三位一体」でなければ不可能なのだ。
メーカー(端末)はキャリアの仕様に沿った端末のみを供給することで(3)を満たし、キャリア(通信回線)は(2)を満たし、プロバイダー(サービス)は(1)を保証する。
どれが欠けてもこの 「端末ID型モバイルEC」は成り立たない。

キャリア(や取り巻きのサービスプロバイダー)がもっとも恐れるのはこうした「単純な」技術に立脚したビジネスモデルが壊れることだ。これらは彼ら自身のエコシステム(必ずしも消費者中心のエコシステムでない点に注意)であり生命線だからだ。
そろそろ問題の正体が見えてきたようだ。
つまりSIMロックの議論とは純粋にSIMはロックされるべきか否かではない。キャリア側論者が問題をすり替える裏には必ず上記に繋がる何かがある。例えばSIMフリー端末が出回り、しかしキャリアの息がかからないことによって端末IDモデルを崩壊される足がかりにならないか、などの懸念だ。
また海外ではAppleに限らず端末メーカー主導でのビジネスモデルが盛んだ。これもやはり奇しくもiPhoneが日本型モデルによらずとも別のエコシステムを運用できてしまうことを実証してしまった。
キャリアからすれば「黒船携帯」はともかく、「ガラケー」だけは何としても死守したいに違いない。そのためにはSIMロック解除などと言う自分の島を荒らされる可能性のある行為は避けたいのが本音だろう。

では「ガラパゴスの本質とは何か」との問いには幾つか挙げられると思うのだけど(以前少しまとめたことはありますが)、もっとも端的にもっとも顕著に集約されているのがこの端末IDの仕様とそれへのビジネスモデルの寄りかかり方であろうと思う。
繰り返すが僕はただ自分の好きな端末を(多少の不便はあっても)自由に使いたいだけの消費者だ。キャリアやサービスプロバイダーの事情やましてやメーカーの世界進出なんてどうでもいい。しかしそうした当然享受できてもおかしくない「自由」がそれら関係各所の都合とやらで閉ざされているのであれば話は別だ。
こうした論議がオープンになされるのはこれまでの状況に比べれば全くもって健全な方向ではあるのだけど、得てして立場があったり何らかの「既得権者」との議論はまた得てして些細な各論に終始して不毛な議論に振り回されることがある。それは本質に触れられたくない人々も多いからだ。また特に気になるのは、成熟したマーケットに関わる議論だけにポジショントークが多いのは仕方がないのだけど、「消費者」という立場の人たちの声が少ないようにも感じる。
それだけに如何に議論を本質に近づけるか、そのために何を知るべきかの選択は非常に重要だと言える。そのためにもSIMロック議論だけに立ちとどまらずより広範囲な議論形成と論点整理が大切になるのだ。「賢い消費者」になるためにも。

2009-12
03
00:05:32
Squareはおサイフケータイと闘うことになるのだろうか


Squareと呼ばれるiPhoneを始めとした携帯端末でクレジットカード決済を行う拡張端末が話題になっている。

iPhoneを端末にクレジットカード課金ができる―Twitterの開発者、Jack DorseyのSquare、ベータ開始

当然にして日本ではおサイフケータイとの比較で話も進むのだけど、そもそも少なくとも技術的には全く別のレイヤーなのであまり比較しても意味がない気がする。とは言え、実際に日本でサービスを始めたら確かにマーケット的にはかなりの部分でおサイフケータイと被る部分が確かに出てくるだろう。

個人的に衝撃だったのは、このレシートの写真だ。
Continue reading

2009-06
28
03:33:00
ひかり電話と携帯電話とSkypeと


今までフレッツADSL モアⅡ(40M)で何の問題もなく5年ほど使い続けてきたんですが、週末にとうとうフレッツ光を導入しました。
古めのマンションなので光配線やLAN配線タイプではなく、各部屋へは電話メタル回線で引き入れるVDSL方式なんですが、要するにADSLの場合のモデムの代わりにVDSL終端装置兼ルーター(レンタル)を入れ替えるだけなので簡単でした。
実際には別に購入していた無線LAN対応ブロードバンドルーターで部屋の中はつないでおり、PPPoEもこのブロードバンドルーターから接続しますので、設定変更も一切なしです。
(この場合終端装置兼ルーターではPPPoEブリッジとなります)
マンション共有型なので下り速度は20Mから70Mまでばらつきますが、上りはあまり使われないのか50M辺りで安定していますね。
これまでモアⅡでは大体6M程度だったので、まあ快適になった気がしますが、実のところは下りよりも上りの方が満足度は高いです。これまではせいぜい1M程度だったのが一気に50倍になりましたので。
さてついでに(NTTのお姉さんの勧誘に簡単に乗って)「ひかり電話」も導入してみました。いわゆるVoIP電話ですが、ルーターから電話回線を分岐するのでそれまでの電話機をそのまま使えるのが特徴です。
実のところひかり電話まで入れるつもりは無かったんですが、固定電話では基本料金\1,700- + ナンバーディスプレイ \400- = 計 \2,100- がひかり電話だと基本料(基本プラン) \500- + ナンバーディスプレイ + \400- = 計\900- になるとのことで簡単に転んでしまいました。
とは言えよく聞く話ですが、割とひかり電話は障害も多いらしく、また掛けられない電話番号があったり、停電時(実質は災害時でしょうね)には通電がないので使えなくなるなど、デメリットも多いです。また固定電話->IP電話へのナンバーポータビリティなどで初期費用も\3,000-ほどかかる模様。
なので実際には自身の使い方やデメリットなどもよく考慮して変更した方がよいと思います。が、個人的にはまあ何でもいいか、ってところですね。
さて前置きが長くなりましたが、自分で使用できる電話環境が最近格段に増えました。ひかり電話に、メインのDocomo携帯、iPhoneに以前海外へかけていた時にはよく使っていたのですが最近久しぶりにiPhoneへインストールしたSkypeなど。
電話を受けるのはほぼDocomo携帯になっていますが、これは受ける上でのコストはかからないし、昔から電話番号が周知されているのでもう避けられないと。
しかし掛ける際には通話料がかかる訳で、果たしてどれを使って掛けるのが一番いいんだろう。
ということであまり通話料とかコストは見ていなかったのでまとめてみることにしました。
以下がその表です。
なおこれは僕の契約や使い方に沿っているだけなので、当然個人の契約内容やオプションなどにより全く金額や使い方も変わるはずなので注意してください。
以下を調べるに当たり各社のWEBサイトを参照しましたが、情報はさすがにわかりやすく載っていたものの、通話料が30秒単位だったり、1分/3分だったりばらばらでとても見分けが付きにくかったです。このあたり統一したらどうなんだろう。

Continue reading

2009-06
19
22:22:00
iPhoneOS 3.0でテザリング


一部方面でMMSやらSafariのアップデートやらSpotlightやらを他所に妙に盛り上がっているテザリングですが、ようやく設定の要領がわかってきた気がするので幾つかヒントをまとめてみます。
とは言えお勧めするものではないので具体的な方法は示しませんが、いろいろ試したくて試行錯誤している人には参考になるかも。
但し高額請求が発生する可能性も多々あり、キャリアとの契約に違反している可能性もあります。筆者は何ら責任をとりませんので、自己責任にてお願いしますね。
20090619222213.jpg

Continue reading