GWT load issues on ios 3G device

[Paul Mazzuca]

I have an IPhone 4 which I am testing my GWT app on.  In Chrome or Mobile Safari, my application will only load when connected to WIFI.  This behavior seems to be consistent, but I wanted to get a sanity check from the community to see if anyone else has experienced this?  I am using code splitting and the xsiframe linker.  My initial download size is around 100k, even with code splitting... ya I know still pretty hefty. 

My thoughts are that the cause may be related to the initial download size being too large, something weird with the xsilinker, or just something bogus that only happens with 3G.   Of note, this does not seem to occur with 4G connections. 

Any thoughts?

[Jens]

Our GWT apps work just fine on 3G connections.

The only issue that exists on iOS 6.x is that mobile Safari 6.x has JIT issues (actually these JIT issues also exist in Safari 6 on desktop) which can result in random JavaScript exceptions if you are unlucky. These random exceptions can also cause your app to not load. The only solution is to either use Chrome on iOS 6.x until Apple has fixed these JIT issues (Chrome also uses the Safari rendering engine on iOS but Chrome does not have access to the JIT compiler thus Chrome works) or you have to do a nasty hack which somewhat disables JIT in Safari for your app.

Have you setup a GWT.setUncaughtExceptionHandler()? If not, set it up with a simple window alert to see if any unexpected exceptions occur in your app while loading.

-- J.

[David Feshbach]

We had an issue with Sprint "optimizing" the page by inlining scripts. As a result, there was no source attribute for the nocache script which prevented it from loading the other scripts (which are on a different server from the host page). We got around this by adding a "gwt:property" meta element that set the "baseUrl" property.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Mazzuca]

Well, the test iPhone is using Virgin Mobile USA which I believe piggybacks on Sprint's network so that would make sense.   The onModuleLoad method is not even being called, so I suspect the js files are no where to be found.  Just to confirm, I edited my html file to include the meta tag <meta name="gwt:property" content="baseUrl=myprojectname"> given that my project js file is typically located at

<script type="text/javascript" language="javascript" src="myprojectname/myprojectname.nocache.js">?

On Friday, July 26, 2013 2:14:04 PM UTC-7, David wrote:

We had an issue with Sprint "optimizing" the page by inlining scripts. As a result, there was no source attribute for the nocache script which prevented it from loading the other scripts (which are on a different server from the host page). We got around this by adding a "gwt:property" meta element that set the "baseUrl" property.

On Jul 26, 2013, at 1:53 PM, Paul Mazzuca wrote:

I have an IPhone 4 which I am testing my GWT app on.  In Chrome or Mobile Safari, my application will only load when connected to WIFI.  This behavior seems to be consistent, but I wanted to get a sanity check from the community to see if anyone else has experienced this?  I am using code splitting and the xsiframe linker.  My initial download size is around 100k, even with code splitting... ya I know still pretty hefty. 

My thoughts are that the cause may be related to the initial download size being too large, something weird with the xsilinker, or just something bogus that only happens with 3G.   Of note, this does not seem to occur with 4G connections. 

Any thoughts?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Paul Mazzuca]

Thanks for the quick reply.  I do have the GWT.setUncaughtExceptionHandler() setup.  The problem seems to be that even that piece of code does not have the opportunity to run.  I have added Window.alert() statements directly after the onMonduleLoad method of my EntryPoint, and not even that runs.  I suspect, as per my reply in the other post below, that the js files are not even sent to the client. 

[David Feshbach]

Have you tried using the web inspector? It's really useful for debugging web apps on iOS devices. There's also a way to do it with android/Chrome using adb but I don't know it off the top of my head.

Things I noticed when debugging our app that indicated the network: it worked over https but not http, the host page received was different from what the server sent. You may also be able to replicate the problem in a desktop browser by enabling tethering on your phone.

That tag looks right. I think if it's wrong it would stop working over wifi too. It's used for the script element that gets added to the DOM so it should be easy to check.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

[Paul Mazzuca]

I actually haven't used the web inspector.  This is a huge help.  So by using the web inspector, it turns out that my nocache.js is completely inlined into the html head section when using 3G via Virgin Mobile USA (Sprint), while when connecting via wifi, the nocache.js is downloaded separate, though referenced in the html head section -- and it does not work on 3G. The question is why doesn't the inline js run, or if it is running, where is it failing? 

 

… inlined js on 3G connection

<script type="text/javascript" language="javascript" style="display:none">

<!--

function myprojname(){…;

//-->

</script>

Just a few observations for others: 

- The inline javascript is surrounded by html comment tags, which I believe enables old browser compatibility

- The HTML is rendered (which makes sense since I can use the Web Inspector)

- I still do see the reference to the cache.js script which is not inline. 

Also, I am still playing with the gwt:property workaround that you mentioned.  no luck with it yet. 

You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/RU2WC0R9I3g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[David Feshbach]

The inlined script is running, but it's failing because it needs its own source attribute, which is removed during inlining.

I just noticed you're using a different linker than me, so that may be why the baseUrl property isn't working. If your linker doesn't have a way to override the base url for the scripts, you'll have to modify the nocache script in some way or switch linkers. Maybe you could write a simple script that loads the nocache script?

You could also contact Sprint and have them whitelist your site.

[confile]

Is there any solution for this problem? I have the same issue.

You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/RU2WC0R9I3g/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsub...@googlegroups.com.

To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Mazzuca]

The quick solution is to use HTTPS.   

To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.

For more options, visit https://groups.google.com/d/optout.