Is there a way to programmatically list available input devices and allow to change the current one being used for the WebSpeech API?
I'm aware Chrome shows a video icon on the address bar where a device can be chosen, but I want to make this setting available on the web app itself.
Yes, there's a way- take a look at https://webaudiodemos.appspot.com/input/index.html, it lets the user select the input. PS: This works just for chrome.
Also you can look this example using webrtc, however I'm not sure if it can be integrated with webspeechapi: https://webrtc.github.io/samples/src/content/devices/input-output/
Also, take a look at this post: https://developers.google.com/web/updates/2015/10/media-devices It has a lot of information
Sorry to burst your buble but it can't be done, the only way to have access to the devices is using the system API's and the web browser limits your access to specific API's that he chooses to expose, unfortunately for you the device related ones are not exposed.
On a side note, think of the repercussions of exposing your devices to every website you visit...
Related
Can PWA access contacts, gps or use the phone camera?
Is this possible in any system (ios, android) ?
Is there any plan in development to implement any of these features ?
There are some restrictions that cannot be overcome with a PWA:
- you cannot access the contacts list on a phone. - On the other hand, you can take photos and use GPS location.
On whatwebcando.today web site you can have a list of APIs available via browser compared to native apps. If you click on one feature, you can see a sample snippet showing how you can implement it and also details about the browsers support.
UPDATE 30.09.2019
From Chrome v77 there is a new experimental API available: Contact Picker
The Contact Picker API is an on-demand API that allows users to select entries from their contact list and share limited details of the selected entries with a website. It allows users to share only what they want, when they want.
For example, a web-based email client could use the Contact Picker API to select the recipient(s) of an email. A voice-over-IP app could look up which phone number to call.
Hence it might be that the the remaining PWA restrictions will be solved in a near future.
It depends on the device the PWA is running on.
Camera and audio seem to be universally supported. Contacts, on the other hand, seem to be inaccessible regardless of platform.
Other features, such as GPS and geolocation may vary from device to device.
A good way to find out what your browser is capable of (and thus your PWA - it runs in a web browser) is to go to https://whatwebcando.today with the browser you want to support. Try visiting it with an iPhone, Android or other device for a list of enabled features.
This list changes as browser and OS developers increase access to native features, so there's a good change that if it isn't available now, it will be in the future. However, it's important to be aware that some features such as access to the wider file system and hardware configuration are likely to remain sandboxed for security reasons.
I have recently posted a question regarding getting the user location which I thought I had solved using geolocation.GeoLocationProvider. However, I am having strange behaviour on different devices. On an iphone 5s, I get the most accurate and smallest circle marking my position. On a galaxy S3 I get very large circles and takes long to connect. I then connected a Nexus to my mobile over bluetooth and shared 3G internet. Funnily enough, my position was not showing at all. In all 3 cases, I tried going into bing maps and google maps and they all have shown my position very accurately. Is there anything I am skipping for this discrepancy between my code and bing/google maps' code?
Thanks you all,
Justin
The Bing Maps site uses the same functionality. All this does is wrap the different web based geolocation API's for different browsers into one easy to use class. This method pulls the location from the browser built-in geolocation functionality (older browsers had several different ways of doing this). This will make use of a GPS device if it has access (small circle), fall back to WIFI or IP address (large circles). A couple of things worth checking, if this is being used in an app, have you enabled access to the geolocation sensors? If this is being used in as a web app through the browser, did you get a prompt to allow access to your location and did you press Allow? If the device isn't able to access the GPS and it's using share WIFI from another phone I could see how this might confuse things.
Another option is to use the HTML5 geolocation API: http://www.w3schools.com/HTML/html5_geolocation.asp
I am working on an app that needs to add a wifi network (i.e., SSID and password) to the list of known ones of the mobile phone, so that it connects to that network automatically even when seeing it for the first time.
I already did this on Android, and now I will start working on the iPhone version.
Question: On the iPhone, is it possible to have my app (when it runs for the first time) add a wifi network to the list of known ones of the device, and if so, any hints regarding how to do it?
Thanks a lot.
Unfortunately this is not possible on iOS.
Apple doesn't provide any public APIs to add network SSIDs or passwords.
The most you can do is to enable your app to manage the user's authentication for a public network, (as is done for things like Boingo and The Cloud). In this case, when the user joins a network, instead of a webpage opening to authenticate, your app can launch and provide the authentication - but that is as far as you can go.
We asked for clarification on this point to Apple in the dev forums and were told that it is definitely not possible. (I will try to dig out the link to that post for you when I get more time. Else, search your query on the dev forums and it might show up).
so it would seem that with iOS 6, there may be a way to do this. Boingo appear to allow a user to turn on "Auto Login" and it will login/authenticate against the access point without the user interacting/authenticating manually (I haven't tried it myself though). Is there new API calls in iOS 6 that now allows this? See this article.
Under iOS there are several built in hooks for launching service-specific apps based on a passed URL for example handling http:// (to Safari), handling addresses (to google maps) and phone numbers (to the built in phone app). Several apps make it a standard practice of implementing the rarely used ability (for most apps) to register your own service prefix. Two handy apps that come to mind that implement this are facebook:// and skype:// and it is a handy way to add quasi-integration with their app into yours. Skype even does this on most desktop os's so you can literally run the command line skype://555-1234. You can also check for these registered service prefixes and expose useful menu choices in your apps but I digress.
As with all of these service handlers built in or not, the problem under iOS is that you lose the user and the flow of their experience ends with the phone app (for example). Yes you can embed web views to handle some cases but things like the phone app still win out.
I propose that it would be great that if iOS apps were handed a trailing URL as part of their arguments (even if they accept and might handle say two args already) that by convention when our app is exited we launch the trailing URL we may have been optionally handed. If fully supported in some manner this would allow for multi-app integration and an extended user experience flow-wise. I'm imagining being able for example to launch a phone call and have the user return to my app when it is finished by launching my app again using the URL I passed it such as "myapp://return-context-values". Obviously this could be taken further.
Does such a mechanism already exist in some way? If not I'd like to hear your thoughts on the idea.
Check out x-callback-url.com, it proposes precisely what you're suggesting.
And yes, I think it would be great. You're much more likely to pass a request to me if you know you'll get the focus back, and vice versa.
Today, the focus of a cell phone's capabilities is drifting away from plain making a phone call.
And somehow, this shows in the API's too. Therefor I'm wondering: if I want to write an app that e.g. pitches up, records, scrambles... an incoming call - you know, the voice on the other side -, what aspect of the API should I use?
I looked into Android, into Windows Phone, iPhone... (briefly), but had no luck. Is this just unintended usage?
This is also not possible with Windows Phone 7. There were, however, API methods for interacting with incoming and outgoing calls and texts in Windows Mobile.
The reason this is not possible in Windows Phone 7 comes down to a deliberate decision around data security and the aim that apps on the phone shouldn't be able to do something without the user specifically knowing about it. This prevents, amongst other things, malicious apps having information about or access to potentially sensitive data.
This is not possible in Android, except maybe via firmware modifications.
There’s no way to do that with the iPhone SDK. It may be possible through jailbreaking, but I’m not familiar enough with it to speak on it.
Given the limited accessibility of in-call audio but ready access to microphone/speaker and data on current smartphones, would probably be easiest to do this as part of a VOIP calling application.