I noticed that people tended to unload my page by mistake a lot. The page is a series of forms that are displayed via JQuery, and the whole thing will be used almost exclusively offline. Because of the multiple forms approach, it looks to the user like they are navigating through pages, when they are actually just staying on one page all the time.
My first thought about solving the unloading issue was to store the current state into the IndexDB that backs the whole thing (it's almost always offline, so offline storage is the key). This was interesting, but entirely practical. However, there are about four tables that get saved, and this is done the semi-typical IndexDB way using promises. So, in the Unload event, I store everything. This works fine as long as the promises complete before the unload event completes...which ONLY happens in testing. In practice, nothing gets saved because the event method ends and the page unloads before the promises have completed.
Better yet, I'm using Linq2IndexDB, as a nice library for doing the writing, so I'm not dealing with the promises directly.
All is fine as long as the async activity gets a chance to run to completion. I can only think of a few alternatives:
1) A spin wait on a variable set to true in the completion of the last promise (or a counter variable incremented by each completion). This should work, but seems a bit painful.
2) Using BeforeUnload rather than Unload, since that event appears to be intended to allow the cancelation of the unload. This would work, because the unloads that I have seen are accidental unloads due to people hitting the back button out of habit (they know it is only one page, they do it reflexively). Asking them if they really mean to exit would be reasonable, but intrusive.
Is there a better approach?
My first thought about solving the unloading issue was to store the current state into the IndexDB that backs the whole thing (it's almost always offline, so offline storage is the key). This was interesting, but entirely practical. However, there are about four tables that get saved, and this is done the semi-typical IndexDB way using promises. So, in the Unload event, I store everything. This works fine as long as the promises complete before the unload event completes...which ONLY happens in testing. In practice, nothing gets saved because the event method ends and the page unloads before the promises have completed.
Better yet, I'm using Linq2IndexDB, as a nice library for doing the writing, so I'm not dealing with the promises directly.
All is fine as long as the async activity gets a chance to run to completion. I can only think of a few alternatives:
1) A spin wait on a variable set to true in the completion of the last promise (or a counter variable incremented by each completion). This should work, but seems a bit painful.
2) Using BeforeUnload rather than Unload, since that event appears to be intended to allow the cancelation of the unload. This would work, because the unloads that I have seen are accidental unloads due to people hitting the back button out of habit (they know it is only one page, they do it reflexively). Asking them if they really mean to exit would be reasonable, but intrusive.
Is there a better approach?