Background
We have a website that delivers dynamic content via download to our customers. Currently this is done by simply making a request to another page which dynamically sets the response ContentType and streams out the file data.
The Problem
We have now been tasked with delivering multiple pieces of content at once at the click of a button (or as a page loads). We have tried various approaches:
1) Multiple iFrames on the page with a different download URL in each. This did not work in all browsers, and since our platform is targeted at mobile phones, many of the native phone browsers did not handle the iFrames at all.
2) Multiple AJAX requests for the content. This is flawed as the AJAX requests were simply returning the binary data and the page was trying to output all of this onto the page rather than deliver as a download.
3) Multiple JavaScript timeouts. This worked for up to 3 downloads, but was very unreliable because if the second Timeout function begun before the first one had started the download, then the whole thing would simply break and not continue.
At this point I'm fresh out of ideas. I tried Googling for similar solutions to the problem but didn't come up with anything and I'm starting to think that it's actually just not possible.
Note that since the content is target at mobile devices, zipping the files up and delivering all at once is not an option since the devices are often unable to decompress the content.
The question, then, is: Is there a way to reliably trigger a web browser to download multiple pieces of content at once?
It turns out that this really isn't possible on mobile devices. Most mobile browsers support the methods involved, but due to the way that each tab of a browser is threaded and paused, it was only possible to fire one download at a time, since any redirect action would interrupt the remaining javascript from processing.
Related
I am trying to load my web page in mobile(IPhone), In chrome browser it taking only 3 seconds but in safari it taking almost 2 minutes to load a entire page, Is there any specific reason for this behavior? If is it so how can I overcome this?
If I had a link to your page I could tell you exactly what is causing the problem.
The second biggest issue with mobile carriers is the number of simultaneous requests allowed. A desktop will download about 6 page resources like CSS, JS, and images (http requests) simultaneously. Mobile, one, maybe two.
The biggest issue is the tower will often drop the radio signal between the phone and the tower between each request. It takes about 2 seconds for the phone to reestablish the connection with the tower.
With mobile it is very important to minimize the number of http requests per page.
You want to make sure your http response header contains a Content: keep-alive for each http request.
Do not have unused CSS selectors.
Much the used CSS is inefficient and bloated by use of over qualified selectors.
Most web pages have multiple CSS files linked in, most unused. Most pages only require a small amount of CSS which could fit withing the pages <head><style> rather than being linked in.
There should never be more than one CSS file.
Javascript should not be used to layout the page. All JS does for layout is alter the HTML and CSS that should be have been done by the page designer. When JS is needed, it should be loaded after the page renders.
I have a simple <input type="file"> in a web form (to be viewed in a browser) and I need it to work on Android (besides other mobile devices and desktop).
Due to a well known but still unfixed bug in Android (https://code.google.com/p/android/issues/detail?id=53088), any such input field may miserably fail to work, because while you are choosing for the file to upload (with whatever application, e.g. the Gallery or a third party file browser), the browser activity is in the background and the system may kill it at any time (no matter how huge your RAM is), and hence the page may reload when the browser activity is restored, and the file you've selected will be forgotten.
This still happens in Chrome on Android 4.4.4.
Of course it does work at times, but not always, and it's unpredictable.
I can think of (painful to implement) workarounds for a webview within a native app, but I can't think of any workaround in pure html+javascript for a web page to be visited by a browser.
The thing is, some workaround must exist, because there are web pages out there with file uploads that never occur into this issue, such as m.facebook.com to name only one. EDIT: forget this paragraph, facebook and twitter are affected as much as every other web page with uploads (and btw, Instagram's mobile web page does not allow upload at all, funny huh?)
Does anyone know what the working workaround is? Or if any exists at all?
Just to be clear, I need a workaround that can be applied by just adjusting the html and/or adding no-matter-how-much javascript code, but without forcing the user to install any specific extra app.
"interesting" problem...
It is not a ready-to-use solution, but you could save the state of the page before requesting a file:
http://www.html5rocks.com/en/features/storage
I've got a page, where I'm showing a video of around 7MB. I implemented a canplaythrough callback on the video. This seemed to work fine until i checked it out on someone's slow internet connection. What I'm actually doing is loading in one big video and skipping through the video to show different little parts of it.
But sometimes it then gets stuck halway and starts partial loading that part again. How can make sure the video is entirely preloaded and that browser won't reload any parts?
You can't. How the video is buffered is not defined in the specifications and it's entirely up to the browser vendors how they implement the buffering mechanism.
The buffering takes into account things such as preload time, network speed but also tries to prevent downloading huge files to the user's computer that would take up unnecessary space on the disk.
That being said - some browsers do currently have some issues with their buffering mechanism such as the Chrome browser which doesn't always work as expected. If you're using Chrome then try with another browser to check how that behave with your code and scenario.
I am building a web application in Node.js, and using Socket.IO to handle data transfer between my client and server sides.
The core piece of my web application is a content feed. My client-side Javascript emits a Socket.IO call for the contents of the newsfeed. Once the response comes back from the server, it populates the feed on the webpage using JQuery.
My issue is that Socket.IO doesn't cause the browser's page loading indicator (for Chrome, this is a spinning wheel in the webpage's tab) to show. I want it to show. Without this loading indicator, my webpage looks like it's finished loading when it really hasn't (the feed hasn't been populated yet).
What is the proper solution to this problem? Thank you in advance!
There is no proper answer per se: browser vendors have different rationales for why certain activities would and would not show "loading" states: A good rundown here.
In general, ajax-like requests (things asynchronous to actual full page loads) should probably NOT show loading indicators by default, as busy states indicate to users that the browser is slow/busy, and we use ajax requests for all sorts of background tasks. There are, of course, times when a developer would want to show these indicators (form submission, single page apps that download subsequent pages via ajax: times when we want to convey to the user that something major is happening and that they SHOULD wait for it to complete) but we don't have a lot of control over forcing that to happen when it comes to async requests. The only real way to "fake" it on some browsers is to load content in an iframe: some modern browsers do trigger the "busy" state in that case.
With Websockets, most vendors have, probably quite reasonably, applied the same logic as ajax requests: there are a lot of operations you'd want to do with websockets that can happen without a user actually initiating them directly, so they shouldn't trigger that "browser is seriously busy, hold on a second" feel. And, like with ajax, there's sadly no api I know of for countermanding that design decision.
The iframe solution is limited: it works in some browsers but not all (notably, it's ignored in all major mobile browsers). And doing it crudely (i.e. creating a hidden iframe for when you want it to trigger the load indicators and removing it when you want to cancel them) has costs: you basically need to hit a resource that is designed to "stall" (like a php page that just runs sleep(10000) and so keeps the connection open). That's both weighty (extra http request just to trigger an effect) and also ties up some server with keeping open connections that are essentially not doing anything. That probably won't scale, particularly if that server is the same one hosting your app.
You're probably instead stuck with coding a custom loading indicator (spinner, fake progress bar fixed at the top of the screen). It's not satisfying, but it's the only thing guaranteed to communicate some of what you want to users. I have a solution for jQuery's ajax that exploits the iframe approach (Noisy JSON) that you could potentially reproduce as a plugin for socket.io, but if you're using websockets, that basically means falling back to ajax-style communication for requests. And you're still out of luck on Safari, mobile, and newer IEs.
I'm looking for tips on how to get the browser to kick off an AJAX call as soon as possible into processing a web page, ideally before the page is fully downloaded.
Here's my approximate motivation: I have a web page that takes, say, 5 seconds to load. It calls a web service that takes, say, 10 seconds to load. If loading the page and calling the web service happened sequentially, the user would have to wait 15 seconds to see all the information. However, if I can get the web service call started before the 5 second page load is complete, then at least some of the work can happened in parallel. Ideally I'd like as much of the work to happen in parallel as possible.
My initial theory was that I should place the AJAX-calling javascript as high up as possible in the web page HTML source (being mindful of putting it after the jquery.js include, because I'm making the call using jquery ajax). I'm also being mindful not to wrap the AJAX call in a jquery ready event handler. (I mention this because ready events are popular in a lot of jquery example code.)
However, the AJAX call still doesn't seem to get kicked off as early as I'm hoping (at least as judged by the Google Chrome "Timeline" feature), so I'm wondering what other considerations apply.
One thing that might potentially be detrimental is that the AJAX call is back to the same web server that's serving the original web page, so I might be in danger of hitting a browser limit on the # of HTTP connections back to that one machine? (The HTML page loads a number of images, css files, etc..)
You can use the jQuery onavailable plugin, which will execute as soon as an element is rendered on the page. You can have it execute once an element that is high up on the page renders.