I want to implement something like voip communication that client doesn't need to install additional application, they just open the webpage and talk to a server. Is there anyway to access the audio stream from client microphone via web browser ? I don't want additional plugin like applet that user have to install.
I think flash can do this, but is there anyway else ?
Thank you,
Voteforpedro
Your four main options are:
Flash
Silverlight
ActiveX
Unsecure browser settings (e.g. javascript calling EXEs)
All of the above will be subject to various security limitations or require some acceptance by the end-user. I'm not even certain that the browser calling out to EXEs is even possible any more so it should be avoided at all costs.
Installing an ActiveX control will limit you to IE on Windows, so should probably be avoided. The user would have to agree to installing the ActiveX anyway.
Both Flash and Silverlight are cross-platform (Flash more so than Silverlight) but also require the user to agree to access to the Microphone/Webcam - this is done by the framework, not something you can control/influence. Obviously, if the user does not have Flash or Silverlight installed, you'd need to prompt the user that they need to install it!
As stated by #Oded, there are serious security and privacy issues related to microphone's and webcams, so do not expect future browsers to make this easier for you (e.g. the new family of HTML5 browsers).
There is no standard, I think flash is your best bet.
AS 3.0 Accessing a microphone.
There is no standard that gives you access to the client machine microphone.
I can imagine there are security implication to giving a browser such access, so don't expect to see anything soon, not without some sort of plug-in.
Chrome 11+ supports access to the microphone. Visit this page (with Google Chrome) and click on "Speech" and try it out. This is using Sencha Ext/Touch which is an open library. This specific addon to Sencha Touch is also open source and released here.
Edit: To clarify, this is JavaScript only. The user doesn't need to approve anything. But, it only works in Chrome and it uses Google voice recognition.
Good luck!
Related
When looking up Electron and Offline HTML5, I have found it difficult to make a decision between which one to use for a project.
Assuming that a user will have to go to a certain website to download the Electron application, and would have to go to the same website to get the Offline HTML5 loaded, what are the pros and cons between using one over the other?
Some that I could think of:
Offline HTML5 can be updated without the user consciously updating their application by just making the user go to the online page again.
Electron would eliminate the need to code around multiple browser/browser version dependencies and quirks
It really depends on your exact requirements. The following is a list of everything that I came up with:
electron supports module system (i.e. require) both in main and renderer processes.
electron provides you access to OS APIs (e.g. fs). Without such many node modules will not work in the JS runtime of the browser (e.g. ip).
updating your app with electron is as easy as sending an http request. (or even better as described here)
an HTML 5 offline app requires a browser and the user might just give it IE6.
electron integrates with native desktop environment (see dialog, power-save-blocker, shell or even app for some examples)
electron enhances some of HTML5 APIs such as file API
electron lets you modify the default behavior of underlying chromium. For example you could intercept all URLs with file scheme and modify them on the fly*.
In short if you want your app to have a good native integration and act deterministic (i.e. no browser quirks) I suggest choosing electron.
*electron-jade for example takes use of protocol API to compile all files ending with .jade on the fly without the need to prior compilation.
DISCLAIMER: I am the developer of electron-jade.
(I have a problem with Google Chrome improvements that will drop support for my current solutions.)
I work on project where I move desktop system to an Intranet web application.
The crucial requirements are:
to move desktop system to a web application
to reproduce every single functionality from the desktop system in the webapp
While 95% of work requires creating casual web application, there is one thing which is non-standard to handle: my application must perform some actions on the client computer. These includes:
connecting with libraries
launching desktop apps
file manipulation in background
The example scenario is to integrate my system with some machine in the lab. I have to integrate my web application with drivers on client computer via DLL (desktop app did this, so my app have to do this as well).
Theoretically scenarios of the desktop actions may vary and I just want to implement some interface that will handle all the "client-machine" job the desktop app has done, so there is no need to work on every single scenario (but of course every scenario should be tested).
My solution was Java Applet. It worked. But then Google Chrome decided to drop support for NPAPI plugins, so in September'15 Java plugin (and my applet) won't be supported (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html).
So my another solution is Java Web Start. It works. But now Google Chrome decided to drop support for background operations of external protocols (https://code.google.com/p/chromium/issues/detail?id=348640), so from Google Chrome 45 my Java Web Start solution won't be supported.
(Both above solutions work on Firefox and IE.)
The question:
What other technology can I use to interact with a client machine from my web app?
Other remarks:
I am reluctunt to write my own PPAPI plugin or Chrome Extension - I prefer one solution working on all major browsers.
I know that StackOverflow community does not like discussions about technologies, so please focus on describing possible solution to my problem.
We struggled with a similar problem as we need to connect/access electronic devices over JNI->DLL. The only technology where this is currently possible are applets. Period. (And even that is tricky since certain combinations of browsers/java versions/operating systems do not work or have problems, but this is another story...)
There are web technologies like HTLM5, JScript which can replace some functionalities of applets however in certain scenarios (like yours) there is no current alternative available - and you named some of those:
connecting with libraries like *.dll, *.so etc.
file manipulations
launching applications
And doing that across browsers and operating systems!
Solutions?
Tell your users that certain browsers can't be used (like Chrome and
Opera Next)
Write individual plugins for each browser (which probably is beyond your budget ;-)
Did you consider writing standalone application(s) in form of an executable file? The user must download and run it however e.g. java or plugins also need to be installed. But then there is the security aspect of that (downloading an and executing an executable file) - certainly not an easy decision
Have a look at FireBreath 2 - (just read about it in some posts, however didn't try it)
There are lots of discussions on SO to this topic so take a read:
alternative technologies to replace applets
applet alternative launch from browser
alternatives to java applet to launch microsoft office applications
alternative-java-applet-network-drive-access
what are the alternatives for java applet to launch client programs using chrome
alternative of npapi plugins for flash java applet
python alternative to java applet
npapi alternative for live file editing
... and many, many more!
We are looking for an easy way for our users to download and install a small client widget (it is a windows app) used with our (much larger) web app.
Our web app is currently only supported in Chrome.
Our concern is that the clickonce support piece may be missing from most Chrome installs.
The questions:
-- Is clickonce really going to be useful in this situation?
-- What is the best option for "one click" download-and-install for Chrome on windows?
ClickOnce uses NPAPI which is being removed from Chrome. You will need to look at NaCl, Native Messaging or PPAPI instead of ClickOnce. There used to be browser extensions that you could use, however they have been removed from the store (or no longer work).
Using Chrome should not matter, so yes Click once will be useful in this situation.
The only thing you need to worry about is your clients using Windows and the appropriate version of the .net framework. I hope this helps.
Is it really true that there is no way to support an offline web application using IE8? I wonder how people/companies are getting around this problem (no IE8 support for HTML5 offline features) if they absolutely need to use an IE browser (not IE10) and need to use it when no net connectivity exists. I realize there are plenty of rich client solutions but am curious about any lightweight solutions whereby IE8 would access something like applicationCache. Apparently Google Gears is no longer a solution for this problem. Any other third party solution people would recommend?
Any suggestions would be helpful!
Thanks.
The only currently practical option is Chrome Frame, but this is almost equivalent to just installing a whole new browser.
Perhaps I'm misunderstanding the concept of offline web app, but we routinely use HTML Applications (HTA) to create web apps that operate client-side, accessing the file system and local data stores, and automating local apps.
I read about http://rhomobile.com/ and I found this is great but I want to ask whether the application built with that would run in Browser or Natively on the device as this requires HTML and Ruby?
The application generated using Rhodes are pure Native application... And there is no need to install Ruby on devices as Rhodes will take core of it..
May be this URl is helpful :
http://itsallaboutruby.blogspot.com/2010/08/rhodes-framework.html
Abhishek
Both, actually.
Your application is a web application, but it doesn't run on the internet, it runs on a small webserver that is part of your application inside the phone. It also doesn't run in the browser, but rather in a native browser widget inside your application.
Since the webserver runs on the phone itself, it has access to all the native capabilities of the phone, so you can make HTTP calls to the webserver to capture sound from the microphone, shoot video with the camera, get the GPS location, get multitouch info and so on.