[TIMOB-2107] iOS: HTTPClient doesn't execute callbacks before returning in synchronous mode
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Low |
Status | Closed |
Resolution | Won't Do |
Resolution Date | 2020-01-09T18:33:03.000+0000 |
Affected Version/s | Release 3.0.0 |
Fix Version/s | n/a |
Components | iOS |
Labels | core |
Reporter | Harry Brundage |
Assignee | Ingo Muschenetz |
Created | 2011-04-15T03:10:38.000+0000 |
Updated | 2020-01-09T18:33:03.000+0000 |
Description
When HTTPClients are opened in synchronous mode (the third parameter set to false), the send call returns before executing the attached callbacks. I know it seems weird wanting to use callbacks with a synchronous call, but this behaviour seems to be expected of other XHR like objects by libraries like jQuery and SpazCore.
Try running this code to reproduce the issue:
var bool, xhr;
xhr = Titanium.Network.createHTTPClient();
bool = false;
xhr.open("GET", "http://api.twitter.com/1/help/test.json", false);
xhr.onreadystatechange = function() {
Ti.API.debug("Ready State change to " + xhr.status);
if (xhr.status === 200) {
Ti.API.debug("Setting bool to true");
bool = true;
}
};
xhr.send();
Ti.API.debug("Bool is: " + bool);
Output I get from iPhone SDK v4.1, Titanium Mobile SDK v1.4.0
[DEBUG] Bool is: false
[DEBUG] Ready State change to 200
[DEBUG] Setting bool to true
What I think I should see:
[DEBUG] Ready State change to 200
[DEBUG] Setting bool to true
[DEBUG] Bool is: true
If you run this code in chrome in a console on
api.twitter.com:
var bool, xhr;
xhr = new XMLHttpRequest();
bool = false;
xhr.open("GET", "http://api.twitter.com/1/help/test.json", false);
xhr.onreadystatechange = function() {
console.log("Ready State change to " + xhr.status);
if (xhr.status === 200) {
console.log("Setting bool to true");
bool = true;
}
}; xhr.send(); console.log("Bool is: " + bool);
You get the above expected output:
Ready State change to 200
Setting bool to true
Bool is: true
Can Titanium's XHR implementation be changed to conform?
Comments
- Harry Brundage 2011-04-15
Confirmed this issue persists in the mobile SDK v1.4.1.1
- Harry Brundage 2011-04-15
Any update on this folks? I'd love to use some of the stuff this breaks!
- Stephen Tramer 2011-04-15
XHR spec does say that these are supposed to be synchronous, but we're purposefully ASYNCHRONOUS. At least on the iOS side, we need a way to force events to fire synchronously, for cases like this.
- Stephen Tramer 2012-07-26 Confirmed SDK 2.2.0.014b86f
- Alan Hutton 2020-01-09 It has been decided that this issue should be closed as “Won’t do.” This issue is out of date with our current supported SDK release (7.5.2.GA as of the date of closure), and out of date with mobile OS versions. Updating, or creating code may not reproduce the issue reported, or be a valid test case.