CordovaAppLoader.js - line 173: consider reject() instead of resolve(null) about cordova-app-loader HOT 2 CLOSED

Interesting.

First thought: I expect check() to resolve when it successfully downloads the manifest.

Second thought: It makes sense to reject the manifest in order to tell the outside world: Please re-check the manifest (until it is a new manifest it can try).

Third thought: Re-checking the manifest (outside of the normal schedule) will not help resolve this problem.

The deeper problem is - there are many results of an check():

• Valid response:
  • true: There is a new Manifest available
  • false: There is no new Manifest available.
  • null: There is a new manifest available, but a previous update attempt failed.
• Error conditions:
  • XHR failed for server Manifest (i.e. internet connnection problem)
  • XHR failed for bundled Manifest
  • Cache failed to list files (filesystem errors)
  • Manifest is missing files attribute.

My current logic is:

• on reject(), you should check() again.
• on resolve(), you should deal with the results.
  • when true, you may download and update
  • when false, you can schedule another check later (or do nothing)
  • when null, you can schedule another check later (perhaps a bit faster), or you could reinstall the entire app (i.e. clear cache).

By the way, as a hack, you could clear last_update_files from localStorage after calling download() to ignore this protective measure. I could also make this an option.

from cordova-app-loader.

Totally understand your thinking. Sounds good.

from cordova-app-loader.