「ついったーたいむらいんびゅーあ」もしくは「ら」は、905/705シリーズ以降のdocomoケータイ向けのiアプリで作られたTwitterクライアントです。全然、動作確認できてないですし、まだまだなのでβというかαです

さらっとした説明です。(私のN705iで元気に動いているところ)

だらだらとした説明です。(更新してません。。すみません。)


アプリのインストールは、下記リンクを辿ってTwitterのサイトから「ら」へ許可を出してください。そしたらケータイ向けダウンロードページが作成されます。ので、それをi-modeブラウザにて表示してやってください。

というわけで、使用するには、「ら」への許可 をください。

※ 気の迷いで許可してしまったと気が付いちゃった場合、Twitterサイトにログインし、「設定」の「Connections」から「ら」の許可を取り消したってください。「ら」や本サイトから何かする事は出来なくなります。いわゆるOAuth認証ってヤツのタマモノです。

直接、 本ページ をi-modeブラウザにてアクセスする事でもインストール出来ます。その場合、初回起動時に、ユーザ名、パスワードを入力する必要があります。(あまり、おすすめしません)


認証方式やら高解像度について、だらだらだらだら書きました。(2010.5.25)

このエントリーをはてなブックマークに追加  



つづく?

ちっとも動作確認できてないですが、iアプリで利用できる画面の大きさが 320x240 以上の機種が対象です。たぶん、だいたい905/705シリーズ以降になると思いますが、駄目だったりするかもしれません(ひょっとしたら以前のものでも動くかもしれません)。

ここらの、動いたよ~的なお声やご感想、ご質問、ご意見、叱咤、叱責、罵倒等々、 @k_ohga 向けにつぶやいてくださると励みになったり、落ち込んだりしますので、気軽に声をかけてやってください。


認証方式、について(2010.5.25)

だいぶ、ご無沙汰な更新です。

あれからやっつけでリストを読める様にして、半年くらい行方不明になっていました。
それはもう、いろいろあったのですが、今月くらいから余裕ができたので、更新を再開しました。が、また、消えてしまう事もありえるので、今は時間があるウチに、がしがし更新しています。がしがし。

で、まずは認証方式について。

なんか、以前も書いた気もしますが、iアプリはダウンロードされたサイトとしか通信できない制限がありまして、Twitterサーバとのやりとりは本サイトを経由しています。
つまるところ、認証情報(ID/パスワード)もここを経由してしまっていまして、私が、すごく怖い顔をした人に脅されたり、甘い罠にはまってしまったり、なんらかの事故があった場合、不可抗力的によるID/パスワードの漏洩がありえます。

xAuthというのに対応する事が出来たので、Twitterサーバとやりとりするたびに、認証情報を投げる様な事はなくなりましたが、それでも一度はID/パスワードが本サイトに通知されます。
本サイトではユーザ管理はしていないので、私の事を拉致監禁して、自白剤やカツ丼を与えてもなにも出てこないのですが、どんな事故があるか分りません。

なので、OAuthにしてもらえるとお互いシアワセになれる気がします。認証行為はTwitterサーバ側で行います。
それと、個人的にもxAuthと言う技術はTwitter側の暫定的な対応な気が、なんとなくしていますので、なるべくならOAuthをつかってくださると嬉しいです。


つぎに、高解像度について。

私のケータイでは確認が出来ないので、ちゃんとしたサポートは出来ない、というより、ただでさえ半年くらい放置するという実績があるので、アプリ自体のサポートも非常にあやしいのですが、解像度を指定してインストール出来る様にしました。

