I have an extension where users maintain a list of links. It would be nice to have this data synchronized between computers (at work and at home). What are the possible solutions?
Chrome has extension synchronization option but I am not sure if it synchronizes data or not (I would be surprised if yes). Even if it does, not everyone would want all their other extensions be synced.
I can store my links in a special bookmark folder and use built-in bookmark synchronization, but in this case all bookmarks would be synchronized too (not all users would want that either I think).
Any external sites I can use? Something easy to use and linked to a google account?
(I don't want to build my own site for this)
Edit: As of Chrome 20 and above you can use chrome.storage module to save to the cloud.
chrome.experimental.storage.sync.set({'settingAlwaysOn': true}, function() {
console.log('Saved option in the cloud');
});
Before Chrome 20
You're right, the Chrome Sync for extensions options (in settings) does not synchronize extension data. The only way to synchronize those data is through a third party.
Since you ruled out the usage of Bookmarks, which makes sense if users don't want bookmarks to be synchronized.
Everytime you persist data through storage (Web SQL Storage, localStorage, IndexDB), you grab that object, and serialize it into JSON (via JSON.stringify), and you send it to some online service such as Google Docs.
That would be quite tricky for Web SQL Storage and IndexDB, you would have to do your own importer and exporter. For localStorage it is pretty simple, since its a key/value pair.
It requires some work to link it to a Google Account (such as Docs) you would have to use OAuth and do the plumbing to connect your extension to the service. Once your connected, it is not that difficult to maintain the state.
Good luck :)
Chrome 20 supports chrome.storage.sync API. It seems to fit your requirements perfectly.
Related
I am currently working on an interaction event tracker for websites. One feature I am looking at adding is the capability to store specific values of elements on the pages and store them in the browser with indexedDb API.
As an extension, I would love to implement a cross-browser implementation so that I can carry the values with me across multiple machines (I use chrome on mac, personal and business machines). I know there are limitations to what indexedDB can do but isn't there a way to carry the indexedDB database between browsers till I am logged into the same account in Chrome?
Any help or direction will be truly appreciated!
I don't know if anyone got a chance to look into this but I found out that "storage" API allows you to do what I want, i.e, store data that sync over the cloud
User data can be automatically synced with Chrome sync (using storage.sync). Your extension's content scripts can directly access user data without the need for a background page.
I hope this helps anyone who goes down this path
https://developer.chrome.com/docs/extensions/reference/storage/
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.
Curious if anyone's seen/heard anything on the ability to use Chrome Profiles to allow synchronization of data contained within extensions between computers.
Put another way, I would like the ability to synchronize / access localStorage from multiple computers signed in with the same browser profile.
Nothing from Google on this now, AFAIK. Anyone know any differnetly?
Chrome has an experimental API that allows syncing of data. Hopefully it will be in stable within the next couple of months.
For storing data offline WebApp can use:
session storage, "advanced version of cookies"
key/value based Web Storage (AKA local/global/offline/DOM storage)
sql-based Web SQL Database (deprecated) and Indexed Database API
FileReader and FileWriter API (requires user to select files each time the application loads)
But apparently there is no File Storage. Of course, there is a manifest-based caching, but it's just a cache and is not supposed to be used as a user data storage.
Does it mean that the user of WebApp is forced to use some sort of a cloud file storage?
Is there any way to save large files on user's local machine? Or maybe some way to select a local folder web application can use to store user data?
Edit. Security. HTML5 already has the ability to write big portions of data to user's local machine. I don't see any security issues if a browser will provide another, file-based abstraction to store data. It can be some virtual machine, virtual filesystem, whatever.
Hm, I think, it is possible to write JS filesystem and store it as a blob in SQL...
Similar questions.
Update:
Hm... recently I've found this and this. Maybe it is what I'm looking for... Yes, it is! See the answer below.
At last, I've found it! Here's the answer:
I’ll have the DOMFileSystem with a side of read/write access please wrote:
Eric Uhrhane of Google has been
working on the working draft of the
File API: Directories and System specification which defines a set of
APIs to create a sandboxed filesystem
where a web app can read and write
data to.
Wow! I'm so excited!
Why not use localStorage while the user is editing a document and the FileWriter API when they want to save it to disk? Most people are used to seeing a save dialog pop up when saving a document.
The only scenario I can think of that warrants userless access to the FileWriter API is an autosave feature, but autosaving to localStorage can be just as good.
There is a way to save relatively large files to a users hard drive if you are willing to use Flash. Look into Downloadify:
http://www.bitrepository.com/downloadify-client-side-file-generation.html
Downloadify allows you to send data to a SWF and have that SWF create a file on the users machine. My recommendation would be to store the data via one of the methods you listed, Webstorage, sqlite database, etc. Put all your assets, including the SWF in the manifest file so everything is cached locally to the browser. You can then pull information from your db or webstorage and use the SWF to create the files you need.
I'm not sure if you will be able to read these files back into your web application.
Another option to save data is by using link tags with the data URI scheme. However, I'm not sure if it is supported in all the major browsers at the moment.
For security reasons you can't write files to a user's local filesystem in case it gets used for nefarious purposes by evil people.
That's not likely to change, and that's a good thing.
The HTML5 FileSystem API started landing in Chrome 8 and is fairly complete as of now (Chrome 11).
There's a nice tutorial on it here: http://www.html5rocks.com/tutorials/file/filesystem/
http://fsojs.com wraps the FileSystem API effectively, if you want an easy solution
As mentioned by others here, the FileWriter and FileSystem APIs can be used to store files on a client's machine from the context of a browser tab/window.
However, there are several things pertaining to these APIs which you should be aware of:
Implementations of the APIs currently exist only in Chromium-based browsers (Chrome & Opera)
Both of the APIs were taken off of the W3C standards track on April 24, 2014, and as of now are proprietary
Removal of the (now proprietary) APIs from implementing browsers in the future is a possibility
A sandbox (a location on disk outside of which files can produce no effect) is used to store the files created with the APIs
A virtual file system (a directory structure which does not necessarily exist on disk in the same form that it does when accessed from within the browser) is used represent the files created with the APIs
IsolatedStorage, which hasn't been mentioned as of yet, also allows for file i/o from a tab/window context, but it is made available through solely through Silverlight and requires the use of managed code to access. It, like FileSystem, also exists in a sandbox and makes use of a virtual file system.
Given the high market penetration of both Chromium-based browsers and Silverlight (support for which, interestingly enough has been dropped by such browsers), you may find a solution which uses the first of the above approaches available on a client machine satisfactory.
BakedGoods, a Javascript library that establishes a uniform interface that can be used to conduct common storage operations in all native (including FileSystem), and some non-native (including IsolatedStorage) storage facilities, is an example of such a solution:
//Write file to first of either FileSystem or IsolatedStorage
bakedGoods.set({
data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
storageTypes: ["fileSystem", "silverlight"],
options: {fileSystem:{storageType: Window.PERSISTENT}},
complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});
Just for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
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)