I am developing a chrome extension/app that requires
communicate with Intranet services in UDP binary protocol using chrome.socket APIs
need to extract DOM content from non-app web pages. This could be done using bookmarklet, Browser Actions, page actions, or chrome context menus.
There are two chrome.contextMenus APIs
http://developer.chrome.com/apps/contextMenus.html
http://developer.chrome.com/extensions/contextMenus.html
One for Packaged App, another for Extensions. The former only insert contextMenus to Packages Apps, not normal web pages.
If I need both chrome.socket & invoking from normal webpage capability, do I need to create both an extension as well as an app? That would be very confusing to end users.
Yes, you need both the app and the extension. Apps are intentionally devoid of APIs that modify web pages. That's where extensions come in.
I ran into the same problem and had to make two separate apps for exactly the same reasons. (JSTorrent contextmenu extension && JSTorrent).
I believe there are ways to trigger the install dialog from one to the other, but I have not tried to do this yet. If somebody had examples for how to do this, that would be great to add here!
Consider using <webview> in an app. You'll be able to display web content there, and you can more easily communicate between the app and the content. It will result in a single installable item.
Related
if we had a responsive web site with HTML, Css and Nodejs for it's back-end, can we make it to act like PWA application?
- I know the difference will the Service-worker file, but i wanna to find out is it the exact difference?
Here is the difference between PWA(Progressive Web Application) and RWD(Responsive Web Design):
PWA
Users access the website through any browser, and on a supported
browser (Chrome, Firefox, Safari, and even Edge!) it asks the user if
they want to install the web app to their home screen. This lets users
download and the store the website on their devices (which then gets
updated with Service Workers in the background).
RWD
Responsive web design (RWD) basically refers to the practice of
designing a website that can be accessed with any technology you might
use to build a site. RWD allows the website to be fully functional
(and look good) no matter what size screen the user has in front of
them. It has been around since 2001, when Audi launched the first
documented responsive site.
Therefore, PWAs and RWD are not two independent ways to create a website — in fact, PWAs will almost certainly utilize RWD.
Here's some tips:
The best solution is to choose the best solution for your particular site. If you’re looking to maximize those app-like features (like easy home screen app access, offline use, and high-quality, full screen functionality), you may want to choose a PWA.
If you’re looking to maximize site speed and accessibility for the most users, RWD might be the better choice.
If you're asking if you can make a PWA without a service worker then i believe you can't since it (service worker) and the manifest.json file are both required to save an application to the homescreen.
from the google documentation:
In order for a user to be able to install your Progressive Web App, it needs to meet the following criteria:
The web app is not already installed.
and prefer_related_applications is not true.
Meets a user engagement heuristic (currently, the user has interacted with the domain for at least 30 seconds)
Includes a web app manifest that includes:
short_name or name
icons must include a 192px and a 512px sized icons
start_url
display must be one of: fullscreen, standalone, or minimal-ui
Served over HTTPS (required for service workers)
Has registered a service worker with a fetch event handler
Is there an API for a Chrome extension to launch and control new Chrome windows under different user profiles?
My understanding is that while an extension may be run under multiple user profiles simultaneously, these instances are isolated; they cannot communicate directly and an extension in one profile cannot access the windows/tabs/processes/etc of another profile. Is this the case?
It seems like the best way to launch and control Chrome windows under multiple profiles is to use an approach based on the Remote Debugger API such as the ChromeDriver project.
For context, I'm interested in writing a tool to manage and launch predefined "bundles" of multiple Chrome windows, each with different URLs and screen positions, and each under a different profiles. The attached screenshot shows an example desired state: three browsers, each in a separate profile, each at a different URL, with different devtools states, organized in a specific screen layout. It is conceptually similar to tmuxinator.
If I wanted to provide a Chrome-based UI for designing and managing these presaved layouts, it seems that I would need to provide a native shim that invokes new Chromes via chromedriver, and communicate with them via native messaging. Is there a more direct API that I am missing?
It seems that the proposed Profile Extension API would do exactly what I'm interested in, but I don't see any discussion on the apps-dev#chromium.org list.
If chrome allowed this it would be a huge security hole.
Chrome extensions are installed per user account so they shouldnt be able to see anything from other accounts.
It appears that chrome apps are unable to render as tabs in the browser... I happen to like the chrome tabbing interface and it would be a shame to have to try and re-implement it in html/css/js. Is there really no way to do tab management at the chrome application level? Must all new windows be shell/panel level windows?
I can imagine scenarios for applications where they would want to contribute extension related features to the browser... why are you making it more confusing for users (who now have to install an app and an extension) in order to get the full feature set?
Is there really no room for middle-ground here?
Chrome apps are separate from the browser. This is a very deliberate approach, which is unlikely to change.
For apps to be seen as apps, as opposed to websites, which are always available regardless of connectivity, they need to be seen as separate to a browser. We have found having apps launched and run outside the browser very important for users to conceptualize them as apps.
There are also security reasons to keep apps out of the browser. They have access to APIs that websites and extensions do not have access to, but to make this possible they are also individually sandboxed and have no access to the browser.
Extensions and apps can communicate via messages. It is less than ideal that a user may need to install both an app and an extension; we have been looking at some form of bundling to make this simpler.
Is there any good reason why I can't use two of them together?
browser_action
page_action
app
I can't think why single extension can't use browser and page specific actions together. Why should I have to write single extension for each action ...
For a browser that boasts about its simplicity I believe that is the clearest explanation. To prevent clutter.
Packaged Apps is the easiest to explain as they are basically an alternative to Hosted Apps for developers that don't wish to host a service or wish to make their app fully integrated in to Chrome and/or work offline. However, since packaged apps are bundled as extensions this prevents them from adding anything to the browser's chrome since hosted apps don't have this ability.
Regarding the action choice, I can only imagine this restriction is to help prevent extensions from overcrowding the address bar and the toolbar with duplication.
In a lot of cases using badges and the onClicked event correctly can replicate a lot of the functionality of page actions in browser actions while using a combination of content scripts and message passing to trigger changes.
The StumbleUpon extension rotates its browser action's behavior depending on whether or not its toolbar is currently displaying.
Is there any good browser based WebDAV client? If not, is it possible to make one?
Look at the AjaxFileBrowser from ITHit. Pretty slick, and has FireFox & Chrome PUT support for uploading. IE, drag-and-drop from your desktop to the browser. They have a fully functional demo site up at http://www.ajaxbrowser.com.
There's a plugin for Firefox which handles WebDAV.
Webfolders is a firefox extension that gives you the ability to view the contents of WebDAV
servers in the browser and use the full functionality of the WebDAV protocol.
Depends on what you expect the client to do, and whether you're looking for a cross-browser "web application", or a browser extension.
The main issue with doing this in a "web application" (as opposed to a browser extension) is (1) the lack of binary data support in Javascript, and (2) the lack of access to the local file system (which of course is a security feature).
There is webdav-js which can be enabled as a bookmarklet or served by the WebDAV server itself as an HTML page.
It supports the regular listing of files and directories, file upload, directory creation, renaming, as well as in-page display of images and other media.
If by browser based you mean that it runs in html (ie you don't want your users to install a plugin) then the answer is partly yes and mostly no.
Partly yes, because I have built and used one. It uses the jquery jtree plugin to display folders, and selecting a folder node populates a file list in the right hand panel. Panels are done with another jquery plugin, and the file list is made dynamic with the jquery datatables plugin.
But I think for you the answer is probably "no". Thats because for the browser to use webdav is must user webdav "methods" like PROPFIND and MKCOL. These methods just arent supported in most browsers, so your javascript can't use them directly. I have a server-side mapping in my webdav server project which allows my javascript to use normal GET and POST methods, and these requests are transformed on the server to webdav methods.
I said "probably no" for you since this serve side mapping isnt standard, its a part of milton. But if you happen to use milton, or you can use milton, then its all good.
Try SMEStorage.com. They turn any WebDav back-end into a personal cloud file solution. As well as a rich browser desktop and mobile client, there are clients for Mac,Windows, Linux and Mobile clients for Android, iOS, Windows Phone, and BlackBerry.