ココ(http://l.ttlv.jp)からアプリを入れると解像度を選択して入れる事ができます。

横幅が320を超えると、一個上のフォントを使う様にしていまして、緑の7にて設定を呼び出して、フォントサイズを指定する事もできます。
ただ、機種がサポートしてないフォントサイズを指定した場合、デフォルトのフォントを使います。

あと、既知の問題として、私の想定してるフォントサイズ以外だと文字組みが崩れます。発言の日付のトコとか、プロフィールのトコとかが顕著です。

お勧めはデフォルト(QVGA)なのですが、高さは調整しても良いかもしれません。


最後に、複数アカウントについて。

2010.6末くらいに本家がbasic認証をやめるといっていまして、OAuthへの移行の為に、今のアプリはそのままで、J環境とか、K環境とかを用意して、利用者の方には、別アプリとしてインストールできる手段を用意して、しのごうと思っていました。

けど、がんばって(そんなにがんばってないですが)英語でTwitterの中の人にメールして許可をもらって、「ら」もxAuthに対応する事ができました。
なので、J,Kの環境は不要なのですが、複数アカウントとして使えるっぽいのでそのまま使える様にしておきます。

複数アカウント、と言う意味では、解像度を1でも変えれば別アプリとして入れる事ができるハズなので、そっちでも良いかもしれません。

ちなむと、ココでも、Jでも、Kでも、インストールページのURLの最後に、"?x=240&y=380"とかすると、解像度が変えられたりします。

だらだら長くてすみません。いじょうです。



たぶん、ダイレクトメッセージ対応、について(2009.11.4)

どうにも、複雑なUIになってしまったのですが、DMに対応させていただきました。

DMを送るには、どこの画面からでも、緑モードにして「*」キー(もしくはソフトキーの左)"DM is sent"を押すと、その相手にダイレクトメッセージの下書きを作る事が出来ます。

で、下書きのリストのとこに「xxxxxへのDM」と緑の文字で書かれてるのがDM用の下書きになっていて、これを「0」キーで送信すると、DMが送られるハズです。

で、どの画面でも、緑モードの「4」キーで受信箱"DM Inbox"、「5」キーで送信箱"DM Outbox"を見る事ができます。送信箱は、Twitterサーバが認識してる送信したやつなので下書きとは関係はないです(下書きはあくまで「ら」が内部でもってるデータです)。

DMの仕様で削除はなんでもできるっぽいので、受信箱、送信箱、共に赤モードの「#」で削除できる様にしてあります。おそろしい事にDM相手の送信箱、受信箱のデータも削除してしまうっぽいので、ガッツのある人は使ってみてください。

また、DMは両思いになってないと送れなかったりする仕様らしいのですが、「ら」側では特に検知したりはしていません。すみません。

なお、緑モードがカオスなので、新しいモードを新設して整理する気もしてますが、なにか別の機能(listっぽい物?プロフィール編集?)を実装する時とかに、一緒に整理する気がしてきてます。


Google App Engine SDK の urlfetch に proxy を通す?、について(2009.10.30)

また、懲りずにサーバ側のネタです。 「ら」の開発では DoJa エミュレータと GAE SDK を動かしてる Linux とで通信しつつ一生懸命作ってる場合もあったりするのですが、 Linux 側が外と通信するのに、プロキシが必要という、ありがちといえばありがちな環境の場合。 SDK の urlfetch を使う時、そいつは proxy を使ってTwitterのAPIを叩かなきゃいけない訳ですが、http_proxy を setenv しても見てくれなかったりして悲しい思いをします。

ので、適当にソースコードをいじって proxy を通す為の応急処置したやつのdiffです。("http.proxy.host"(プロキシのホスト)と、3128(プロキシのポート)は適当に弄ってください。認証とか必要なら connection 相手におしゃべりしたりすれば良いと思うので頑張ってください)。つか、 python とか SDK 側で、どっかに定義をもってて、そこをいじればよかったりします?

--- google/appengine/api/urlfetch_stub.py.bak  2009-10-30 01:00:00.000000000 +0900
+++ google/appengine/api/urlfetch_stub.py  2009-10-30 01:05:00.000000000 +0900
@@ -188,9 +188,9 @@
                     host, url, payload, adjusted_headers)
       try:
         if protocol == 'http':
-          connection = httplib.HTTPConnection(host)
+          connection = httplib.HTTPConnection('http.proxy.host',3128)
         elif protocol == 'https':
