過去ログこの広告は、90日以上更新していないブログに表示しています。#facebook4j色々とFacebook自体が不勉強なのでメモしておく色々とありがとうございます(ぺこり公式サイトにAPIサポート一覧ページを追加しました。eclipse上で動かないや(汗。projectがmavenで作ったような感じだな。ProgrammableCallBack版の資料も公開されていますね。/>と書かないと文句言われちゃうのかな....あとCALLBACK認証を繰り返していると=>ブラウザ開きまくる=>端末固まる=>電源切って再起動*1はよくあるのでこれ閉じる方法って無いんだろうかとはよく思うわけですね......*2ちなみにGalaxyNoteやXoomがよく固まります。あたりも必須かも今日のメモ。AndroidアプリをHTML5で組もうとするときは、とりあえずandroid:hardwareAccelerated="true"としておくと良い。GNなどの大画面+ICSな機種においてかなりの高速化が見込める。webな話はあるんだけど、OAuth認証用のWebページに関してはどうもうまく動かなそう。/>な書き方ができないようなのでベタになるわけですけど、セキュリティの話をするとここらへんは一番容易にデコンパイルできるわけだから切り無い気もする。みたいなのあったような。YoruFukurouな話もあるので。いう点(未だ1.6,2.1〜,3.0〜系のサポートはずっとある現状)、Android4系からはAndroid版Chrome*5横スライドでアプリ終了とか出来るわけだけど、ブラウザ形式だと開いた奴がずっと残ってるとかあるわけで。難しい話なんですけどね....よく感じるのはセキュリティクラスタの方は警告はしてるけどそれでもそういうソフト使った場合は自己責任のポジションなのかな。追記)CALLBACK形式のOAuth関係にはこういう問題も有るみたい(そういえばIS01のtw認証も一時期メモリ足りなくて落ちるから封じていたよな。URLでアプリに戻ってきた時はmRequestTokenがnullなのでアプリが落ちる。YoruFukurouRequestToken保存すればいけるかな。YoruFukurouLowMemoryKillerで死んでも、onSaveInstanceState()で保存しておいたBundleは使えるようだ。YoruFukuroutwitter4j.auth.RequestTokenはSirializableなのか。Bundle.putSerializable()で保存してみる。YoruFukurouonSaveInstanceState()/onRestoreInstanceState()でmRequestTokenを保存・復元したら動いた。する対応はしっていたけどそれだけじゃ対処不足なのか。追記2)ブラウザベースの認証でも穴有るみたいだな。そりゃAPIとしてアカンだろ。Togetterまとめ開発者としてはここまで対応したので安心してくださいという話なのかな(汗。さんから補足いただきました。