I've started looking into HTML web database storage for some Chrome extension I'm working on, and it made me wonder - Who should be cleaning abandoned web databases? As opposed to desktop apps, there's no uninstaller for a web site. And as opposed to regular cookies, web databases can be much larger than just 4KB.
I can imagine some browsers or addons might give advanced users a way to clean up locally stored data, but I can't imagine my parents doing that. What will prevent web sites from clogging their hard drive once this feature is commonly used? Is there any way honest and responsible web sites can have their local data removed once they are not used anymore?
On the two websites and 4 apps I use html5 local storage in, I offer an option somewhere (off the About page, or in account settings, or a link at the bottom of the page) which gives you the ability to remove the local database and key-value pairs, as well as the option to opt-out of the site using it.
It'll be persistent, just like cookies. The difference with cookies is that you can store much more data and no expire date can be given.
Firefox has an option to clean those information automatically (Offline storage)
Related
I know that the most Iconic feature of PWA are
Service Worker: which make user can use the app offline from cached resources
Add To Home Screen: With this feature, user can add a shortcut of the app on their mobile home screen, to get a experience like interacting with a Native App(But there still a huge different, in my opinion)
etc.
However, I can do like all of them on about 6/7 years ago by using the HTML5 technology at that time, I know that service worker comes recently but there also was "HTML5 App Cache, as well as the Local Storage, Indexed DB, and the File API specifications." can do similar things.
Is there anyone can explain what's the difference between PWA and HTML5 webapps? or they are just the in term of same? or a similar concept but different implementation? or PWA is the (next gen/extension) of HTML5 webapp?
I might have some misunderstanding on PWAs, since I am new to this term, Thanks.
If keep it simple PWA is ordinary site with 3 additional features.
responsive design - site should look well on all devices
manifest.json - site must have general description about itself stored in manifest.json
caching - site must work offline
I believe 1 and 2 is easey. And 3 is realy what PWA is all about. So the question is: how we can provide offline support?
First problem is how we can get our initial .html .css and .js files without internet connection? Answer is: we should use service worker or App Cache. But App Cache has a lot of problems and probably will be deprecated, in other hand service worker under developement and become better each month. You can read more about their difference here.
Second problem is how we can get server data without internet connection? We should store most vital data somwhere. But after we get our .js file from cache we have access to Local Storage, Indexed DB etc. So we can store vital data in any of this storage while we online and get it back from them when we offline. It is totally up to you how you will handle that.
I believe there no cleare and strict defentiton for PWA and HTML5 webapp (at least for now). So you can asume it is the same but today PWA is more common word.
I created a scheduling software for beauty salons as a web application. The idea is that the business owner can schedule customer appointments with a hair stylist. I made it web based because eventually these beauty salons need to integrated into a larger cloud service. So far, I've only put in about 40 hours of coding.
One challenge i am encountering is that a lot of beauty salons may have poor internet connectivity. They may experience temporary outage that last several hours to several days. But during this time, they still want access to this web application .. at the very least for read only purposes.
I understand that html 5 in modern browsers support offline capabilities via things like localStorage and cache manifest. It appears to me that at the moment, I need to do a drastic rewrite of my existing application to make use of localStorage and cache manifest to allow the web application to work offline. The reason this is so is because my web application writes/saves a lot of information to urls like http://mywebsite.com/api/somefunction?queryparams=value1 via ajax calls. These ajax calls need to be replaced by function calls that write to localstorage.
So my questions are:
a) To enable my web application to work offline (at the very least, read only of the website should be offline), I should replace my ajax calls with calls to localStorage. Is this the best approach?
b) Would it have been better to create this application as a .NET desktop application? Especially if there are microsoft technologies that help with synchronizing stored client data with an external database at a later time?
My opinion:
a) I wouldn't say you should replace your Ajax calls. Rather, you want your code to notice when it is offline and store stuff in localStorage then. You wouldn't always store in localStorage as your clients are going to be online sometimes.
b) That's kind of a loaded question I think. :) So... my thinking is this: Building a web site makes sense as it would let your clients at the salon access their data both from computers in the store and other devices as well. So for example - if the salon's internet access is down, the employees could perhaps use your website via their mobile phones too. Having the data be web bound gives them more ways to get to it.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
What is new in HTML 5’s “offline web applications” feature which was not already available in all browsers?
Offline caching is the job of the browser — how did it become a job of HTML?
A web cache is a mechanism for the
temporary storage (caching) of web
documents, such as HTML pages and
images, to reduce bandwidth usage,
server load, and perceived lag. A web
cache stores copies of documents
passing through it; subsequent
requests may be satisfied from the
cache if certain conditions are met.
As written in Wikipedia’s article for Web cache.
And this is written for offline web cache in the W3C website:
In order to enable users to continue
interacting with Web applications and
documents even when their network
connection is unavailable — for
instance, because they are traveling
outside of their ISP's coverage area —
authors can provide a manifest which
lists the files that are needed for
the Web application to work offline
and which causes the user's browser to
keep a copy of the files for use
offline.
What is HTML 5 doing better and different in caching?
Is it similar to offline mode in Internet Explorer 5? And can we cache the data beyond the limit of amount of space set in browser?
Please give me an example so that I can understand the difference of HTML 5 offline cache, and browser caches.
Web browser caching is when browsers decide to store files locally to improve performance. HTTP allows web servers to suggest browsers how long to store the files for, and allows browsers to ask the server whether a file has changed (so that they can avoid re-downloading it).
However, it’s not designed to reliably store assets required by an offline application. It’s ultimately up to the browser whether, and for how long, it caches the files. And browsers will often stop using their cached version if they can’t contact the server to check that it’s up-to-date.
The HTML5 offline web applications spec provides web authors with the ability to tell browsers what to store for offline access, and requires browsers to keep those files up-to-date when it is online. It also provides a DOM property that tells the developer whether the browser is online or offline, and events that fire when the online status changes.
As Peeter describes in his answer, this allows web app developers to store user-inputted data whilst the user is offline, then sync it with the server when they’re online again. The developer has to do this storage and syncing manually, as the browser only provides the events indicating online status, but if the browser also supports localStorage, the developer can store the data there.
I can do no better than point you to the relevant chapter of Dive into HTML5: http://diveintohtml5.ep.io/offline.html
You can now cache dynamic data, instead of just js/css/html files / images.
Lets say you've got a todo list application open in your browser. You're connected to the internet and you're adding a bunch of stuff you have to do.
Boom, you're on an airplane without a connection. You've got 6 hours of time to kill so you decide to get some work done. You finish all of the things on your todo list (the list was still open in your browser). You select all of the items and change their state to "finished".
Your plane lands, you open up your laptop and refresh the page. All the changes you did without a connection are now synced to the server as you have a internet connection now.
With many browsers adding proper local storage support (and with this whole HTML5 buzz), there is a lot of talk about offline web apps competing with desktop software. But, as a matter of fact - one quick "clear private data" on your browser (which a lot of people do) - clears all the local storage data.
I'm now thinking that local storage in browsers can at best be used to cache data temporarily before being sync-ed with the web server, but truly offline web applications can't rely on HTML5's local storage permanently due to the problem I outlined above.
Is there a scope for offline web applications that actually depend on data extensively?
My take on this is that the offline capability of online web apps can compete with desktop software, but not pure offline web-apps.
Why? Well, the major drawback of online web apps was what happens when you lose your network connection when doing any work. Seeing as this can be resolved now, the competition is truly on. Imagine editing a document online, then move around without internet, come back online and then sync the changes and continue to work as if nothing happened. That is truly awesome.
For this to work, the browser should allow to store data in a location that you can pick which would mean access to OS layer, which will probably not happen anytime soon...