How to make an asynchronous call in html5 apps .Suppose if i make a async call to get data from server and waiting for response.Meanwhile if i refresh the browser,i will not be able to catch the data b'coz page is reloaded with all variable redefined.so how to get those data even though user refresh the browser or navigate to other page.
Whatever variables are getting redefined, you can store in a temporary session. You can either store the data locally with local storage, store it in javascript with cookies, or store the data server-side and reference it with a cookie session.
At that point, you can just have your code realize it needs to download the data and do that as soon as the page gets refreshed.
Alternatively, you can make it so a confirmation prompt comes up on refresh mentioning their data may be lost.
There is no direct way to implement this. You can try Ajax History, when you refresh the page, a new ajax call will be made.
or try http://ajaxpatterns.org/Unique_URLs
I do not believe that this is possible. Once the user refreshes the browser, then any existing calls will act as though they have been cut off.
You COULD try to write logic such that on every browser refresh you check the server for lost calls, but this will get quite complicated.
Most users tend to know that when they browse away from a page, any existing requests will be lost, though.
Related
Imagine this scenario - A user visits their profile page on URL /user/username and the component that loads on this URL has to make 1 GET request to the API in order to obtain the information about the user with that username. So far so good, however, if the user visits another URL and then decides to come back to the profile page with URL /user/username, the component makes a new GET request for the same information that it got earlier which leads to 2 drawbacks - the information doesn't appear instantly as the component has to wait for the GET request and I'm making a second call to the API.
This is why I am wondering if it's possible to somehow cache that information so that when the user visits his profile page again, the component wouldn't have to make a second GET request. Also this cached information should be able to expire after a certain amount of time like an hour so that it is never inaccurate.
Is this achievable and worth it?
I personally would first try the http-caching solution as mentioned by "Sudhakar RS", but next I would try session storage. There is a vue-sessionstorage plugin as well. Of course your data then would be valid for the session. Should your session be longer than the hour you mention you would have to manually handle that as part of the data you save with a timestamp. There is a sizelimit of I think 5MB for all session storage data. If you need more then I would go with what "Hung Nguyen" suggested.
You can use browser Local Storage or WebSql or IndexedDB to store data on browser but be careful, they has limit size.
You should cache data on server side instead client side, by this way you will have more privilege to manage your data (caching size, flush cache, ...)
I'm currently fooling around with AJAX. Right now, I created a Markdown previewer that updates on change of a textarea. (I guess you know that from somewhere... ;-) ).
Now, I'm trying to figure out, how to update a page upon an event is fired from another client. So to say an asynchron message board. A user writes something, an event is called, the post is written.
But on the other clients' pages, the new post is of course not yet available until they reload and get the updated list of posts from the database.
Now, how can you get this to work asynchronously? So in that moment when one client does something, the other clients all get to know that he did something?
I don't think this can be done completely in AJAX, but I also have no idea whatsoever how to implement this on server-side, as it would require a page reload to inform the other clients of the event.
I'm thinking of creating a file or database entry that hashes the current state of data. Whenever a client loads the page, he saves this hash. Then, a timer (does this exist in JavaScript?) checks for the hash every few seconds.
As soon as anyone changes the databse, the hash is recalculated. If the script sees that the hash was changed and is different to the one saved, it reloads the contents form the database and saves the new hash.
Is that even going to work?
Polling that is light as possible is really the best solution here. Even if you did use a socket or something... That's still basically a live connection waiting around that will likely have to poll itself (albeit in a more effecient way).
20 queries in 10 minutes that have responses like {"updates":false} shouldn't even be putting a dent in your application. I mean imagine someone browsing your site requesting 20 pages and the related images/scripts/etc (even if some caching is involved), there could easily be hundreds of requests requiring all sorts of wasted database queries to information to be displayed on the page they don't actually care about.
You could use polling. For example each client might be sending continuous AJAX requests to the server say each 30 seconds to see if new posts are available and if yes, show them:
setInterval(function() {
// TODO: Send an AJAX request here to the server and fetch new posts.
// if new posts are available update the DOM
}, 30 * 1000);
On the other hand when someone decides to write a new post you send an AJAX (or not AJAX) request to the server to store this post in the database.
Another less commonly used approach is the concept of Comet and the HTML 5 WebSockets implementation which allow the clients to be notified by the server of changes using push.
My Django app displays data from a database. This data changes without user intervention, i.e. behind the scenes. Whenever it changes, I would like the webpage to update the changed sections without a full page reload.
Obviously AJAX springs to mind. When the page is loaded initially (or manually, fully re-loaded later on), the rendered template loads a JavaScript that runs window.onload = update("all"), update(...) in turn triggers a number of XMLHTTPRequests which again return data that gets transformed into HTML pieces for the corresponding sections. All works fine. At the initial page load.
Now I find myself in a Python function that saves a new object to the database.
How do I tell the browser to run update(...) ?
Do I need to somehow manually issue a request to a url that is mapped to a view which in turn renders a template that contains the JavaScript code to run update(...) ??? Oh my!
I feel like I'm not following the usual approaches.
Maybe I'm just standing to close in front of the problem.
Can anyone help me ?
2021 update: Use channels: https://channels.readthedocs.io/en/latest/
You have two choices
Have the browser poll using setTimeout()
Look into Comet -- this is a technique for pushing data from the server to the browser.
Here's an article on Comet in Django
two approaches:
just update the database and wait until the next AJAX query. That means it should do the query periodically, you'll have to balance between immediacy and server load. It helps a little if you can do a cheap query to just verify if there has been an update. Maybe make that check rely only on memcached instead of going to the DB
use comet. In short: the client does an AJAX query asking for the update. the server sees there's no update, so it doesn't answer. Instead, the connection is kept open for a long time. Eventually either the update comes and the server finally answers, or the client times out and kill the connection. In that case, the client should immediately reissue the query to keep waiting for the update.
You can also use The Websocket API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
We have a POST to a PL/SQL database procedure that (a) does some database operations based on the POST parameters and (b) redirects the user to a page showing the results.
The problem is, when the user does a browser "refresh" of the results page, that still has the original request, so it calls the database procedure and resends the parameters.
There are things we can do with saving state so bad things don't happen if the request gets sent in again. But that got me wondering.
Is there a way to tell the browser to set the url to the redirect call, not the original user request? This would probably be in either the redirect itself, or in Javascript on the target page.
You don't mention what you are using to serve the page, but make sure you perform an EXTERNAL redirect. Some platforms will internally redirect within a site.
For instance, with Apache HTTP Server, you need to specify the force-redirect flag in mod_rewrite: http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule
The 4th response here has a decent explanation of this as well.
The canonical solution is described pretty well on Wikipedia. See Post/Redirect/Get. You want the code that's handling the POST to redirect to a GET when it's work is done, as refreshing a GET will not resubmit form data.
I have an ExtJS grid on a web page and I'd like to save some of its state information back to the server when the users leaves the page.
Can I do this with an Ajax request onUnload?
If not, what's a better solution?
You can use an Ajax request, but be sure to make it a synchronous request rather than an asychronous one. Alternatively, simply save state whenever the user makes a change, this also protects the data if the user's browser crashes.
There's an answer above that says to use a synchronous ajax call, and that is the best case scenario. The problem is that unload doesn't work everywhere. If you look here you'll find some tricks to help you get unload events in safari... You could also use Google Gears to save content user side for situations where the user will be coming back, but the only fully safe way to keep that information is to continuously send it as long as the user is on the page or making changes.
You could also set a cookie using javascript on unload. I think the advantage ajax has over cookies is that you have the data available to you for reporting and the user (if logged in) can utilise the data across different machines.
The disadvantage of using ajax is that it might slow down the actual closing of the browser window, which could be annoying if the server is slow to respond.
It depends on how the user leaves the page.
If there is a 'logoff' button in your GUI, you can trigger an ajax request when the user clicks on this button.
Otherwise I do not think it is a good idea to make a request in the onUnload. As said earlier you would have to make a synchronous request...
An alternative to the cookie solution would be an hidden text field. This is a technique usually used by tools such as RSH that deal with history issues that come with ajax.