Could anyone explain how Chrome Extension upgrading works?
Let's say I publish version 0.0.1. After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2? If not, what is the process to sending/updating Chrome Extensions?
Thanks!
After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2?
Yes. By default, if you publish (not just submit a draft, actually publish and wait for the automated review process to complete) a new version then all users will get it.
..eventually.
Chrome does not get push notifications about extension updates; it instead polls the Web Store for version information once every few hours.
While it would be possible for Google to make this push-based, I think this remains in place as a natural load-balancer (not everyone trying to update at once) and a bit of a safety net in case you published something badly broken.
On the extension side, there are 2 things in the chrome.runtime API that can influence the process.
You can force a check for a new version with chrome.runtime.requestUpdateCheck(). Note that this is rate-limited - you can't check too often.
In principle you could use some other method of delivering a notification to your extension (GCM, WebSockets to your server, polling your server etc.) to discover an update and trigger this check.
You can delay an update after it was detected with a listener to chrome.runtime.onUpdateAvailable event. It can be delayed no longer than the next browser restart.
If your extension has a lot of users (this starts at 10k users), there's an additional option available in the Dashboard's edit item interface.
Is it possible to perform a partial roll out in the Chrome web store?
CWS offers an option to only offer this version to a developer-specified percentage of users. This way you can limit the damage from a bad update.
Related
Please tell me if the extension was removed (taken down from Chrome Webstore or account was suspended) after 3 months will be it deleted from the Webstore finally? And will be it removed from computers of all users (which previously installed it) or not?
I guess it would depend on how it was removed.
If a developer unpublishes the extension, it is not deleted from Web Store database, and existing installs will continue to exist but no new installs will happen.
If Google catches a malicious extension, it will be, in addition, remotely disabled on users' machines. It's hard to say if it's "deleted" from Web Store or simply unpublished.
Those are the 2 extreme situations. In-between there can be a whole spectrum. If an extension is delisted pending some changes, I'm not sure what happens with existing installs. Google probably explains that when it notifies a developer.
I don't know whether this question belongs to SO or UX (or Programmers.SE) but here it goes.
We have built a mobile app a couple of months back, which we intend to alter in some major ways (like authentication and security) in next release. We published it to AppStore/PlayStore and it has a download count between 5k-10k range.
Now the question is;
whether if we retire our current API rightaway and show current version users a popup which forces them to update the app (via stores)
or
create a new API under a different URL and maintain both APIs at the same time (in this case should we maintain it forever or should we set up an expiration date) ?
EDIT:
It'll be our first and possibly last update, since our app is a cordova based hybrid app, we intend to use silent cloud deployments without relying on app stores.
I would say - for a mobile application, forcing your users to upgrade straight away isn't a unreasonable expectation. The exception to that is if you have users on an older operating system (e.g. old iOS) that cannot upgrade. Then you might want to maintain a legacy API.
Can you give a legitimate reason why a reasonable user wouldn't be prepared to update your app?
I'm trying to develop a Google Chrome Extension app VoIP softphone. I will be using the Inline Installation feature (https://developer.chrome.com/webstore/inline_installation) and will be publishing on the Chrome Developer Dashboard (https://chrome.google.com/webstore/developer/dashboard)
My problem is due to the nature of the softphone that has to be always connected, every time I need to publish an updated version of the softphone users will be disconnected, and this will be a big hit on user experience.
Anyone ran into the same issues in publishing a softphone extension app in Google Chrome?
An update may be downloaded at any time, but an extension is only reloaded when the background page goes inactive.
I guess that you're using Web sockets for signaling. Since the connection need to be available at all times, you are probably using a persistent background page. This is enough to prevent a sudden unload. If you use event pages, then you need to jump through some hoops to get the page to stay alive even if the Web Socket is not busy all the time (crbug.com/204573), but also in this case, the extension will not suddenly be reloaded.
If you do want to reload an extension after an update, add a chrome.runtime.onUpdateAvailable listener and call chrome.runtime.reload when it is convenient (e.g. when the user has unregistered their soft phone, and/or when the user is idle, etc.).
The dashboard provides the ability to ramp up your updates. So only a small percentage of users will be affected at any time under your control.
In addition to the a slow ramp you can do it during off hours to minimize user experience.
This won't solve for disconnections during the update but could minimize the impact.
I'm developing a Chrome App (as a packaged app/extension) which purpose is to act as the base platform for several fullscreen apps to be build on top of. Chrome will be running on Ubuntu Linux.
And no trouble so far. But then I was told, that an intended app it is to be the platform for requires the source code to be updated with very short notice, as it probably is to be deployed for large scale use before the system has been tested through (even though it's a bad idea to deploy software that's not completely stable, but we're on a tight schedule). The problem is, that the "a few hours" interval for the autoupdating mechanism just isn't good enough.
So I somehow need to have the updating interval changed. I know this can be done with the --extensions-update-frequency command line switch, but as apps cannot access the command line (for obvious security reasons), and I'd prefer that the intended background page was to handle all the "administration", I don't think that switch is possible to use.
Is it somehow possible to update at a higher frequency? Or at times when it's ordered to?
There is now a method chrome.runtime.requestUpdateCheck():
Requests an update check for this app/extension.
It will return a status, which can be either "no_update", "update_available" or "throttled".
Unfortunately, the docs do not specify the limits for frequency that will trigger "throttled".
Your best option will be to have the extension manually check with your servers for an updated version. If there is an updated version show the user a desktop notification to manually update.
Potentially you could write a NPAPI plugin to modify the update frequency.
This may cause issues with CSP but you can try to live load JavaScript from your server that executes in the extension. In this case to "update" your extension you would simply update the JS hosted on your servers and the extension would automatically start using it on next load.
How do I setup the basic switching of offline storage modes (offline/online) in Web SQL? I know there's javascript
window.navigator.onLine. I can check the mode and then go through a process...
//All GET/POST performed with AJAX
//On Startup pulldown entire accessible database into offline storage (Doesn't seem secure IMO)
//if(read) pull from offline
//if(create, update, delete and online) pull from standard db, mark changes with offline expiration flag
//if(create, update, delete and offline) perform operation on offline storage, persist with POST when next online (change flag)
I'm asking if there is any OOB integration for these standard tasks?
The navigator.online property generally isn't very useful - in a desktop browser all it does is hook into the File -> Work Offline menu. It may be more useful on an iPad, I don't know because I don't have one, and I'm guessing there's not a File menu, but I would recommend you test.
A common approach to this issue is to set up two easily distinguishable files in the fallback section of your manifest. Every time you want to connect back to the server attempt to fetch the file with AJAX and, in the callback, check it to see if you got the online file or the fallback, then branch accordingly.
You shouldn't be using Web SQL as that spec was nixed a new months ago. You should be using Localstorage. Unless you are specifically coding for something like the iphone, but even then you dont know how long the spec will be in webkit.