Request module on android not connecting...?


#1

Man, I feel like I can info dump on this one all day. Not sure where to start. Up to date on all modules, the Trigger platform version, etc. Only on Android, the Request module never seems to connect to a site it worked fine on in previous versions. I rely on a group of people for live Android testing; I use the emulator, and when it works, I push code to testers. I haven’t heard until today that a NEW install of my app on a probably-not-super-modern Android device couldn’t bang the request.get calls in the app. I grabbed an old Android device I have laying around - specifically an LG Bolt phone using just wifi and usb for debugging. I found the latest version of my app just went to limbo and timed out.

I grabbed older builds of my app (the .apk files) from my archive and started loading them on the phone until it worked. What I discovered was the build that worked used Request 2.4, Platform 2.5.1. So, I took my current code, rev’d back to those versions on platform and module, rebuilt and loaded it for debugging… and it didn’t work.

I can’t stand android, generally, on a good day, and I really hate the idea of developing native for this bunged-ass of a platform, and dealing with all the fragmentation, etc. I really want to stick with Trigger, but I’m at a complete and utter loss on how to even begin to properly research exactly where this is bombing. In addition, other users are using the very latest code on not-super-modern phones just fine.

I can’t find anything in the phone settings that might suggest it’s just a local/environmental setting, security model, etc.

Fire questions at me, I’m happy to answer them, but holy crap, I’m kind of lost.

Thanks.


Android 4.4.4 request module timing out
#2

PS… yes, the iOS version works like a charm. (sigh)


#3

I threw some warning messages into the forge log to clearly show the request call is timing out. I don’t know why this is happening, but it’s sporadic (this same code is out running in the wild right now on some machines).

Here’s the log messages:

[WARNING] [FORGE] 'validating danio at https://daniodiary.com/danio/1234/check'
[DEBUG] Native call request.ajax with task.params: {"url":"https://daniodiary.com/danio/1234/check","username":null,"password":null,"data":null,"headers":{"Accept":"*/*"},"timeout":60000,"type":"GET","boundary":null,"files":null,"fileUploadMethod":"multipart","progress":null}
[DEBUG] Returned: {"content":null,"callid":"7457B546-7A17-4C0B-AC30-251BE5AC4573","status":"success"}
[DEBUG] Returned: {"content":null,"callid":"2F94713E-1DA4-470D-90C7-EBF663BC85EA","status":"success"}
[DEBUG] Native call logging.log with task.params: {"message":"[FORGE] 'error validating danio: {\"message\":\"Request timed out\",\"type\":\"EXPECTED_FAILURE\"}'","level":30}
[WARNING] [FORGE] 'error validating danio: {"message":"Request timed out","type":"EXPECTED_FAILURE"}'
[DEBUG] Native call notification.hideLoading with task.params: {}
[DEBUG] Returned: {"content":null,"callid":"AC777755-0B00-437D-8F5B-F9DD9042E51B","status":"success"}
[DEBUG] Native call notification.alert with task.params: {"title":"Invalid danio","body":"That danio does not exist or is invalid"}
[DEBUG] Returned: {"content":null,"callid":"0C3B3C27-AA18-4A71-8886-112461B3B0A0","status":"success"}

And here’s the code with the logging messages as warnings so they’re easy to spot in the log as they’re a different color ( including the previously-declared variable containing the URL ). This call is stupid-simple and only validates, without any sort of credentials, that the requested data is a known entity in the database and is a unit that can be publicly read. Stupid simple. Works fine in the Apple generated code and simulator, and works a charm on some Android devices and not others. The only pattern I think I’ve found is that if the android device does NOT have an older version of the app already installed, it’s more likely to have the issue, but if you update in place, it seems like it’s fine.

Anyone…?

var DANIO_URL_BASE 			= "https://daniodiary.com";
//var DANIO_URL_BASE			= "https://dev-danio-diary.herokuapp.com";
var DANIO_CHECK_URL 		= DANIO_URL_BASE + "/danio/$DID$/check";

function validateDanio( did, next ){
	var url = DANIO_CHECK_URL.replace( /\$DID\$/g, did );
	forge.logging.warning( "validating danio at " + url );
	forge.request.get( 
		url, 
		function(data){
			forge.logging.warning( "returned from validate call with " + data );
			next( null, true );
		}, 
		function(err){
			forge.logging.warning( "error validating danio: " + JSON.stringify( err ) );
			next( err, false );
		}
	);
}

And as for test data, replace $DID$ with “4Q4Q1WYB” if you want to ensure that call is alive and well in the wild.

https://daniodiary.com/danio/4Q4Q1WYB/check


#4

Huh.

ok.

I guess I have to go check something out in my Heroku config on the production node. The test node seems to work just fine.

Huh.

Alrighty.


#5

Well, switching my app to use the native heroku address rather than the friendly masked domain name works fine. But… that doesn’t explain why it works some places and for some places and not others, unless there’s some weird and different DNS lookup handling at some mosts/ISPs, or behind some proxies or firewalls, or something. oy. my head hurts. For the time being, I’m using the heroku native address in the code; I don’t have time to keep banging my head on this wall, and have to restore users’ functionality. It sucks I have to do it with a code update, but here we are. (no, not using Reload, and this is the perfect reason to use it, I suppose).

If anyone has any ideas…? Thanks.

var DANIO_URL_BASE	= "https://danio-diary.herokuapp.com"; <-- yay, works!
//var DANIO_URL_BASE 	= "https://www.daniodiary.com";
//var DANIO_URL_BASE	= "https://dev-danio-diary.herokuapp.com";

#6

Do you have a valid SSL certificate for each of those domains?

Also, if you’re hosting all the domains from the same IP you could be running into an Android bug where it doesn’t support SNI on some devices:

Also see: https://developer.android.com/training/articles/security-ssl.html

Otherwise, can you paste the output from running adb logcat so we can see what’s happening in the device logs?


#7

So sorry, didn’t see this before today, and on my way out for some late-day meetings and an evening out. I’ll do so tomorrow. Thanks!