Http requests working in emulator but not in "Intel App Preview" app

Http requests working in emulator but not in "Intel App Preview" app

For those reading this thread, frameworks (such as Cocos2D) that rely on using XHR with file:// URLS, and treat a non-200 status and/or a non-OK statusText as an error may not work in App Preview due to some XHR override code that is included as part of App Preview. This special handling XHR code code built into App Preview can be disabled by adding the "data-noxhrfix" property to the <head> tag in your app, for example:

<!DOCTYPE html> <!--HTML5 doctype-->
<html>
	<head data-noxhrfix>
	<meta charset="UTF-8">
...

The override should only apply when the status is 0 and the responseURL is not empty. The override mechanism is part of App Preview in order to workaround an Android issue relating to file:// URLs that are not located in the Android assets directory.

3491 RELEASE UPDATE: There is a known bug with the Simulate tab and the use of this signaling feature. It appears to be a bug in the Simulate open-source tool and can be caused by adding any "data-*" attribute to the <head> tag. Please see this forum post for additional details > https://software.intel.com/en-us/forums/intel-xdk/topic/626468#comment-1... <

--Paul F. (Intel)

- - - - original post - - - -

Hi,

There should be a simple explanation for this different behavior on my Android cellphone, but I don't know it.

I have built an SDK for my test (HTML5) app which has, at its essence, the following Http request/response code:

function executeRequest(req, callback) {

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://ipinfo.io/json', true);//hard-coded test
xhr.send();
console.log('executeRequest: sent() request');

xhr.onload = function(e) {
            console.log('executeRequest: onload: statusText: '+this.status);
            if ((this.status == 200) || (this.status == 201) || (this.status == 204)) {
                var error = null;
                if(this.response != '') {
                    response.body = this.response;
                    //response.headers = resp.headers;??
                    response.statusCode = 200;
                    context.response = response;
                    callback(error, response, context);
                }
                else {
                    var error = {
                         message: this.status + ': ' + this.response,
                         code: this.status
                     };
                     response.statusCode = this.status;
                    context.response = response;
                    callback(error, response, context);
                }
            }
};

}

 

When I run this in the XDK Emulator, it works fine - getting a response that is logged at "console.log('executeRequest: onload: statusText:..."

 

When I push the code to the server and run it in my Android (NOT USB-CONNECTED) phone in "Intel App Preview", it does not get to the "onload" function. WiFi is on and my phone is (WiFi) connected to my router.

What's different about running it in this mode? Is there something simple that I am missing?

Is there an example/library somewhere that works?

Regards

Colin Goldberg

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Colin,

Maybe you are using jQuery 1? There is an issue with jQuery 1 and Cordova apps. Both jQuery 1 and jQuery 2 will work in the emulator, but only jQuery 2 will work on device. If you are using App Designer, you are using jQuery 1. See FAQ: 

Pamela

Okay - you aren't using jQuery. But the FAQ may point you in the right direction.

Hi, Colin:

Some HTML5/JavaScript program that will work in emulator but may not work on real device. The difference of emulator and App Preview is that the emulate tab bases on the Chromium desktop browser; but the App preview essentially a weinre (Web Inspector remote) console provides quick view of web app in native WebView on that device.

To understand more about the difference between running your app in a WebView and running it in a browser, please see When is an HTML5 Web App a WebView App?

Hope it could help you.

Colin -- use the Debug tab for the best environment to debug this issue. If that doesn't work, they try using remote CDT (see this page for info on how to use remote CDT > https://software.intel.com/en-us/xdk/docs/intel-xdk-debug-and-test-overv... <)

Best Reply

Try to add the following to the index.html file:

<!DOCTYPE html>
<!--HTML5 doctype-->
<html>
	<head data-noxhrfix>
    <meta charset="UTF-8">

AppPreview somewhat hacks the http requests, with the data-noxhrfix, I solved all the problems.

 

Thanks, Andrea. That worked!

I would never have guessed it.

As this is a VERY basic capability, I would hope that information about this is prominently displayed somewhere (beside the forum), to help others who will surely be faced with the same problem. I would also like to understand it more, and to have more certainty that this same problem will not resurface if I change something.

Thanks for all the responses - it seems that there was a real need to solve this pronto.

Regards

Colin Goldberg

Colin -- I was unaware of this issue. I've filed a high priority bug fix request regarding this problem.

Awsome. Thanks

Searched a lot found a sloution here.

引文:

Andrea C. 写道:

Try to add the following to the index.html file:

<!DOCTYPE html>
<!--HTML5 doctype-->
<html>
	<head data-noxhrfix>
    <meta charset="UTF-8">

AppPreview somewhat hacks the http requests, with the data-noxhrfix, I solved all the problems.

 

Worked like charm

I am currently experiencing a similar issue. AJAX Http requests in the emulator work as expected, but under the debug tab I receive an error:

net::ERR_CONNECTION_REFUSED

General:

  1. Request URL:

Request Headers:

  1. Content-Type:
    application/x-www-form-urlencoded
  2. Origin:
    file://
  3. User-Agent:
    Mozilla/5.0 (Linux; Android 5.1.1; SM-G900T Build/LMY47X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Crosswalk/16.45.421.19 Mobile Safari/537.36
  4.  
  5.  
  6.  
  7.  

Form Data:

  1. username:
    MyUsername
  2. password:
  3. grant_type:
    password

 It appears the request never reaches my local server. Again, this works perfectly fine from my Emulate tab. The included fix above did not solve this issue for me.

Leave a Comment

Please sign in to add a comment. Not a member? Join today