2010年5月31日月曜日

GoogleBuzz

先日行われたGoogleI/O 2010でGoogleBuzzのAPIが公開されました。
それからというもの、BuzzAPIと戯れる日々でした。

Buzzについては、周りの反応では「使ってないし...これからも使うつもりないなぁ...流行らないんじゃ?」って感じの人が多いみたい。
FriendFeedを良く触っている人からみると、FriendFeedの代わりになるものになるん? って感じもあるかと。

FriendFeedは、deliciousに登録する程でもないけど、気になったリンクを投稿して、コメントも付けておく。
後から検索できたらいいな..って感じで使う事が多いです。
Twitterでは、FriendFeedでの投稿 + 後で為にならないつぶやきも って感じ。
使う人によって用途は違うとは思いますが。
あと、たまに恩恵に預かれるのが、Twitterの調子が悪い時....FriendFeed経由だったらTwitterのエントリが取得できる時があること。
Twitterの調子が悪い時に、他の道筋で取得できるのは嬉しいですね。
FriendFeedの欠点としては、古いエントリが削除されてしまうこと。これは結構イタイ。
せっかく投稿しておいたリンク/コメントが消えてしまいますのでー。

さて、そんなFriendFeedの代わりにBuzzを使えるのか? なのですが、今の時点ではなんだか微妙。
第一に、Twitterのエントリが配信されるタイミングが遅い。
第二に、リアルタイムに取得できる口がない。リアルタイムじゃないTwitterの情報なんていらない><
第三に、リンクはあくまで補足情報の扱い。メインはユーザ入力の文字列。
第四に、Comment/Likeの情報はエントリの一覧からは取得できず、別途取りにいく必要がある。

第三についてですが...
FriendFeedの場合、リンクのポストをする場合、
1. リンクのタイトル
2. リンク
を投稿して、それについてコメントを入力していく形になっています。
その結果として取得できるエントリの文字列は、リンクタイトル + リンク になります。
リンクについては、短縮URLになっていたら展開してURL文字を返してくれ、URLが長かったら後ろを...にしてくれる賢い機能付きです。


それに対してBuzzの場合は、
1. リンクのタイトル
2. リンク
3. エントリの文字列
を投稿します。3.ユーザの文字列が無い場合、勝手に文字がはいるっぽい

これは、エントリの文字を空にしてWeb上から送信した時の状態。勝手に 「1 photo」と入ってくるみたい。
Buzzでのリンクはあくまでエントリ文字の補足情報としての扱いみたいですね。
エントリの文字列にリンクも含まれていないようですし。(上図はのリンクは、リンク情報を展開しているので見えているだけ)

FriendFeedの代わりに使う為には、クライアント側で整形してエントリを投稿してあげないとイマイチですねぇー。

とりあえず、空うさぎの次のバージョンには含めない形になりそーですが、色々模索を続けようと思っています。
あ、そうだ、Buzzの取得方法について、Javaに落としたサンプルをhttp://sites.google.com/site/shin1ogawa/googlebuzzに載っけてみたので、よければどうぞ。
• • •

2010年5月10日月曜日

ChirpUserStreams

ChirpUserStreams を試してみました。
これはまだTwitterの新しいStreamAPIらしいのですが、まだベータのものです。
正式に対応している Streaming API Documentationでは、PublicTimelineから特定のキーワードなどを指定して取得はできますが、自分のHomeTimelineの情報を取得することができません。
そこで、ChirpUserStreams。これを使うと、HomeTimelineがStreamで取得できてしまいます!

StreamAPIがを使うと、リアルタイムにエントリが取得でき、嬉しい事になります。
何か更新があった時にすぐに情報が取得できるのと同時に、何回もアクセスする事がないのでAPI消費も少なくする事ができます。
ちなみに、現在のChirpUserStreamsでは、通常のAPIで使用できる回数:350は全く消費されないようです。