-          connection = httplib.HTTPSConnection(host)
+          connection = httplib.HTTPSConnection('https.proxy.host',3128)
         else:
           error_msg = 'Redirect specified invalid protocol: "%s"' % protocol
           logging.error(error_msg)
@@ -208,7 +208,7 @@
         orig_timeout = socket.getdefaulttimeout()
         try:
           socket.setdefaulttimeout(deadline)
-          connection.request(method, full_path, payload, adjusted_headers)
+          connection.request(method, url, payload, adjusted_headers)
           http_response = connection.getresponse()
           if method == 'HEAD':
             http_response_data = ''




ソフトキーのラベル、について(2009.10.29)

ソフトキーのラベル、出るやつがあったり、なかったりするっぽいので見送ってましたが、ラベルをつけてみました。で、ちまちまと遷移周りを確認してたのですが、決定キーでモード変化って微妙ですね。FirefoxのVimperatorのガイダンスっぽいのを意識してるのですが考えるのが難解になってきました。

手が空いたら、どっちかのソフトキーでモード変換するように、変更かけます。あと、自動でバージョンアップの確認するの、そろそろ考えないと駄目ですね。。勝手に通信するのって嫌いなのでこれも見送ってました。


もろもろ、直しました、について(2009.10.28)

どうやらダウンロードの問題は直った風なので、一旦、上の赤字は消しました。ただ、OAuthを使わない場合の認証に失敗すると難解なエラーメッセージが出るみたいです。なんも考えてませんでした。もうちょっとなんとかします。

動いている風なので、friends_timelineをhome_timelineにして引いてます。あ、サーバ側の話です。OAuthだとなんか駄目みたい?。もどしました。またうそつきました。ごめんなさい。あと、RTの動作に変更はかけてません、とりあえず。これは状況をみてなんか考えてます。

なんか、listsを使える人になってたりするのですが、これってOAuthアプリの開発を登録してたりすると贔屓してくれるんですかね?とりあえず便利です。使い方を覚えるとか、それを使わせるクライアント側の実装とかしんどいかもしれませんが、tabs的な使い方が出来そうな気がしてます。APIが出てきたら実装を考えてみます。


HTTP Rangeヘッダのがバグってましたとか、について。(2009.10.23)

すみません、ここウソついていました。というかバグです。私は教材とかえらそうな事を言ってものを提供できる人間ではありませんでした。すみません。修正してますのでゆるしてください。あとiアプリは少しづつ直したり機能強化したりしてますが、使い方の説明んトコがちっとも直っていません。

こちらもぼちぼち直していきます。とりあえず、通信キャンセルとか、'@'付きの呼び出しが見れる様になったりとか、戻る(キャンセルボタン)のスタックを増やしたりとかしてます。落ち着いたら説明の方にも反映させていきます。ので、気長に付き合ってくださればと思います。


最新のタイムライン取得する時いっぱい取得してしまう、について。(2009.10.20)

もう、表題の通りなんですが、Twitter APIを使ってタイムラインを取得する時、max_id方向のはうまく行くのですが、since_id方向のがダメです。つまり、「このつぶやきまでのデータちょうだい」は大丈夫なのですが、「このつぶやきの次のからちょうだい」が駄目なのです。できるって書いてる様な気がするのですが。。

なので、「ら」では、最新を取ってくるとき、おなかに抱えてるモノの最新の一個前のつぶやきをsince_idに指定して取得しにいって、取れたデータの一番古いつぶやきが、おなかにかかえてるつぶやきの最新のものと同じかそれ以前なのかを判定して、なんか隙間があいていたら、それを補完すべく、こんどはmax_idを指定しつつ取りにいって、を何回かくり返します。

日本語にすると訳が解らなくなりますね、これ。というか、こういった不具合とかバグってのは、経験上、だいたい私が悪いことになるのが多いもんでして、最初は他人のせいにするのですが、あとからみんなにごめんなさいをするという。だからって、そうやって自分を責めてばかりいると、生れてきてごめんなさい、って気分になるので、一旦、ここに吐きだす事にします。

