というわけで、今回はMac系でもiPhone系でもない雑誌に掲載されました。
日経 TRENDY ( トレンディ ) 2010年 04月号 [雑誌] 日経TRENDY 日経BP社 2010-03-04 by G-Tools |
なんだか今までと違った嬉しさがありますよね。掲載していただき感謝感謝です。
シンプル、GPS連動、この方向性はそれなりに間違ってなかったことで。
ダウンロードはこちらからどうぞ。
林檎と音楽に囲まれて・・・
というわけで、今回はMac系でもiPhone系でもない雑誌に掲載されました。
日経 TRENDY ( トレンディ ) 2010年 04月号 [雑誌] 日経TRENDY 日経BP社 2010-03-04 by G-Tools |
なんだか今までと違った嬉しさがありますよね。掲載していただき感謝感謝です。
シンプル、GPS連動、この方向性はそれなりに間違ってなかったことで。
ダウンロードはこちらからどうぞ。
iPhoneカメラライフ ビー・エヌ・エヌ新社 2010-02-22 by G-Tools |
拙作の TwitPict が本日発売の「iPhoneカメラライフ」に掲載されました。
名前の通りiPhoneのカメラで楽しもう!という主旨の本なのですが、有名なカメラアプリに紛れて、一番最後の “twitterに投稿する” というコーナーにて写真を簡単に投稿できるアプリとして紹介されました。
iPhoneのカメラといえば、200万画素だったり300万画素だったりで、最近のデジカメからするとものすごくスペックは低いようにみえますが、そこを補うかのようにたくさんのカメラアプリがでていますし、そんなカメラアプリで写真を撮るというのも一つの魅力ですよね。(ま、私のTwitPictは違いますけれど・・・)
最後になりましたが、掲載していただきありがとうございました。
2010年最初のミーティング。場所はいつもの本陣にて。
いつものメンツと新しい方々で、iPhoneの話とかiPadの話とかを酒の肴に盛り上がりました。
今回は、準備不足でちゃんとしたプレゼン?ができなくてすいませんでした>関係者のみなさま。次回はちゃんとネタを用意していかないとダメですねえ。
開発の情報交換が出来たり、今回も刺激たくさんの飲み会でした。スタッフの方々いつもありがとうございます。(最近はじゃんけん大会連敗中です・・・)
余談ですが、QuickTakeの実機をはじめてみました。
次は4月ということで、iPadの実機持参での集まりになるといいですねえ。(それまでにiPad用のネタも仕込んでおかねば、、、という話もありますが)
昨日の13日、アップルストア心斎橋にて4時間の長丁場イベントに参加してきました。もちろんその後の二次会にも。
特に最初のCES報告会はものすごい盛況で50-60人くらいは軽くいたんじゃないですかね。開始30分くらい前に会場についたものの、すでに立ち見決定で、魚井先生の土産話を聞いていました。
MUGNET定例会になったあたりから、まわりもちょっと落ち着いてきて、いつもの雰囲気に。で、のんびりとみていたらいきなり「itokさん、最近新しいアプリを出されましたよね?」というフリ。これが噂の「無茶ぶり」ですかと軽く「無限スコープ」を紹介させていただきました。
常に無茶ぶりに耐えられるようにアプリのデモ動画を常備しておく(or YouTubeにおいておく)っていうのも手かもしれませんね、と。
公開収録をみるのは初めてでしたが、以前、特番の収録に参加した時とはまた違う雰囲気で、面白かったです。やはり、みなさんそれぞれ個性的ですから、ネタによっていろんな化学変化をしますよね。
2次会でははじめての人ともいろいろとお話できて楽しかったです。なにやら新しいアプリのアイディアもいただきましたし、これについては前向きに検討していきたいと思います。ちょうどお蔵入りになっていたものを復活させられるかもしれませんし。
そんなこんなで、ワンボタンのみなさん、参加されたみなさんお疲れさまでした。また配信を楽しみにしています。
iPhoneアプリのレビューサイトとして有名なAppBankの中の人が京都に来られるということで、いつも大変お世話になっていることもありますし、一度話をしてみたいな、とそのオフ会に参加してきました。
いつのオフ会の雰囲気と違って、ほとんどが初対面の人ばかりで、普通のiPhoneユーザーのみなさんばかりでしたが、それはそれで面白かったです。拙作アプリの愛用ユーザーの方も結構おられまして大変励みになりました。
で、目的のAppBankさん。なんといいますか、ネット上で見ている印象とほとんど変わらない雰囲気で、月並みな言葉で言えば強いオーラを感じました。一次会ではそれほどお話できなかったのですが、二次会では同じテーブルでじっくりとお話を聞くことができました。
ちなみに、AppBankさんは二次会で離脱されましたが、最後に残った3人で三次会まで決行され、家に帰って寝たのは3時くらいでしたかね。地元京都での開催ってことで時間の余裕があったのでつい長居してしまいました。
全体として大変面白く有意義な時間を過ごすことができました。みなさんお疲れさまでした。
最後に、今回強く思ったのはもっといいものを作らないといけないってことです。なので新年早々にも書いたけれどもう一度。
まだまだ行ける。もっと上に行ける。
Apple系Podcastとして有名なApple News Radio ワンボタンの声に参加させていただきました。
おそらくことの発端は、僕自身がワンボタンの声のアプリを作ろうとしたことによると思うのですが、その話の流れで「12月か1月くらいに収録を」みたいなことになりまして、みなさんのスケジュール調整の結果、ようやく先週末に収録がとりおこなわれました。
もちろん、podcastの収録は初めてでしたし、そもそもskypeでの複数人チャットもはじめてのことだったので、ちょっと勝手のつかめないままあっという間に時間が過ぎてしまった気がします。
で、配信されたのがこれです。
まず最初にプレビュー版を聴いた時、編集ってほんとにすごいなあ、と。いろんな雑談とか、話がそれてしまったりしていたのに、こんなにきれいになるものかとびっくりです。
で、個人的な感想、というか反省ですが、改めて自分の声を聞くと、やっぱり鼻声で、そして発声があまりよろしくないようで、だからちょっと聴きにくいですね。自分で聴いていても「え?なんていった?」と思うこともありましたし。あとは、編集のことも考えて、あまり発言タイミングがかぶらないようにすべきでした。これははじめてのことなので仕方ないというところですが。
肝心の中身ついては、あくまで一開発者の主観ですので「こういう考え方もあるんだな」という軽い気持ちで聴いていただければよいなと思います。自分で言うのもなんですが、偏っている気がしなくもないのでね。
ワンボタンの声のみなさん、山村さん、松尾さん、魚井先生、どうもおせわになりました。もしこれに懲りることなく、また機会がありましたらご一緒させていただければ幸いです。
いろいろと話題のOAuthですが、その意義とか仕組みとかはさておき、実際に実装してみようと思ったときに、ややこしいのはsignatureを作ってリクエストを生成するところなので、そのあたりをざっとメモっておきます。
あくまで個人的な覚書なんで、より詳しくは本家のサイトを参照してください。OAuth Core 1.0a
以下、NSString を ‘&’ や ‘=’ で連結しているかのような記述がありますが、単なる文字連結のイメージですのでご了承下さい。
全体を通していえることですが、すべてのGET/POSTパラメータは key, value ともにURLエンコードされている必要があります。(実際 key のほうは不要であることが多いですが)
OAuthでのURLエンコードはRFC3986準拠ですので注意しましょう。CFURLを用いて例えばこんなふうにできます。
CFStringRef encoded = CFURLCreateStringByAddingPercentEscapes(
kCFAllocatorDefault,
(CFStringRef)str,
nil,
CFSTR(":/?=,!$&'()*+;[]@#"),
kCFStringEncodingUTF8);
以下、http://twitter.com/statuses/user_timeline.xml?screen_name=itok_twit にアクセスすることを前提にメモっておきます。
OAuthの標準パラメータとして、以下のようなものがあります。(GETなりPOSTなりで渡す必要があります)
CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault);
CFStringRef nonce = CFUUIDCreateString(kCFAllocatorDefault, uuid);
CFRelease(uuid)
signature の元となる signature base は分解した link や normalized parameter を元に ‘&’ で結合します。
NSString* base = [HTTP method]&[my_urlencode_rfc3986(link)]
&[my_urlencode_rfc3986(parameter)];
ここで link はいわゆる query をのぞいた部分。
NSString* link = @"http://twitter.com/statuses/user_timeline.xml";
normalized parameter は POST/GETパラメータ(標準パラメータ含む)を全部key=valueの形にして昇順ソートし、それを ‘&’ で結合して1つの文字列にしたものです。
NSString* parameter = [key1]=[val1]&...;
/* oauth_consumer_key=xxxx&oauth_nonce=xxxx&
oauth_signature_method=HMAC-SHA1&oauth_timestamp=123456&
oauth_version=1.0&screen_name=itok_twit */
次に HMAC で使う key も ‘&’ で結合。
NSString* hmacKey = [my_urlencode_rfc3986(consumer secret)]
&[my_urlencode_rfc3986(token secret) *なければ空文字];
signature base と HMAC key から HMAC-SHA1 ハッシュを生成し、これを Base64 エンコーディングしてURLエンコードして signature とします。
NSString* digest = my_hmac_sha1(base, hmacKey);
NSString* base64 = my_base64_encode(digest);
NSString* signature = my_urlencode_rfc3986(base64);
パラメータに oauth_signature=signature を追加して、最終的にアクセスするURLの出来上がり。
と、ざーっと書き連ねてみました。手元で動いている現状のソースから引っ張ってきたので多分大丈夫と思いますが、なんかおかしかったら教えてください(いつでも弱気)
twitterヘの認証方式は2つありまして、1つはお馴染みBasic認証。もう1つがOAuthです。で、なにやら、今後はOAuthしか受け付けなくなるとかいう話があって、ちょっと盛り上がっているtwitterクライアント界隈。
OAuthの細かい話はさておき、twitterのOAuth認証(access_token取得)の手順には2通りがあります。(太字はiPhone上での主な挙動)
まあ、セキュリティ云々の話は別として、どっちもどっちだと思うわけです。サーバ型ではアプリをいったん離れなければなりませんし、クライアントではPINを入力するという手間がかかります。
じゃあ、アプリを離れることなしに、サーバ型の方式は使えないのかと思って試してみました。
UIWebView の delegate でアクセス予定の URL を取得できます。ここで、指定していた callback URL にアクセスしようとしていたら、そこから oauth_token パラメータを取り出せるのではないかと考えました。
予想通り、UIWebView の delegate で (4) の callback 呼び出しをとらえて、そこから oauth_token を取得することができました。これだと操作がアプリ内蔵の UIWebView だけでとじているので、アプリの切替もPINの入力も要りません。極端な話、callback URL 先の実体すら不要です(存在しないURLを指定していても大丈夫のようです←実際にアクセスする前に request を止めるので当然といえば当然ですが)
delegate 内はこんな感じで。
- (BOOL)webView:(UIWebView *)webView
shouldStartLoadWithRequest:(NSURLRequest *)request
navigationType:(UIWebViewNavigationType)navigationType {
if ([[request.URL host] isEqualToString:@"callback.example.com"]) {
NSString* query = [request.URL query];
NSArray* arr = [query componentsSeparatedByString:@"="];
if ([arr count] > 1 &&
[[arr objectAtIndex:0] isEqualToString:@"oauth_token"]) {
NSString* token = [arr objectAtIndex:1];
// do something
}
return NO;
}
return YES;
}
OAuthの運用上、あるいはセキュリティ上の問題があるかもしれませんが、それらをさておいたとして純粋にユーザ視点にたてば、これが一番スマートなのではないでしょうか、と。
あとは、twitterのログインページがiPhoneに最適化されれば問題ないんですけれど・・・
***一応、手元で開発中にアプリでは問題なく動いているんですが、なんかおかしかったら教えてくださいませ。
たまには開発の小ネタでも。
ご存知のようにiPhoneでFlashは再生できません。なので、基本Flashベースで動いているYouTubeの動画なんかも再生できません。(もちろん、標準のYouTubeアプリは別ですが)
動画再生専門のアプリならともかく、ちょっとしたYouTube動画を再生したいと思った場合には、標準のYouTubeアプリをURLスキームで起動するのが手っ取り早いわけですが、それだと自分のアプリに戻ってこれなくなります。
そこで、YouTube動画をアプリ内で再生する方法。
YouTubeはFlashベースではありますが、MP4ファイルが取り出せることもよく知られている事実です。もちろん簡単には取り出せないのですが、
この辺りを参考にしますと、get_video_info.php で取得した token を用いて fmt=18 を指定すればmp4で取得できそうです。
余談ながら、最初はサーバでこのtokenを取得してアプリからの要求をリダイレクトさせようと思ったのですが、tokenはアクセス元によって異なるようなので、DL元(今回の場合はiPhoneアプリ)でtokenを取得しないと行けないようです。
というわけで、NSURLConnection あたりを用いて token を取得し、それをそのまま MPMoviePlayerController に渡せば無事に YouTube の動画再生ができました。(コンソールには Warning: MPMoviePlayerController may not support file of type php
のようにPHPファイルは再生できないといった警告がでますが、YouTube側のリダイレクトの話なので特に問題なさそうです)
任意の video_id を渡して MPMoviePlayerController で再生するサンプルコードを GitHub においてますので、参考にしてください。