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/
Related
I would like to publish an app in google play, but I want to restrict the downloading under password or something like that. Is it possible? Is there any alternative?
Many thanks in advance,
Short Answer:
No.
Slightly Long Answer:
Applications available on Google Play cannot be downloaded only after a user authenticates. Any such feature will have to be implemented withing your application. At best, if this feature is needed for monetary reasons, publish a paid application.
Since the OP isn't descriptive beyond what you are looking for as a feature, it will be difficult to suggest an option / alternative that might suit your requirement. However, if you have a server setup that can communicate with the app, you can implement a feature which requires users, upon installation and running your app, to Sign Up for a new account and/or Login if already registered.
Again, I will circle back to the original point. Any such feature will have to implemented within the application itself. Google Play does not have such a feature.
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.
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.
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)