I'm building a packaged app that's meant to interact with a website I wrote to get its localStorage data and send it to other devices using bluetooth. This seems like it would be easy with an extension, however with an extension I would not have access to chrome's bluetooth API. I'm not sure this is even possible, but if it is, how would I go about accessing and communicating with the website using the packaged app?
The answer is that you can't. The two local storage repositories are distinct ("sandboxed"), and one can't access the other.
If this website wants to make data available to any other website, or to a Chrome App, it should put it someplace on the server, accessible via a URL, and then the Chrome App can easily access it. But, there's no way to effect such sharing with the data on the client.
Two Chrome Apps can share data locally, because they can access the local file system. However, web apps (HTML/JavaScript loaded from a server) can't access the local file system, only a sandboxed file system.
Related
I'm trying to determine if I can access any browser api for chrome OS that will allow me to identify the device that its running on when the application has been force-installed in kiosk mode as a PWA.
We're running into exactly the same issue right now. The correct path seems to be to create a PWA and to connect it to a (pre-installed) extension that has access to the enterprise.deviceAttributes:
See https://developers.chrome.com/apps/migration:
"If there is a capability that your Chrome App has that the regular web platform can't provide, it might be available as an extension API. In this case, you use a progressive web app together with an externally connectable extension your web app can send messages to."
enterprise.deviceAttributes are only accessible if the calling App/Site is pre-installed to the device and not loaded dynamically, so it cannot run in the PWA by design.
But with this tutorial, it seems possible:
https://developer.chrome.com/extensions/messaging#external-webpage
We're looking into that right now and will post our progess here.
I have (had) a hosted app in the Chrome Web Store, built using the following Developer documentation:
https://developers.google.com/chrome/apps/docs/developers_guide
After being in the Chrome Web Store for years, I recently received an email saying my app does not comply:
Your item did not comply with the following section of our policy:
Do not post an app where the primary functionality is to install or
launch another app, theme, or extension. For example, if your app’s
primary function is to launch a desktop app that the user has already
installed, that is not allowed. Another example is a packaged app that
just launches a website.
My question is: Did the rules change? A Hosted App IS an app that launches a website. Does anyone know what to change in a Hosted App to make it compliant again?
A Hosted App, a Chrome App (successor to Packaged App), and a Chrome Extension are three separate things, distinguished by how their manifest.json file is set up. What this email appears to be saying is that you're not allowed to have a Chrome App (which they call a packaged app) whose only purpose is to launch another app or a web site. They are saying nothing about Hosted Apps, which continue to be allowed, as far as I know. (I have one in the Chrome Web Store myself.)
Is your app truly a Hosted App? Or, is it a (legacy) packaged app or a Chrome App?
If I write a web app that will run in Chrome or Firefox and uses IndexedDB (or localStorage), but it's not hosted anywhere and instead is run by the user double-clicking a local ".html" file, will the limits on storage size still apply?
I'm referring to this:
https://developers.google.com/chrome/whitepapers/storage#unlimited
[Unlimited Storage is] unique to Chrome extensions as well as hosted and installed web apps.
If it is not hosted, indexeddb won't work. The indexeddb is origin dependend, meaning it needs to have an address. Local file system doesn't meet that requirement.
Webapps are a different story, but these apps need to be installed and run inside a sandbox.
In my packaged app I would like to open pdf's stored in local filesystem. I've managed to open them if I select them using chrome.fileSystem.chooseEntry, but I can't find a way to do the same if the filesnames are hard coded.
The idea behind is an app that manages book information and allows to open them if they are stored in the local filesystem. Thanks a lot!
This can't be done, for good reason. Packaged apps have a security model based on the open web. Web pages can't access your local files without your permission (i.e., without a "user gesture" or a specific user action such as going through a file chooser), and packaged apps have the same restriction.
You could import local files (again using a user gesture) into the HTML5 file system, or into chrome.syncFileSystem. Then you'd have gestureless access to the imported copies. Likewise, you could export from either of those file systems to the local file system, again with a user gesture. But the boundary between local files and your app's access to them is meant to be loud and explicit.
I am currently building an intranet applicaiton using asp.net mvc and I am wondering if there is a way to link to a file or folder available on the network.
I tried simply
open folder
But obviously that won't work as it just gives the output: file:///G:/folder/ which doesn't actually open to anywhere. I understand that this is for security and that is fine, i am jsut wondering if there are any workaround or anything in an intranet setup? Would impersonation of any type possibly work? Any other ideas?
You could open that file from the server, and serve it to the client. Your web server will act as a proxy. If the files are accessible to the server, and there are no special permissions for the users, or if you can encode those permissions in roles or business rules, then it's quite easy.