ユーザ認証の機構を再考・エラー処理

一応前回（http://hshstter.hatenablog.com/entry/2012/03/27/025504）まででクライアントとしての基本的な機能は揃ったのですが、Access Tokenを持たない（つまり初回ログイン時）にはCUIに表示されるアドレスをコピーし、CUIの標準入力にPINを打って認証……なんてカッコ悪いことをしていたので、ここまで含めて全てGUIで処理できるようにしました。

具体的には、

(1)保存済みAccess Tokenがある→そのAccess Tokenでログインする。

(2)保存済みAccess Tokenがない→メインウインドウは出さずに認証用ダイアログを表示し、認証用URLを表示。
PINをText entryに入力後、認証ボタンを押すと、その認証でAccess Tokenを取得・保存し、ログインする。

という流れを踏みたい。

このためには、ツイートする関数・タイムライン更新関数などはAccess Token取得後に設定する必要があるため、Access Tokenを持たない場合はまずメインループを開始させ、Access Tokenを取得してからonClickedイベントの登録・タイマの追加などを行うような関数を書く必要があります。

流れだけ書くとこんな感じです。具体的な処理は全部消去して骨組みだけにするとこうなります。

mainRoutine関数で、メインウインドウが起動しクライアントとして使えるようになる感じです。
mainRoutine関数を呼ぶのは、restoreAccessTokenでファイル読み込みをした後か、getNewAccessTokenで新規にAccess Tokenを取得したあとなので、mainRoutine実行時には必ずOAuth値にはAccess Tokenの値が設定されています。

最後に、そういえば作成したGUIを公開してなかったのでここで公開。あくまで形を整えただけ。
特にタイムラインは早めになんとかせんとこれじゃ何もできん……

メインウインドウ。上のテキストエントリにツイート内容を書き、tweetボタンで投稿。
空白部分はテキストエリア。タイムラインが表示される。

認証用ウインドウ。英語は適当。

そう言えばいい忘れましたが、新たに定義したOAuth／GUI／Tweet型の各フィールドを正格な値にしました。
特にTweetなんかLazyなままだったら今後遅すぎてやばくなりそうな気がしたので。
そのあたりに関する変更点はほぼ無いので説明はなし。