なにが言いたいのかと言うと、最新方向でつぶやきを取得する時は、こういった事情があって、イマイマはいっぱい受信してしまっています。


iアプリのサイズとか、HTTP Rangeヘッダとか、について。(2009.10.19)

「ら」は無駄に(?)アイコン付けたりしてるので、アプリサイズは120Kを超えてきてます。このクラス(DoJa5.0)のiアプリはスクラッチパッド(アプリのデータ保存領域)と合せて1Mなので、だいぶ余裕はあるのですが、画像データを保存するのにスクラッチパッドを贅沢に使っているので、油断はできない水準だったりします。で、アプリサイズ(jarのサイズ)が100Kを超えたあたりから、ケータイはアプリをインストール(ダウンロード)するのにRangeリクエストを投げて分割してダウンロードしようとします。

ふつうのapacheなら、たぶん問題無い、というか、私はそこらで悩んだ事が無いので、平気なんだと思うのですが、このサイトは、試しに Google App Engineを使ってたりしていて、普通の静的コンテンツとして配置しても、Rangeヘッダを解釈してくれないみたいでして、最初は100K以内に抑える為に頑張っていたのですが、途中で諦めました。

という訳で、需要があるか解りませし、ザイズチェックとかサボってますが、ここで動いていたGAE(python)のそこらのコードを教材的ちっくに。
class GetJar(webapp.RequestHandler):
  def get(self):
    path = join_path(dirname(__file__), 'keraji.jar')
    out = open(path).read()
    fsize = len(out);
    range = self.request.headers.get('Range','')
    
    mm = re.search(r'bytes=(\d+)\-(\d+)',range)
    if mm != None:
      offset = mm.group(1)
      end = mm.group(2)
      length = int(end) - int(offset) + 1
      self.response.set_status(206, "Partial Content")
      self.response.headers['Accept-Ranges'] = "bytes"
      self.response.headers['Content-Range'] = "bytes " + str(offset) + "-" + str(end)+ "/" + str(fsize)
      self.response.headers['Content-Length'] = str(length)
      self.response.headers['Content-Type'] = 'application/octet-stream'
      # self.response.out.write(out[int(offset):int(length)])
      self.response.out.write(out[int(offset):(int(offset) + int(length))])

    
    else:
      self.response.headers['Content-Length'] = str(fsize)
      self.response.headers['Content-Type'] = 'application/octet-stream'
      self.response.headers['Content-Length'] = str(fsize)
      self.response.out.write(out)




インストールとか、認証関係とか、について。(2009.10.18)

ネイティブアプリっぽいクセに、使い始めるのが、なんで、こんな面倒なのかと言うと、認証情報(パスワードとか)を、このサイトを経由してやりとりしてしまうからです。 Windows,Mac等々の普通のネイティブアプリなTwitterクライアントであれば、認証情報はそのアプリで閉じてしまうのですが、iアプリはそれが設置してあったサーバとしか通信できない制限があるので、Twitterのサイトとのやりとりはこのサーバを経由する事になります。まぁ、ネイティブアプリだから安全だっていうのも、なにかの錯覚な気もするのですが、それは別の話。

ええっと、つまるところ、認証情報もここを経由してしまっているので、その気になれば、私は使用していただいてる方のパスワードとかを見る事ができてしまいます。なので、OAuthを使用してもらえるとお互いシアワセになれる気がするのです。

なんにしても、そこらの認証情報は「ら」でしか使用しません。また、アプリは悪用等ができない様に細心の注意を払いたいと思います。ここらも、なんかあれば報告してくださると助かります。あと、ついでに私は悪用しない事を誓います。たくさん。とてもたくさん。けど、その宣誓をどれほど信じてもらえるか不安ですし、私の能力不足に起因する事故って可能性もあるのです。

その点、OAuthにしておけば、最悪、私が暴走しても、Twitterの公式にログインして「設定」の「Connections」とかから、さくっと「ら」の許可を取り消してもらえば良い訳です。とても安心です。



presented by @k_ohga