I'm working on a Windows phone application which uses Network and Location capabilities.
All apps using any kind of these capabilities or others, will first display a consent dialog ("this app will use microphone, do you allow this?").
This dialog appears on first use by default on the Windows Runtime apps. But what about the apps for Windows Phone (Universal app, still using WinRT)?
Should I display a dialog for the first time usage of the capability or the OS handles this automatically? In Debug mode, nothing ever appears. I've also tested the app in Release Mode, and still nothing. So, do we have to manually handle this or the OS will handle a display of such dialog when the package is to be installed and used on other devices?
You can trust that the operating system will do the right thing for user consent when you declare a capability such as location. On Windows, as you've seen, this consent prompt happens on first run. The model for Windows Phone is to ask for consent at installation time. Either way, the system will take care of the prompting for you--you need not implement your own prompt.
Indeed, if you think it through more carefully, what would you do with the accept/decline answer from such a custom prompt? The whole purpose of the consent prompt is to broker access to sensitive WinRT APIs, which means those APIs will fail unless consent has been granted. Apps can't be given the power to make that decision on their own, because it would defeat the whole purpose of consent. Thus even if you obtained accept/decline yourself, there's nothing you could do with that value; there's no API to set permissions programmatically, as only the user can do that through Settings.
The consent prompts are just a way to initialize those permission settings at the appropriate time, and again, you can trust the system will do the right thing.
Windows Phone universal apps uses WinRT APIs as well, and same general guidelines described below applies to Windows Phone as well. However, there are differences in settings charm . The best way for you to test is publish the windows phone app as beta, then see if there is a consent prompt.
http://msdn.microsoft.com/en-us/library/windows/apps/hh768223.aspx
Related
I've written a simple web app to factory-reset bluetooth devices that were accidentally turned on during shipping. The app scans for a class of bluetooth devices (those made by the company I work for), renders a list of devices found, and, when I click a button next to a device in the list, sends a reset message to the device.
This is a very manual process and I'd like to automate it. The problem is the Chrome dialog that asks for permissions to pair with a device. I am trying automate the app with Puppeteer, but I can't find a way to either (a) programmatically grant permissions to pair with a device or (b) to select the device in the dialog and click the "pair" button via Puppeteer. Anyone know if what I'm trying to do is possible, or if there's a better way to achieve the goal? Thanks!
This is not possible in Chrome. (I work on chrome.) The automation that does exist for Chrome's testing is layered such that actual Bluetooth connections aren't made.
Eventually we would like to enable this workflow via Enterprise configuration controls. But that is not started yet and there is no date commitment.
One alternative is to use node.js, though you lose the easy interface. You might build the reset backend in a node server and have it serve a web page interface.
When I enumerate Bluetooth LE devices using WinRT API, sometimes, I needed to reset Bluetooth radio to successfully find my device. I am wondering is there an easy way to do this from code (Windows SDK, WinRT, WMI etc)?
After digging through Windows Universal samples from Microsoft, I have found a sample RadioManager which shows how to access Radios and turn ON/OFF from code at will. I was able to use the API successfully with a caveat that when used from Desktop WPF app, the app has to be built to match native architecture of the machine. Otherwise, ‘GetRadiosAsync’ method returns empty set.
I'm not totally sure, but resetting the system-wide Bluetooth radio is the sort of action highly unlikely to be available to an execution environment with non-admin privileges.
Anything able to stomp over the abilities of other processes (like turning off a radio) is not going to available in WinRT.
Edit: I stand corrected. Such an API apparently exists:
Windows.Devices.Radios.SetStateAsync
I'm developing a line of business app for Windows 8.1, that is, I am not deploying through the Windows Store and will be able to control all of the features of both the OS and hardware this app is being deployed on.
Because this app is working as the UI in a real-time situation I would prefer if I could ignore the life-cycle events and not have the app suspend or terminate at the whim of Windows 8. Does anyone know of a way to do this?
I have seen some older answers, such as this one and this other one indicating otherwise, but I haven't yet found anything more recently and specifically dealing with the case of a line of business app. I have found the Embedded Lockdown Manager which would prevent the app losing focus and addresses some of the needs I have, but I still would like a way to simple disable Lifecycle events.
Have you tried Assigned Access Mode? Basically use PC Settings -> Accounts to lock an account to a single app. You have to reboot the device and log-in again in order to run anything else.
I have created an application which use HERE Application Launchers and my app work fine on my Nokia Lumia 720.
My problem is certification on marketplace I get the response like:
The application exhibits device specific behavior that inhibits functionality and
features. The application's main functionality
cannot be tested on non-Nokia devices because it requires Nokia Here Drive.
-Launch the application on HTC 8X.
...
-Observe the user is prompted to install the app "Here Drive".
I agree with this becouse HERE maps are only available on Lumia devices. But how to use HERE Launchers if we cannot publish it on the marketplace?
If somebody has had similar situation and know solution for it?
That's because it's better to use the ms-drive-to or ms-walk-to Uri scheme!
When you use those, the phone itself will launch HERE drive if it is present, otherwise Bing maps!
Get the needed example code and usage on MSDN here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj710324(v=vs.105).aspx
I think you need to clearly state in your app description for Store and in the app itself, that it works only on Nokia devices. (Or you can implement some kind of fallback behavior for non-Nokia devices as well)
This way it should pass the certification, because the behavior will be expected and not confusing.
I suppose either there were something wrong on the submission time, or the rules have changed. I at least submitted an application which is using the Uri Scheme directly, and it got accepted.
In the essense there is no requirements for any specific Application being installed, but there is a query made for applications which support the Uri scheme protocol. And if the HERE application having it is installed, then it will be launched.
And if there is no handlers available, then the market place should be opened for searching for the handlers. At least that's the way the system is designed for.
I'm going through the Windows Phone test suite before submitting my app to the Windows store.
The guidelines have the following section:
Requirement - 5.4.1 - Malicious software screening
Requirement Text - The app must be free of viruses, malware, and any malicious software. -
Test Steps -
Launch your app.
Scan the app for malware.
Verify that there are no viruses, malware or malicious software in the app.
What does "Scan your app for malware" mean? Is there some tool I'm supposed to use to scan the app for malware? The document contains no link to such tool and a google search and MSDN search did not yield much results.
I can't speak on behalf of MS but I imagine that the malware tools used internally aren't available outside. Having said that, you could still run scans using programs like MalwareBytes or Microsoft Security Essentials on your XAP file itself and/or rename XAP to ZIP and unzip it to scan the files individually. Viruses stored within the XAP file could be read in by an app and then spread onto other platforms (even if it doesn't affect the phone itself. The requirements may be discussing that.
If your app isn't doing anything suspicious and doesn't use unsupported APIs, I personally wouldn't worry too much. Whilst there may be some false positives sometimes, I'm not aware of any particular tool that this section of the requirements specifically refers to.
Edit - I was reminded that there is a Store Test Kit but I didn't initially post that as it doesn't specify that it does a malware check. Good idea to run it nevertheless.
[What Store Kit Tells You]
Whether the XAP file meets size requirements and whether the app manifest file is valid.
Whether a Direct3D app that targets Windows Phone 8 uses APIs that are not allowed on the phone.
Whether a background agent app uses APIs that are not allowed with background agents.
What capabilities the app uses (for apps that target Windows Phone OS 7.1 only).
Whether the specified images and screenshots meet certification requirements.
Whether the app icon and background image used in the app meet certification requirements.