I'm writing a React App and I'm using Web Speech API for both speaking and voice recognition. I've written some code that works on desktop Chrome.
The way I ask for permission from the user is the following:
navigator.mediaDevices
.getUserMedia({ audio: true })
.then(function (stream) {
console.log('Succeeded');
/*Handle success*/
})
.catch(function (err) {
console.log('Failed: ', err)
/*Handle failure*/
});
However, this same code always goes to the catch callback when used from my Android phone, with the following written to the console:
Failed: DOMException: Could not start audio source
The site asks me if I want to allow microphone usage and when I go into the site settings, it says microphone and sound are both allowed, which makes me believe I've done the user interaction part well.
The site is served over HTTPS (already solved that issue), so I believe this is not an issue as well.
I'm using Xiaomi Mi 9 with Chrome Chrome 86.0.4240.185 in this test.
My first instinct is that I'm doing something wrong here? If this is the case, what?
Otherwise, what can I do to fix this issue?
Check if your Android app has required permissions:
android.permission.RECORD_AUDIO
android.permission.MODIFY_AUDIO_SETTINGS (might be optional)
You can check html or ejs file ;
you have to use in the body tags
Such as:
body
</div>
<script src="script.js"></script>
/body
Related
I just released my first app and It has a button in it that takes you to a website.
A user just sent me this:.
I tried googling Google's secure browsers policy but not much info is coming up.
how can I make my app comply with this policy? I think the button opens a browser in app (I use duckduckgo as my default browser and haven't had an issue)
is it just a case of opening a browser and then heading to the website when the button is pressed?
my code to open the website is:
_launchURL() async {
const url = 'https://www.thiswebsite.com';
final uri = Uri.parse(url);
if (await canLaunchUrl(uri)) {
await launchUrl(uri);
} else {
throw 'Could not launch $url';
}
}
thanks so much and any help would be greatly appreciated
Google is trying to make sure, you open this window in an actual new browser window, not in a webview still under the control of your application.
Your code should open an external browser.
Maybe the user has no browser installed on their device? Maybe their default browser is some exotic thing not recognized by Google?
If you are using the latest version of url_launcher (currently 6.1.8) there is not a lot more you can do.
You could force the app to take the external browser, not the in-app webview:
await launchUrl(_url,mode: LaunchMode.externalApplication);
But that should be what happens anyway. If your version is up to date, ask your user, what browser they use. Be prepared to tell them that they need to use another one.
I'm following this guide, I'm having this code:
var acs = ActionCodeSettings(
url: 'https://example.com/auth/widget',
androidPackageName: 'com.example',
iOSBundleId: 'com.example',
handleCodeInApp: true,
androidInstallApp: true,
androidMinimumVersion: '12',
);
var emailAuth = 'john.doe#pm.me';
FirebaseAuth.instance
.sendSignInLinkToEmail(
email: emailAuth, actionCodeSettings: acs)
.catchError((onError, stackTrace) {})
.then((value) =>
print('Successfully sent email verification'));
Sending the email works, but when I click on the email, then…
in iOS it opens https://example.com/auth/widget - which is the fallback
in Android it shows a circular loader for about 1s and then it "falls down" and nothing happens
The incoming link handler
FirebaseDynamicLinks.instance.onLink.listen((dynamicLinkData) {
print('got dynamic link! $dynamicLinkData');
}).onError((error) {
print('error error!');
});
I configured dynamic links in Firebase to point to to.example.com. I also added a manual dynamic link to.example.com/test which opens my app (the got dynamic link! message shows up) - so all seems fine, the problem seems to lie in the link generation.
The link structure I get by email is:
https://to.example.com/?link=https://example-abcd.firebaseapp.com/__/auth/action?apiKey…%26continueUrl%3Dhttps://example.com/auth/widget%26lang%3Den&apn=com.example&amv=12&ibi=com.example&ifl=https://example-abcd.firebaseapp.com/__/auth/action?apiKey%3D…%26continueUrl%3Dhttps://example.com/auth/widget%26lang%3Den
After some more painful hours of debugging and reading documentation I finally found it out. Most of this is in the flutter documentation, but since the documentation has broken links and is a bit all over the place it was hard for me to catch it all!
Android
I needed to decrease the androidMinimumVersion from 12 to 1. Then my app opens and I can receive the dynamic link. No idea why. My android simulator is android version 13 but the app never opened.
Before decreasing the android version I also set the sha256 setting in firebase, using gradlew signingReport documented in this answer. Not sure though this was required.
iOS
I forgot to do all the steps documented in receiving links on iOS section, namely:
add the dynamic links domain into associated domains
add FirebaseDynamicLinksCustomDomains into Info.plist
Overall, I found that to get this feature working was really really hard for me as a Flutter beginner. But I guess a lot of the setup I can re-use as the dynamic links capability seems to be something which comes in handy in the future.
My app is based on this code sample from Google: https://actions-on-google.github.io/actions-on-google-nodejs/classes/conversation_question.deeplink.html
Here is a snippet directly from my code:
app.intent('Default Welcome Intent', conv => {
conv.ask('Great! Looks like we can do that in the app.')
conv.ask(new DeepLink({
destination: 'MyBookApp',
url: 'https://www.mybooksite.com/read/123456789',
package: 'com.mybook.app.reader',
reason: 'handle this for you',
}))
})
// Create a Dialogflow intent with the `actions_intent_LINK` event
app.intent('Get Link Status', (conv, input, arg, status) => {
// possibly do something with status
conv.close('Okay maybe we can take care of that another time.')
})
When I run this app I see "Okay maybe we can take care of that another time." instead of my app being launched.
Is there code missing in my handler for the 'Get Link Status' intent? (I created the intent according to the comment above that line).
Am I passing the wrong params to the DeepLink object? I can't find docs for them anywhere.
Note: My app is definitely coded to handle http deep links including verification with Google Digital Asset Links and the deep link URL I'm testing with works perfectly from other apps.
Any suggestions or help is much appreciated!
Thanks in advance...
Your welcome intent handler is missing an additional call to conv.ask before the deep link call:
conv.ask('Great! Looks like we can do that in the app.')
All responses should have at least a simple response.
I have an HTML5 application that uses Azure mobile services authentication to login (straight from the example code...provided below). It works fine in all desktop browsers and iPhone 5 in Safari. But from app / full screen mode, it does nothing (doesn't ask for permission to show a popup window like it does in safari and no popup windows shows up) and I can wait forever and nothing happens. If I invoke it a second time, it gives an error saying "Error: Unexpected failure"...perhaps because the 1st attempt is still running? Any help/insight is appreciated.
client.login ("facebook").done(function (results) {
alert("You are now logged in as: " + results.userId);
}, function (err) {
alert("Error: " + err);
});
edited update with more info and 2 potential ideas*
I did some more research and found a site that uses an approach that overcomes this problem and also solves two other side effects with the current Azure mobile approach to authentication. I think the Azure mobile team might be looking to do something similar because there are some hints of other authentication options in the code (although difficult to read and be sure because the minimized code is obsfucated). It might be just a matter of activating these in the code...
The "solution":
Go to http://m.bcwars.com/ and click on the Facebook login. You'll see it works perfectly in iPhone Safari in "app mode" becuase instead of doing a popup, it simply stays in the current browser window.
This approach solves two other problems with the current Azure mobile approach. First, the popup gets interpreted by most browsers as a potential ad and is either blocked automatically (desktop Chrome) ... and the user doesn't know why it's not working...or gives a warning which the user has to approve (iPhone Safari in "browser mode") which is a hassle. And if the user has a popup blocker, it gets more difficult and even more potential for the user not getting it to work properly. The bcwars.com method doesn't have this problem.
Second, in iPhone Safari, when the popup window auto closes, the original page doesn't get focus if there are other browser windows open in Safari. Instead, it's in the smaller/slide mode so they can choose which one to show. If this happens, the user has to go through one more sttep...click on the browser window to activate it and give it focus..again more of a pain and more potential for them to mess up and not do it correctly and need help. The m.bcwars.com doesn't have this problem.
Azure options:
Looking at the Azure mobile code it looks like may already have the solution. I can't read it easliy becuase it's minified/obsfucated, but it seems to have 4 options (including iFrame, etc.) for invoking the authentication, and only 1 (the "less ideal one" of a popup) is being used. An easy solution would be to set a property to allow one of the alternate authentications to work. But I can't read it well enough to figure it out. Another would be to hack the code (temporarily until a fix is put up by Microsoft).
Could I get some help there perhaps?
You can implement an authentication flow with Facebook that doesn't use a popup. The basic idea is to use the 'Web Flow' for doing the login, and once the window return from the login, use the access token to login the user in to Azure Mobile Services.
The Facebook documentation for doing this is here:
https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/#step2
Some code samples to make it easier for you.
You would start by something like this:
(Remember to replace YOUR_APP_ID and YOUR_URL with something relevant to your site.
function logIn() {
window.location.replace('https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=http%3A%2F%2FYOUR_URL&response_type=token')
}
This redirects the window to the Facebook page for the user to log in and authorize your app. When the user is done, Facebook will redirect the user back to YOUR_URL given above.
There you can handle the redirect and do the Mobile Services Login with something like this:
function handleLoginResponse() {
var frag = $.deparam.fragment();
if (frag.hasOwnProperty("access_token")) {
client.login("facebook", { access_token: frag.access_token }).then(function () {
// you're logged in
}, function (error) {
alert(error);
});
}
}
In here you parse the access token you get as a URL fragment and pass it as argument to the login call you make to Azure Mobile Services.
This code depends on the jquery BBQ plugin to handle the URL fragment easily.
Hope this solves your problem!
I have web page where I have Button that either opens app (if it installed) or directs to App store if app isn't installed.
It all works if App is installed (I call into "MYAPP://"). However, if app is not installed Safari shows error message "Can not open URL" and that's it. Is there way to disable that message from JScript or is there another way to find out from JScript if app installed (instead of hitting app URL)?
To MODERATOR: I saw someone asked similar question and Moderator wrongly marked it as duplicate. Please understand that question was specifically about doing it from Browser.
Found somewhat suitable solution here
BTW if someone interested in how to do same thing for Android, here is code. We are using Dojo library:
dojo.io.iframe.send({
url: "yourApp://foo/bar",
load: function(resp) {
// nothing to do since it will automagically open App
},
error: function () {
window.location = "go to Android market";
}
});
At Branch we use a form of the code below--note that the iframe works on more browsers. Simply substitute in your app's URI and your App Store link. By the way, using the iframe silences the error if they don't have the app installed. It's great!
<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
window.onload = function() {
// Deep link to your app goes here
document.getElementById("l").src = "my_app://";
setTimeout(function() {
// Link to the App Store should go here -- only fires if deep link fails
window.location = "https://itunes.apple.com/us/app/my.app/id123456789?ls=1&mt=8";
}, 500);
};
</script>
<iframe id="l" width="1" height="1" style="visibility:hidden"></iframe>
</body>
</html>
If others have better solutions to detect whether the URI scheme call actually failed, please post! I haven't seen one, and I've spent a ton of time looking. All existing solutions just rely on the user still being on the page and the setTimeout firing.
here is a code that works on iOs, even if the "Can not open URL" still show.
window.location = "yourApp://foo/bar";
clickedAt = +new Date;
setTimeout(function() {
if (+new Date - clickedAt < 2000) {
window.location = "go to Android market";
}
}, 500);
Thanks for the android solution.
I've combined a few things and used the following code to check if it's an iOS device before using the try/catch method from chazbot. Unfortunately, the device still throws a pop-up box to the user saying the address is invalid...anyone know if this is expected behavior for trying to open an invalid URL within a "try" block?
var i = 0,
iOS = false,
iDevice = ['iPad', 'iPhone', 'iPod'];
for ( ; i < iDevice.length ; i++ ) {
if( navigator.platform === iDevice[i] ){ iOS = true; break; }
}
try {
//run code that normally breaks the script or throws error
if (iOS) { window.location = "myApp://open";}
}
catch(e) {
//do nothing
}
There are a few things you can do to improve on other answers. Since iOS 9, a link can be opened in a UIWebView or in a SFSafariViewController. You might want to handle them differently.
The SFSafariViewController shares cookies across apps, and with the built in Safari. So in your app you can make a request through a SFSafariViewController that will set a cookie that says "my app was installed". For instance you open your website asking your server to set such cookie. Then anytime you get a request from a SFSafariViewController you can check for that cookie and redirect to MYAPP:// if you find it, or to the app store if you don't. No need to open a webpage and do a javascript redirection, you can do a 301 from your server. Apps like Messages or Safari share those cookies.
The UIWebView is very tricky since it is totally sandboxed and shared no cookies with anything else. So you'll have to fallback to what has been described in other answers:
window.onload = function() {
var iframe = document.createElement("iframe");
var uri = 'MYAPP://';
var interval = setInterval(function() {
// Link to the App Store should go here -- only fires if deep link fails
window.location = "https://itunes.apple.com/us/app/my.app/id123456789?ls=1&mt=8";
}, 500);
iframe.onload = function() {
clearInterval(interval);
iframe.parentNode.removeChild(iframe);
window.location.href = uri;
};
iframe.src = uri;
iframe.setAttribute("style", "display:none;");
document.body.appendChild(iframe);
};
I've found it annoying that this will prompt the user if they want to leave the current app (to go to your app) even when your app is not installed. (empirically that seems only true from a UIWebView, if you do that from the normal Safari for instance that wont happen) but that's all we got!
You can differentiate the UIWebView from the SFSafariViewController from your server since they have different user agent header: the SFSafariViewController contains Safari while the UIWebView doesn't. For instance:
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Mobile/14E269
-> UIWebView
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E269 Safari/602.1
-> SFSafariViewController
Other considerations:
in the first approach, you might want to handle uninstalls: if the user uninstalls your app, you still have a cookie that says that the app is there but it's not, so you might end up with the "Can not open URL" message. I've handled it by removing the cookie after a few tries that didn't end up opening the app (which I know because at every app open I'm resetting this failed tries cookie)
In the second case, it's unclear if you're better off using a setInterval or setTimeout. The issue with the timeout is that if it triggers while a prompt is on, it will be ignored. For instance if you open the link from Messenger, the os will ask you "Leave Messenger? You're about to open another app" when the iframe tries to load your app. If you don't respond either way within the 500ms of the timeout, the redirection in the timeout will be ignored.
Finally even though the UIWebView is sandboxed, you can give it a cookie to identify it, pass it in your deeplink, and save this id as corresponding to device with your app in your server when your app opens. Next time, if you see such a cookie in the request coming from the UIWebView, you can check if it matches a known device with the app and redirect directly with a 301 as before.
I think you can still use the app url as a test. Try wrapping it in a try...catch block,
try {
//run code that normally breaks the script or throws error
}
catch(e) {
//do nothing
}