ただ、残念なのが、認証方式がBasic認証しかまだないという事。うむー。
良く分かってないのですが、Basic認証情報が入ったユーザ/パスワードの情報が入ったHTTP HEADERは最初のアクセス時に送信されるだけなので、それ以降のエントリ情報受信が始まればヘッダー情報は流れないから傍受されても致命的ではないのかな? まぁ、だからといって...ですが。

そんな、ChirpUserStreamを空うさぎの開発版に組み込んでみました。
実装は、すぎゃーんメモを参考にさせて頂きました。有り難うございます!

エントリがリアルタイムに反映されていくのはやっぱり気持ちいい!
FriendFeedのリアルタイムAPIの時と同じ感動を味わいました。
これを味わってしまうと、今までの定期的に取得するタイプに戻るのがツライですw

ChirpUserStreamsでは、ツイート情報だけでなく、「フォローした」「Favoriteつけた」「Retweetした」という情報も入ってきます。
これを空うさぎで通知を出すように試してみたら、凄い量の情報量でビックリしてしまいましたw
この人、めっちゃフォローしまくってる...手当たり次第やってんの? とか丸分かりでちょっと怖い感じもしますが。

空うさぎ正式版でも、ChirpUserStreamsを使えるように空うさぎでは対応したいなぁーと思っているのですが、Basic認証の危険性をちゃんと警告してから使えるようにしないとダメですね。
しかも、API変更や、そもそも無くなるってこともあるし。

そう考えると、クライアントアプリで採用するのはまだ早い感じですが、空うさぎぐらいのマイナーなクライアントであれば許される?!そう思いたい程、やっぱリアルタイムでの取得はいいもんですー♪

...ということで、明日からはもうちょっとChirpUserStreamsでの実装を詰めていこうとおもいます。
• • •

2010年5月6日木曜日

AdobeAIRでサイズの再計算

空うさぎで、通知画面の改造を行っています。
今までは、前面に全画面を覆う透明のパネルを一つ貼って、その中に通知パネルをペタペタ貼っていたのですが、これでは問題が。
こぅすると、その他のアプリで前面表示するものと競合するようで、FireFoxのダウンロード完了ウィンドウとか、GoogleChromeでのタブの順番を移動しようとすると上手く行かなくなってしまいました。

そもそも、透明パネル対応をしたかというと、ウィンドウ(mx:Window)を作って消すというのは凄く負担のかかる処理で、CPUの消費も尋常じゃない><
通知の画面なんて、絶えずいっぱい出して閉じるものなので、それだとキツイんですよね。

で、今回の空うさぎでは、透明パネルをやめ、通知用ウィンドウを再利用することによりCPUの消費も押さえつつ、問題解決を試みています。

ここで問題が出たのが通知用のウィンドウのサイズ変更。
通知用ウィンドウは、表示する文字のサイズによって高さを自動的にぴったりになるように表示するようにしたい。
mxmlの設定ではheightの設定は行わず、自動的に計算するのに任せていました。

こーすると、ウィンドウ再利用時、上手く再計算をしてくれない。
AdobeAIRでは、サイズが指定されていないため計算を行った値を explicitWidth, explicitHeight という変数に格納しています。
一度計算がおわったものについてはこの値を使い、再計算を省くことにより速度を改善するんですね。

もちろん、width, height の属性に値を設定していればその値が使用されます。
実際どんな値を使うのか? は、getExplicitOrMeasuredHeight() , getExplicitOrMeasuredWidth() というメソッドが使えます。

ということで、計算させたいコンポーネントにて
explicitHeight = NaN;
explicitWidth = NaN;
validateNow();

をしてあげることにより、再計算してくれるようになりました。

mx:Textに入れた文字列の表示サイズを判定については、
1行のものであれば、measureText(txt)メソッドで取得できるTextLineMetricsから取得できます。
が、複数行になるものであれば、上記のvalidateNow() してあげれば大丈夫です。

ここらへんの、サイズ変更については、SwingでもSWTでもハマったな。
まぁーまだマシに解決できたAdobeAIRは良いのかも。

さて、次回の空うさぎは↑の処理を加えつつ、通知ウィンドウでいろんな処理ができるようになります。
お楽しみにー。
• • •