jpurcell / birdhouse

BirdHouse is a Titanium Developer plugin for authenticating and sending API calls to Twitter.
64 stars 17 forks source link

Sending message to a Handler on a dead thread/not sending X-Requested-With header #16

Open rjsteele opened 13 years ago

rjsteele commented 13 years ago

I am opening this as a new issue since the similar issue was resolved.

I have the same problem (Twitter: not sending X-Requested-With header). I am using the following code.

Ti.include('birdhouse.js');

var BH = new BirdHouse({ consumer_key: "the_key", consumer_secret: "the_secret", callback_url : "the_call_back" }); BH.tweet('Trying something out....');

I would like to post "Try something out ..." to my twitter page, but nothing post. Do I need more code? When I run the emulator in Titanium, I get Twitter's authorization page with my apps information. I click 'Authorize app" and another Twitter page pops up "Redirecting you back to the application", but nothing post my twitter account.

I am using Android API 2.3.3 on the Titanium 1.7

I/ActivityManager( 62): Starting: Intent { cmp=com.palmvalleychurch.mainapp/org.appcelerator.titanium.TiModalActivity (has extras) } from pid 337 I/ActivityManager( 62): Displayed com.palmvalleychurch.mainapp/org.appcelerator.titanium.TiModalActivity: +451ms I/ARMAssembler( 62): generated scanline__00000077:03010104_00000504_00000000 18 ipp at [0x45fb5a08:0x45fb5a9c] in 441467 ns D/dalvikvm( 337): GC_CONCURRENT freed 754K, 46% free 4649K/8583K, external 1646K/1828K, paused 6ms+17ms D/dalvikvm( 337): GC_CONCURRENT freed 1052K, 45% free 4772K/8583K, external 1646K/1828K, paused 7ms+6ms D/dalvikvm( 337): GC_CONCURRENT freed 1226K, 44% free 4879K/8711K, external 1646K/1828K, paused 7ms+16ms D/TitaniumModule( 337): (kroll$6: app://twitter.js) [26004,49736] calling timeout timer 0 @1309623 D/dalvikvm( 337): GCCONCURRENT freed 1129K, 43% free 5102K/8839K, external 1646K/1828K, paused 8ms+7ms D/TiAPI ( 337): (kroll$6: app://twitter.js) [2285,52021] signing key is ****& W/OrientationEventListener( 337): Cannot detect sensors. Invalid disable E/TiBaseActivity( 337): (main) [60,52081] Layout cleanup. I/dalvikvm( 337): Jit: resizing JitTable from 2048 to 4096 D/TiAPI ( 337): (kroll$6: app://twitter.js) [284,52365] baseString is POST&https%3A%2F%2Fapi.twitter.com%2Foauth%2Faccess_token&oauth_consumerkey%3D****%26oauth_nonce%3DselupfcgPhdg7oRlrZFkXETQtfTspHa07xEIln5Mxz%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1309623092%26oauth_token%3DwVb0VGEbVSLZwqMXh4KoCh1eIcOnq8BMKWR17NFqY%26oauth_verifier%3DDcdGcPr4cDbZbtwTgCTl0kTagWpjbSoMCQTpYxQjI%26oauth_version%3D1.0 D/dalvikvm( 337): GC_CONCURRENT freed 1645K, 47% free 4911K/9159K, external 1646K/1828K, paused 7ms+5ms D/TiAPI ( 337): (kroll$6: app://twitter.js) [1822,54187] signature is rb72k5Vc0KJGD9YKJu2FxBQDpHs= D/TiHttpClient( 337): (kroll$6: app://twitter.js) [47,54234] Setting ready state to 1 I/TiHttpClient( 337): (kroll$6: app://twitter.js) [1,54235] Twitter: not sending X-Requested-With header D/dalvikvm( 337): GC_FOR_MALLOC freed 1031K, 50% free 4649K/9159K, external 1646K/1828K, paused 77ms D/TiHttpClient( 337): (TiHttpClient-2) [508,54743] Setting ready state to 2 D/TiHttpClient( 337): (TiHttpClient-2) [1,54744] Setting ready state to 3 D/TiHttpClient( 337): (TiHttpClient-2) [4,54748] Setting ready state to 4 W/MessageQueue( 337): Handler{4059ce70} sending message to a Handler on a dead thread W/MessageQueue( 337): java.lang.RuntimeException: Handler{4059ce70} sending message to a Handler on a dead thread W/MessageQueue( 337): at android.os.MessageQueue.enqueueMessage(MessageQueue.java:196) W/MessageQueue( 337): at android.os.Handler.sendMessageAtTime(Handler.java:457) W/MessageQueue( 337): at android.os.Handler.sendMessageDelayed(Handler.java:430) W/MessageQueue( 337): at android.os.Handler.post(Handler.java:248) W/MessageQueue( 337): at org.appcelerator.titanium.kroll.KrollCallback.callAsync(KrollCallback.java:162) W/MessageQueue( 337): at org.appcelerator.titanium.kroll.KrollCallback.callAsync(KrollCallback.java:96) W/MessageQueue( 337): at org.appcelerator.titanium.kroll.KrollCallback.callAsync(KrollCallback.java:91) W/MessageQueue( 337): at ti.modules.titanium.network.TiHTTPClient.fireCallback(TiHTTPClient.java:483) W/MessageQueue( 337): at ti.modules.titanium.network.TiHTTPClient.fireCallback(TiHTTPClient.java:474) W/MessageQueue( 337): at ti.modules.titanium.network.TiHTTPClient.setReadyState(TiHTTPClient.java:506) W/MessageQueue( 337): at ti.modules.titanium.network.TiHTTPClient$ClientRunnable.run(TiHTTPClient.java:1022) W/MessageQueue( 337): at java.lang.Thread.run(Thread.java:1019) W/KeyCharacterMap( 337): No keyboard for id 0 W/KeyCharacterMap( 337): Using default keymap: /system/usr/keychars/qwerty.kcm.bin

enhorn commented 13 years ago

Getting the same problem when running on ZTE Blade with 2.3.4 and built with 1.7.0.

philmohr commented 13 years ago

I have the same issue with my Galaxy S running 2.2. It seems the bug is related to:

http://developer.appcelerator.com/question/120956/httpclient-problems-when-switching-to-17-on-android

philmohr commented 13 years ago

could it be that we should handle the window closing after we dealt with the data and handled the return? i.e. return the window and then close it once we have done everything else?

in: webView.addEventListener('load',function(e){

else if (loads==3) {

win.close(); get_access_token(callback); return true; // return window here?

xeijix commented 12 years ago

I don't know if people are still looking for a fix for this issue... My fix is as follows:

We want to delay when the window closes, giving android enough time to process the callback data, so in this logic block: "else if (loads==3) {" I moved "win.close();" into a timeout like so:

                win.remove(webView); //* NOTE: it's ok to remove the webView, we just can't close it
                get_access_token(callback);
                setTimeout(function(){ //* TODO: check for ios vs android
                //* CUSTOM
                win.close(); //* we close it after 3 seconds, which is more than enough time
                            //* TODO: test older devices
                }, 3000);

Note: there might be better ways to fix this, from a speed/interactability perspective, the response on a droid device feels slow enough that the 3 second delay is minimal.