Imagine you're on a plane with no internet connection. You try to open a web application you've visited before, and it loads. How is this possible?
The technology behind this is HTML5 AppCache. It’s a system that allows websites or applications to store certain files in the browser, enabling them to work offline.
When developing a hybrid mobile application, you'll inevitably ask, "What happens if the user has no internet?" Your first thought might be AppCache. However, the process isn't as seamless as it sounds.
If you're wondering how HTML5 AppCache works, the core of the system is a file with an .appcache extension. This manifest file specifies which resources (like HTML, JS, and CSS files) should be cached. The browser reads this list and stores the files locally. This way, even without an internet connection, the page appears to load.
However, AppCache has some frustrating downsides. For instance, once a page is cached, forcing it to fetch a new version is difficult. A user might unknowingly be stuck with stale content. If you've ever wondered, "Why am I still seeing old information on this page?" AppCache could be the culprit.
For this reason, it is no longer recommended. Its replacement, the Service Worker, is far more flexible and powerful.
It's important to note, though, that you might still encounter AppCache in legacy projects or certain hybrid apps. Traces of AppCache can still be found, especially in some Android applications that display content using a WebView.
In summary, AppCache was a well-intentioned but flawed technology. Still, it paved the way for the offline web applications we have today.
What content does an AppCache file contain and how does it work?
At first glance, AppCache can seem a bit complex. This file, with its .appcache extension, is essentially a manifest. Think of it as a list that instructs the browser, "Cache these files, but not those."
The content itself isn't highly technical. A sample file looks like this:
CACHE MANIFEST
/index.html
/styles.css
/app.js
NETWORK:
*This tells the browser: "Save index.html, styles.css, and app.js locally. For all other requests, connect to the internet."
While this seems simple, for the system to work, your HTML page must also include a line like this:
<html manifest="my.appcache">This attribute allows the browser to find the .appcache file and begin downloading the resources listed inside. When the user revisits the page, this content will load even without an internet connection.
The manifest file only contains the paths to the resources to be cached—it doesn't contain the content of the HTML, CSS, or JS files themselves. But these paths tell the browser what to store.
There's another catch: AppCache doesn't behave consistently across all browsers. In fact, many modern browsers no longer support it at all. So, if you're asking, "what to use instead of html5 appcache," the answer is clear: Service Worker. We'll get to that shortly.
Now, let's shift our focus to the mobile side, specifically Android, where AppCache sometimes makes an appearance.
What is a content:// URI in Android and what is its role in the AppBlock app?
One day, I came across something like this inside an application:
content://cz.mobilesoft.appblock.fileprovider/cache/blank.html
Initially, I couldn't figure out its purpose, but some research revealed interesting details.
In the Android ecosystem, URIs starting with content:// are a standard way for the system to handle file access. Specifically, if you want to access a file from another application, you do so through a FileProvider. You can think of it as a secure gateway between apps.
For example, in the URI content://cz.mobilesoft.appblock.fileprovider/..., the cz.mobilesoft.appblock part identifies the AppBlock application. What does AppBlock do? It blocks social media or other distracting applications. It can modify or redirect content to prevent users from opening certain apps at specific times.
Now, let's return to the blank.html file.
This is typically used in the following way: when an application tries to open a web page, but AppBlock is active, a blank page is served instead. The user is redirected without even noticing.
That moment when something was supposed to open but you were left with a blank screen… blank.html might have been at play.
Files like this are stored in the cache directory by applications like AppBlock and are called using this URI structure:
content://.../cache/blank.html
But be aware: accessing this file directly is not easy. These content:// URIs can only be accessed by applications with the proper permissions. If you try to access this file from your own app without the necessary permissions, the system will deny access.
Another thing that caught my attention was that some users believe this file blocks their internet connection. The reality is different. Apps like AppBlock intervene visually by displaying blank pages instead of distracting content. It doesn't kill the connection; it just makes the page appear empty.
Can HTML5 AppCache content be retrieved programmatically?
The short answer is no, but let's elaborate, as the topic is more complex than it seems.
The AppCache manifest is a simple text file listing the paths of files to be cached. If you open this file manually in your browser (e.g., by navigating to https://sitename.com/my.appcache), it will be displayed as plain text. You can also fetch its content as text using fetch or XMLHttpRequest.
The problem is that AppCache is processed automatically by the browser. When you include the <html manifest="my.appcache"> attribute, the browser fetches that file and handles the caching process internally.
You cannot directly access this cached content from within your JavaScript.
Let's say you've cached a .jpg or .js file with AppCache. If you then try to read the contents of that file with JavaScript, the system won't allow it.
Why? Security. The browser wants to maintain control over the cache rather than handing it over to the developer. While this prevents certain issues, it's a major limitation for developers who need more control.
I once tried to track files loaded via AppCache using the applicationCache API and then process their content with JavaScript. However, I soon realized that AppCache was not designed for this kind of programmatic access or data retrieval.
AppCache operates silently in the browser's caching layer, like an invisible hand. It's hard to know when it's active or when it's updating. This unpredictability is why it has been heavily criticized over the years.
If you truly need programmatic access to the cache, you should not use AppCache. Instead, you need to use a Service Worker, which gives you the power to intercept fetch events, access the cache, and manipulate it as you see fit.
Why is AppCache support being deprecated and what replaced it?
When AppCache was first announced, it generated a lot of excitement. Imagine your web application working even without an internet connection! At the time, this felt like a huge step toward bridging the gap with native mobile apps.
But over time, the system started causing problems for both developers and users. Once AppCache cached a resource, getting users to see an updated version often required them to refresh the page multiple times. This process was completely invisible to the user. When does it update? When is old content deleted? It was all uncertain.
This is why AppCache began to receive serious criticism. Browsers were caching things, but developers had no control over when or how.
The internet filled with questions like:
- appcache not updating
- page stuck on old version due to appcache
- how to clear appcache file
Another issue was security. AppCache granted offline access to cached pages by default. This meant a malicious actor could potentially serve unwanted content to a user even when they were offline.
Faced with these problems, major browser developers like Google, Mozilla, and Apple said, "Enough is enough."
Starting in 2020, browsers began to deprecate AppCache support entirely. While it might still appear to work on some older systems, most modern browsers now completely ignore the .appcache manifest file.
So, what replaced it?
The Service Worker came to the rescue. A Service Worker is a script that runs in the background of the browser, separate from the web page, and gives you full control over network requests and cache management.
Now, you, not the browser, get to decide:
- What gets cached
- When it gets deleted
- What to show the user when they are offline
Believe me, the control, security, and modernity offered by Service Workers are far superior.
So, if you are still using AppCache in an old project, it is definitely time to move on. For new projects, adopting Service Workers is an essential step.
What is the difference between a Service Worker and HTML5 AppCache?
Both technologies try to solve the same problem: making a web application run in an offline environment. But their approaches are fundamentally different.
AppCache operates on a "give me a list, and I'll handle the rest" philosophy. You tell it what to cache in the .appcache file, and the browser manages the rest internally. But this comes with a major drawback: you have almost no control.
For example, with AppCache, you can't easily answer:
- When will the cache be updated?
- How long will a file be stored?
- What should be displayed in an offline state?
Service Worker is the complete opposite. It gives you step-by-step control over everything.
When I first started using it, I thought, "Do I really have to manage every little detail?" Yes, it requires a bit more setup, but the payoff is enormous.
Developing an offline web application with a Service Worker has become a standard, especially in the world of Progressive Web Apps (PWA). This is because:
- You can intercept network requests (using the fetch event).
- You decide what to add to the cache.
- You can clear the cache whenever you want.
- You can control the update process.
For instance, you can serve a custom offline.html page when the user is offline. This level of granular control is simply not possible with AppCache.
Conclusion
Although HTML5 AppCache helped pioneer offline functionality for web apps, it introduced more limitations than solutions. Today, Service Workers offer a smarter, more flexible way to control caching, handle network requests, and create true offline-first applications. If you're still relying on AppCache, now is the perfect time to migrate and future-proof your project.
Comments (0)
Sign in to comment
Report