Is there a way to detect if user clicked to call in Windows Phone?
I don't want to block, detect incoming or anything else with the call, I just want that my app knows when the user clicked to call and knows the number that he is calling.
Is this possible?
No, with the Windows Phone OS, an app can not interfere with the calling functionality. The best they can do is prompt the user to dial, to a supplied number.
There is no way currently to detect the phone call status (or any other metadata, for that reason) for security and privacy reasons.
If you ever want to know whether your application workflow is interrupted by a call or whatnot, you can rely on the Obscured and Unobscured event handlers. You can download a ready-to-go sample here.
Related
Regarding the MediaDevices API.
(https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)
I know I need permission to use a media device to capture video, however I am not sure if I need to request permission multiple times in order to capture videoshots at regular intervals or just the one time at the start?
In other words, when does the permission expire? When the stream is closed, browser is refreshed or something else?
Can I use the initial permission to capture subsequent videoshots or do I need permission for each videoshot I intend to capture.
The browser continues to store the settings for device access, so you only need to approve it the first time. Unless you reset the settings yourself.
For example in chrome, you can check the permission of the site at the address below.
cam : chrome://settings/content/camera
mic :chrome://settings/content/microphone
According to getUserMedia docs:
First, getUserMedia() must always get user permission before opening any media gathering input such as a webcam or microphone. Browsers may offer a once-per-domain permission feature, but they must ask at least the first time, and the user must specifically grant ongoing permission if they choose to do so.
So we can see that the user must explicitly choose to grant the ongoing permission option from the pop-up, otherwise, it's going to ask every time.
The permissions pop-up and default selections may vary between browsers though, but they all support this feature.
I decided against using the native browser APIs directly, opting instead to use a service like Twillio to handle video capture AND recording. Once we have the recording I intend to chop it up to get a series of screen shots that summarize the video. This is not in realtime and does not need to be for my application.
Im working on an app that requires a PIN to allow certain tasks (purchasing, dealing with credit cards, etc). I would like to add the ability to use biometrics.
I want to be able to ask for permission to use the biometrics without actually authenticating anything the first time.
for example, the flow would be as follows:
- user logs in
creates a PIN
App asks if they would like to use biometrics in the future
next time when PIN is required, authentication prompt appears.
the current flow:
user logs in
creates a PIN
App asks if they would like to use biometrics in the
future
next time when PIN is required, OS prompt appears asking if
user is ok with app using biometrics.
THEN
authentication prompt appears.
Ive played around with react-native-touch-id, react-native-biometrics and a few others.
I know i could have it triggered when i first ask to set the PIN but the system prompt options are not customizable.
Thank you for your input!
So I know it's possible to use vm_read_overwrite and vm_write without asking the user to type in their password every single time your app launches.
I have an app that does this. I know you need to sign your application, then a password dialog will be displayed if your app reads/writes another process. You generally type in the root password once and then the app runs as your local user.
My problem is I'm creating a new app, which I signed, but it's not posting the dialog for permission.
Am I missing another step here? Worst case I can copy/paste my existing project, but I'd rather not as it's quite large.
Thanks!
Found it, needed SecTaskAccess set to allowed in Info.plist
http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/
Does Windows 8's built-in email client serve as a share target and, if so, will it send email sent it in this fashion (shared with it programmatically) without requiring direct user intervention?
Let's see if I can decrypt your question.
Yes: the email client pre-installed on Windows 8 (the "native" one) is a share target, yes. It is a PlainText and HtmlText share target out-of-the-box. All you need to do is share out from your app and Mail comes up as a potential target in the list.
As a result, the entire mail operation is handled by the mail application. You can't automate it. You also can't interrupt it. Once you share out, the target app handles the payload as it pleases.
If you want to automate an email send operation you need a service to help you do it. If you want to handle it on the client, read this: http://mikaelkoskinen.net/post/windows8-metro-app-winrt-send-email-emailcomposetask.aspx
Note: You should note that the operating system brokers all interaction across the share operation. This means you cannot reach out to the share target from your app, and the share target cannot reach back to your application. The best you have is knowledge of which target app the user has selected.
Reference http://msdn.microsoft.com/en-US/library/windows/apps/windows.applicationmodel.datatransfer.datatransfermanager.targetapplicationchosen
Yes it is a share target, and no you can't use it to send mail without user intervention - that's not how the share target is designed to work.
I wonder if I might disable the keychain dialog that pops up whenever my application wants to access the keychaindata. My app compares a TextField's string with a keychain entry in order to check if the entered Password is correct.
It works fine but it asks for the permission accessing it.
How to avoid this behaviour?
Best regards,
Adrian
Another advice is to code-sign your executable, even on OS X.
If you don't, then the system always asks the user if s/he allows the program to access the keychain when the program is updated, even when your user selected "Allow Always" before. This is because the system can't tell if the so-called updated program is a genuinely updated version.
As written in this Apple document, if you code-sign, the system doesn't ask the user if s/he allows the program to access the keychain when the program is updated, because the system can tell your new version of the app is really the new version of the app, issued by the same programmer.
So, to minimize the number of keychain dialogues, code-sign your app. Yes it's optional on OS X, unlike on iOS, but it has a few advantages.
This is the intended behaviour, so that Users are in control of what apps can access their keychain. If you want to avoid the prompt click "Allow always" on the dialog.