2

I have PHP / MySQL front-end that uses some very large forms to collect data. I have the data saving to the database at regular intervals using a JSON post in the background. Occasionally, the user loses connectivity, but continues working. That data is then lost, causing frustration, etc...

Is it possible to have the client transition seamlessly to saving the data in a local file when connectivity is lost, then sync back up to the database once the connection is restored? I know this is not a simple request, I'm just looking to see if it has been done, or could theoretically be done.

Thanks in advance.

user1647550
  • 61
  • 9
  • 1
    You can check if last data part was successfully sent. If not, store it in memory and retry at next interval. – Elon Than Sep 25 '13 at 18:31
  • Look at **[localStorage](http://coding.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/)**. You could implement that in the case of ajax errors. – Reinstate Monica Cellio Sep 25 '13 at 18:31
  • You should also look into [PHP](http://www.xphp.info/php-tutorial/long-polling/) [Long](http://www.nolithius.com/game-development/comet-long-polling-with-php-and-jquery) [Polling](http://stackoverflow.com/questions/333664/simple-long-polling-example-code#answer-333884). It would help solve a lot of your problems if you don't want to use something like [node.js](http://nodejs.org/) – SpYk3HH Sep 25 '13 at 18:39
  • ^ note there is 4 linx there – SpYk3HH Sep 25 '13 at 18:39
  • @SpYk3HH How will you solve problem with loosing data with long polling? Especially that long polling is for fetching data, not sending. – Elon Than Sep 25 '13 at 18:46
  • @ElonThan My simple thought was, you can run a long poll on "connection status". If it's broken, then send a flag to the UI client side thus directing an "alternate course of action". Also he could use it to remove the periodical JSON for saving. In essence check for a connection AND/OR a time server side that is reached, then send flag to UI, causing UI to then make a save. Was just a thought/idea – SpYk3HH Sep 25 '13 at 18:48
  • @SpYk3HH But you can't do that. Long polling with wait for response until it get it or until timeout occur. In first case, connection is up. In second case, connection is maybe up or maybe not, because timeout is normal thing in long polling. – Elon Than Sep 25 '13 at 18:51
  • @ElonThan uhm ... I do it alot in the CRM I wrote for the company I work for ... it seems to work fine for me!? – SpYk3HH Sep 25 '13 at 18:56

1 Answers1

1

You might try to use LocalStorage. You can find basic information about the mechanism here

The simple use would be as follow: 1. When user opens a form you check if there's any data in local storage (and if this data is newer than the one that came from the server) - if it is, load it. 2. Once in a time js tries to send ajax call with update. On failure (connection timeout etc) js just saves the data locally (with timestamp) and tries to save it later.

However you could improve it a bit by saving the form data on every change (or when user moves to another field) into localstorage and running second function once in a while which tries to send this data to the server.

Disadvantage of such solution is that it won't work in older browsers but if you really need to, you can overcome this by replacing LocalStorage by... cookie. It will be terrible ugly but will work as you need.

Community
  • 1
  • 1
Tomasz Kapłoński
  • 1,320
  • 4
  • 24
  • 49
  • 1
    Also, he could use PHP Long Polling to determine "connection" status, and send a return when connection is lost. Thus providing the UI a way to either "tell the user" the connection is currently lost, or to prepare a "local save" from local storage or something of that manner. – SpYk3HH Sep 25 '13 at 18:46
  • It's possible also but I don't think it's good to use long pooling in this situation because it costs quite a lot on the server side because apache has to keep an open connection for each user... – Tomasz Kapłoński Sep 25 '13 at 19:11
  • Perhaps. But it was just an idea, figured he might want to investigate along with your answer. There's never one correct solution, only the solution that works best for you and your "clients" – SpYk3HH Sep 25 '13 at 19:14
  • I agree. I just described better solution (in terms of performance) for this situation - using long pooling just for this seems like using a cannon to kill a fly... :) – Tomasz Kapłoński Sep 25 '13 at 19:16
  • I'm accepting this because, at this moment, it does seems to be the best solution. We are in a closed environment with complete control over servers and clients, so this may work particularly well for us. – user1647550 Sep 25 '13 at 20:01