Domanda

Ok, I'm building a PoC for a mobile application that needs to have offline capabilities, and I have several questions about whether I'm designing the application correctly and also what behavior I will get from the cache manifest.

This question is about including URLs of Controller actions in both the CACHE section of the manifest as well as in the NETWORK section.

I believe I've read some conflicting information online about this. In a few sites I read that including the wild card in the NETWORK section would make the browser try to retrieve everything from the server when it's online, and just use whatever is cached if there is no internet connection.

However, this morning I read the following on Dive into HTML5 : Let's take this offline:

The line marked NETWORK: is the beginning of the “online whitelist” section. Resources in this section are never cached and are not available offline. (Attempting to load them while offline will result in an error.)

So, which information is correct? How would the application behave if I added the URL for a controller action in both the CACHE and the NETWORK sections?

I have a very simple and small PoC working so far, and this is what I've observed regarding this question:

  1. I have a controller action that just generates 4 random numbers and sets them on the ViewBag, and the View will display them on a UL.

  2. I'm not using Output caching at all. The only caching comes from the manifest file.

  3. Before adding the manifest attribute to my Layout.cshtml's html tag, each time I requested the View, I'd get different random numbers every time, and a breakpoint set on the controller action would be hit.

  4. The first time I requested the URL/View after adding the manifest attribute, the breakpoint on the controller is hit 3 times (as opposed to just 1 before). This is already weird and I'll post a separate question about this, I'm just writing it here for reference.

  5. After the manifest and the resources are cached (verified by looking at the Console window on Chrome Dev Tools), everytime I request the View/URL I get the cached version and the breakpoint is never hit again.

This behavior makes me believe that whatever is in the CACHE section will override or ignore anything that is on the NETWORK section, but like I said (and the reason I'm asking here) is because I'm new to working with this and I'm not sure if this is how it's supposed to work or if I'm missing something or not using it correctly.

Any help is greatly appreciated

Here's the relevant section of the cache.manifest:

CACHE MANIFEST
#V1.0
CACHE:
/
/Content/Site.css
/Content/themes/base/jquery-ui.css

NETWORK:
*
/

FALLBACK:
È stato utile?

Soluzione

As it turns out, html5 appcache or manifest caching does work differently than I expected it to.

Here's a quote from whatwg.org, which explains it nicely:

Offline Web Applications

The application cache feature works best if the application logic is separate from the application and user data, with the logic (markup, scripts, style sheets, images, etc) listed in the manifest and stored in the application cache, with a finite number of static HTML pages for the application, and with the application and user data stored in Web Storage or a client-side Indexed Database, updated dynamically using Web Sockets, XMLHttpRequest, server-sent events, or some other similar mechanism.

Legacy applications, however, tend to be designed so that the user data and the logic are mixed together in the HTML, with each operation resulting in a new HTML page from the server.

The mixed-content model does not work well with the application cache feature: since the content is cached, it would result in the user always seeing the stale data from the previous time the cache was updated.

While there is no way to make the legacy model work as fast as the separated model, it can at least be retrofitted for offline use using the prefer-online application cache mode. To do so, list all the static resources used by the HTML page you want to have work offline in an application cache manifest, use the manifest attribute to select that manifest from the HTML file, and then add the following line at the bottom of the manifest:

SETTINGS:
prefer-online
NETWORK:
*

so, as it turns out, application cache is not a good fit for pages with dynamic information that are rendered on the server. whatwg.org calls these type of apps "legacy".

for a natural fit with application cache, you'd need to have only the display and generic logic on your html page and retrieve any dynamic information through ajax requests.

hope this helps.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top