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.
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 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
I am developing a Windows phone 8 app that need to run only in background with UI. Is there any way I can run the app in the background, or without actually being open?
It depends upon what you want to do in the background. Generally speaking you can't implement something like a Windows service that will startup automatically when the phone is launched.
That said you can run your app in the background within given limitations. Check out MSDN for detailed information.
Why all these limitations you might ask yourself? It's to provide a good battery life to the user.
Edit:
For the periodic agent to start running the app must be started once. Further the agent must update a live tile (user must pin it to the start screen) or the app has to be once opened every 14 days.
Another option might be using push notifications to trigger an update..
I need to make a certain setting stay on the device even when the app itself has been uninstalled. For iOS we are using user's keychain to store this information. Is it possible on WP8 somehow?
If you want to keep, let's say user settings after an app is uninstalled, I highly doubt that this is possible on Windows Phone. First of all it would create a lot of orphan files on the phone that you would not be able to get rid of. One of the services on Windows Phone is Package Manager. This manager is in charge of installing/uninstalling apps, keeping track of what is pinned to the start screen and other metadata about an app and any extensibility points like Share..., etc. If you uninstall an app this manager should clean everything related to you app, even your user settings in any file or IsolatedStorage that you create.
iPhone and Android give you an ability to use some sort of file manager to explore your phone. As far as I can remember you could use Putty to connect to your phone to see the folders and stuff. In Windows Phone you cannot go this far. There are some tools like Windows Phone Power Tools that you can use to check the installed apps, but that's about it.
Apps and all their related data are stored in sandboxed folders. When an app is uninstalled this whole folder is deleted. As such this means that all saved data is removed.
There are two, probably non-ideal, workarounds.
You could create an image saved in the users photo library. You could embed the identifier in the image or it's name but the user has control of these images and may delete it. You also can't programmatically delete such files so you may end up with lots on the device. Having lots of "rogue" files on a device is also likely to cause a user to tidy them up (delete them).
You could store a record of the setting, linked to the device on a web server. This has the downside of needing to maintain the server and handling data sync and offline scenarios.