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.
Related
I'm pretty new in the field of Web Store and its content and I've been going through it for past few days. I am not sure if I'm getting it right, but as far as I know, Chrome Apps can be packaged or hosted and also I have noticed that both of them (packaged and hosted) will be removed from the Chrome Web Store on Windows, Mac and Linux.
But, according to this page, there are four types of content which can be published on Chrome Web Store - Websites, Chrome Apps, Extensions and Themes. And it somehow corresponds with the Web Store filters - you can filter between Websites and Chrome Apps.
And my question is - what is the difference between a Website and a hosted Chrome App? Is just Google messing up the terms (and by Website they mean hosted Chrome App and by Chrome App they mean packaged Chrome App) or is there any real difference?
Because this is what is totally confusing for me - in the early 2018, when all the Chrome App stuff will be removed from any other OS than Chrome OS, what am I going to see if I open the Web Store on Windows? Themes and Extensions only? Or the Websites will be available too, because only Chrome Apps will not be supported and a Website is not a Chrome App?
And after the "early 2018", is there going to be any way how to integrate a Website to Chrome other than telling the users to manually bookmark it? It won't be possible to distribute a web app through the Web Store at all? Because what I also noticed is Google encouraging developers to create PWAs rather than Chrome Apps, but how those PWAs can be integrated to Chrome more smoothly than just a manually added bookmark?
Thank you very much for your answers and sorry for a long and chaotic post full of questions.
Karolina
Gonna start by referencing the Wiki descriptions for a Website:
A website is a collection of related web pages, including multimedia content, typically identified with a common domain name, and published on at least one web server. A website may be accessible via a public Internet Protocol (IP) network, such as the Internet, or a private local area network (LAN), by referencing a uniform resource locator (URL) that identifies the site.
and a Google Chrome App:
A Google Chrome App is a web application that runs on the Google Chrome web browser. Chrome apps can be obtained from the Chrome Web Store where apps, extensions, and themes can be installed or bought. There are two types of apps, hosted and packaged, which have different locations of their executable and are targeted at different use cases.
and for Hosted Apps part:
Hosted apps are the original type of Chrome apps. They contain a single manifest file that contains the URL and additional information about the app. Hosted apps are usually offline and are subject to regular web page security restrictions.
To say things simpler, a Website is such a broad term where in some cases, a Hosted Web App might actually fall under it's category.
While a Chrome Web App has this required tie-in with Google Chrome (hence it's name).
For more descriptions on the difference between a Hosted and Packaged App (and an extension:
There are actually two kinds of apps: hosted and packaged. A hosted app wraps an online website, so the CRX package can be as simple as a single manifest.json file pointing to the website. A packaged app contains the whole kit and kaboodle inside the CRX package—HTML, CSS, and so on, all run from the user’s hard drive.
Packaged apps are a kind of missing link between extensions and hosted apps. They look the same as a hosted app to the user, but under the covers, they are really like traditional extensions with that special “launch” parameter. They have access to almost all functionality afforded to regular extensions—context menu, background pages, and so on. The only exception is that packaged apps can't add buttons to the address bar.
Returning to the example in the previous section, it’s perfectly valid for a packaged app to add an item to Google Chrome's context menu. However, it’s completely invalid for a hosted app to do the same thing. In some respects, a packaged app lets you have your cake and eat it: the appearance of a packaged app with the power of an extension. But there are still plenty of reasons to use pure extensions and hosted apps.
Guide for choosing an App Type can be seen here.
For the early 2018 part, there still isn't much details mentioned about it, but referring to the Chromium blog, I guess it's safe to say that the Chrome Web Apps will be totally removed (hence they're asking developers to migrate their Chrome apps to the web) and that only extensions and themes would be available.
However, this could still be subject for change. At this point, no one could really tell.
[...] there are four types of content which can
be published on Chrome Web Store - Websites, Chrome Apps, Extensions
and Themes.
I'd say that is accurate.
Some websites are just simple bookmarks you can find in the Chrome
Store. I consider these little more than advertisements.
Some websites do that and add trivial things like system
notifications and even run offline. I.e. they have their code on your hard drive and access some system resources. But Google still categorises them as websites (or webapps in modern vernacular) probably because they have no special feature set. An example is Spotify or Gmail offline.
Hosted Chrome apps might not have an online presence at all or typically do something different from the website version. For example, they could run in a specially designed transparent window; they may run offline too. An example is Hangouts, the app has slightly different features from the website at hangouts.google.com.
Packaged Chrome apps are defined similarly, but need more access to system resources such as the filesystem. They are pushing the border of what we may define as being 'sandboxed'. They also may run offline. In some cases people who want to write scripts using javascript and html/css may consider this instead of a nodejs-like solution.
what is the difference between a Website[/Webapp)] and a [...]Chrome
App?
Typically the ratio of 'fresh server code' to 'local drive code' gets smaller as you go down the above list, but this is just a correlation. The main difference between a Chrome app and a Web app is a unique content feature-set. Also webapps typically require at least periodic online contact, whereas a chrome app could just be a 100% offline game without an online counterpart.
Is just Google messing up the terms [...] or is there any real
difference?
So yes according to how I see it there is a difference. Though personally, I'd categorise everything that puts code on your local drive as a chrome app and stuff that runs at least 99.9% online as a webapp/website. But Google disagrees apparently.
in the early 2018, [...] what am I going to see if I open the Web
Store on Windows? Themes and Extensions only? Or the Websites will be
available too, because only Chrome Apps will not be supported and a
Website is not a Chrome App?
Only Google knows this I think. But I'm guessing you'll see Websites, and clicking "add to chrome" will create a bookmark for online stuff, or an extension for the offline stuff (like google docs). So you can distribute websites, you just won't be able to find them under an "Apps" panel. We'll also probably see an increase in extensions with a UI component as some apps are re-labelled as extensions.
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.
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...
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)