Under the current Windows Phone 7 Application Certification Requirements (pdf) applications running under lock must "stop any ... active timers" (section 6.3.1). However looking out on Marketplace there are a number of timer/stopwatch apps claiming to run under lock and also allow lock to be disabled in their settings. How are these apps certified or is there some loosening on the restrictions by Microsoft if the app allows the user to make that decision?
Also some of these apps also suggest they continue even when the app is exited or when the device off. Is it the case that they are not truly running under these circumstances, i.e. the timers either start where they left off when reactivated, or perhaps use the OS time to work out the time elapsed between tombstoning and reactivation? In these circumstance I also presume it is not possible for the app to notify the user when the timer completes?
6.3.1 requires apps to offer the ability to prevent the app from running under a lock screen.
Apps can run under a lock screen by disabling ApplicationIdleDetectionMode.
You can keep track of time while the device is off using the OS time as you note. Peter Torr demoed this with tombstoning state in his WPH305 Tech Ed 2010 Talk.. refer 28 minutes in.
You presume correct that there is no ability to notify the user using client APIs on a timer. The closest you'll get to this is notifications which entails network communication and presumes connectivity.
Related
API Monitor has a feature to automatically watch for a new process starting and ask if you want to monitor it. However I have not been able to get this to actually work. The only option in the program I can find which seems to be related is the File menu "Pause Process Notifications" option. However, this is disabled which gives me the impressions that it can't be turned off but also that it is supposed to work automatically "out of the box". But whenever I start a new process, nothing happens.
Specifically I'm referring to the feature described here:
Process Notification
API Monitor intercepts process creation and allows you to select the
process for monitoring. Each time a process is created by the system,
a notification window is displayed with options to monitor, skip or
terminate the process. This is especially useful for monitoring
processes with a short lifespan or processes that are automatically
launched in the background. Process Notification can also be used to
monitor applications such as consent.exe (UAC prompt), which run on a
different desktop.
The following screenshot shows an example of the Process Notification
window that is displayed when launching an application that requires
elevation
I've tried both the 32-bit and 64-bit versions of API Monitor (Version 2.0 Alpha-r13) running both as regular user and as admin; makes no difference.
How can this feature be activated?
The specific reason I'd like to use this feature is that I have process A which starts process B, and it is B I need to monitor. A and B each run for only a few seconds so I can't manually get it to monitor fast enough.
Finally after reading through API Monitor forums I found some information. Unfortunately (for now at least) it seems the answer is that this feature no longer works (since Windows 8.1).
As posted on http://www.rohitab.com/discuss/topic/40418-process-notification-on-81/?p=10093378
rohitabPosted 11 October 2013 - 03:38 AM
Due to security related changes in Windows 8.1, the Process
Notifications feature of API Monitor does not work. I will try to
resolve this issue as soon as possible and post a hotfix.
But a later update in 2014 indicated that it hadn't been fixed yet, and seems not to have been since then either.
It was implied that running in a Windows 7 (or 8.0?) virtual machine might be a workaround, or obviously finding another tool which has this capability.
I've been playing around with NSRunningApplication in Swift 3, and I've come up with a few questions.
What's the best way to "pause" an application while it's launching. Don't quit it, but don't let it launch completely either. Just keep the icon bouncing in the dock (i.e. "freeze" the launch) for some arbitrary time. After that time, if I decide I want to quit the app after all, I can do NSRunningApplication(withBundleIdentifier: "xyz").terminate() or .forceTerminate(), and I can confirm with .isTerminated(). Otherwise, I can just "unfreeze" the app and let it finish launching.
What's the least power-hungry way of checking constantly for an app launch? I could just schedule a Timer to check every half-second or so, but I believe that hogs a fair amount of memory. Can I set a listener or notification to check for a 3rd-party app launch? (i.e. to run a function every time the Notes app changes isTerminated state).
Thanks!
You can't reliably target another process and control it from Swift (or any other User-mode program), as you really need to do that in the kernel, with a kernel extension (Kext).
Apple's official framework for this is the Kernel Authorization framework (KAuth). Using the File Operation Scope (described in the documentation), a kernel extension will be notified of various operations, including a program's execution and can allow or deny its access.
A working example of its usage can be seen in the open source code of Google Santa, which they use to manage their own employees' computers. As its documentation states:
It consists of a kernel extension that monitors for executions, a userland daemon that makes execution decisions based on the contents of a SQLite database, a GUI agent that notifies the user in case of a block decision and a command-line utility for managing the system and synchronizing the database with a server.
I'm using DeviceUseTrigger to get a "near-permanent" connection to the Microsoft Band. Explained in http://www.codeproject.com/Tips/1036512/Achieveing-Indefinite-Background-Execution-with-th
The method, described in the codeproject article, works perfectly in debug mode (without draining the battery). But running my app from the store results in a stopped backgroundtask; Windows 10 mobile stops the task due to some failing OS policy condition.
Does anybody found a workaround for this backgroundtask restrictions?
Microsoft Band does not initiate connections with channel A502CA9A-2BA5-413C-A4E0-13804E47B38F. Given that, we are uncertain what causes such RFCOMM trigger to start the background task.
Overall, today there is no supported way to solve this problem on Microsoft Mobile in RFCOMM trigger way using only the Band. Any successful experiments would hurt the behavior of Health Application.
What can help is any other device opening RFCOMM connection to the phone and a trigger set up for that connection.
Besides that it is not clear what "works perfectly in debug mode" means. When Visual Studio debugger is attached, the background tasks stay, helping the developer. Without debugger they get cancelled by OS.
I am developing a Windows Phone 8 app that would have a live flip tile. I will be creating a scheduled agent (periodic task not resource intensive) which will update the live tile using local data.
The whole app does not connect to the internet in any way, it uses only local data. So push notifications are out of the question.
I need to update the live tile from the background agent and/or from the foreground app when it's launched whichever happens first.
However how can I ensure the foreground app and the background agent do not step on each other's toes? I have two main options to do this :
Use a mutex (AFAIK the background agent runs in a different process so locks (monitor that is) is out of the question). But I'm afraid it would have a high performance cost (obtaining and releasing the mutex, that is).
When the foreground app starts I would always remove the agent, do its work and reschedule the agent back. Theferore there would not be any chance of overlapping between the foreground app and the background agent, BUT the whole add/remove agent could also be lengthy and, furthemore, the user might close the app after this removed the agent but before it added it back.
I am really torn between these two approaches and can't tell which would be best.
PS : You can't reschedule an agent from the agent's own code, right?
Mutex
The mutex option is officially recommended by the MSDN documentation for both Windows Phone 7 and 8.
I have used this option and experienced no noticeable performance problems when sharing data between the Background Agent and Foreground App, and I target WP7.1 and test on 1st and 2nd generation WP7 devices (LG E900 and Lumia 800).
Obviously, when using mutex, the key is to lock the resource for as short a time as possible. And when trying to acquire a lock on a resource in a Background Agent, the timeout feature of WaitHandle.WaitOne is very useful as the Background Agent only has 25 seconds to run.
NOTE: If you are targeting Windows Phone 8 only, or via a 2nd project/binary then a different approach (named events for inter-process-communication) is available. Peter Torr wrote about it on the official Windows Phone Developer blog.
Enabled/Disable Background Agent
The second approach you mention is riskier because the we don't know what guarantees the OS gives for adding or removing of the Background Agent - what happens if removal if not instant? what happens if a newly renewed Background Agent fires while to Foreground App is running? etc.
Agent Renewal
Background Agents cannot renew themselves - once added, they will run for a maximum of two weeks unless renewed by the Foreground App. This will prevent Background Agents running for apps the user no longer uses.
Given that Outlook runs in most offices, and given that a screensaver may user CPU, or network file copies, or virus scans, or network installs by the admin (granted, that usually happens when you're logged out), and all the myriad other things that might occur on a Windows 7 desktop in an office environment, how could I possibly know that a user is idled out, and not just reading a PDF?
Do I use a set of metrics to sample at regular intervals and use that to determine "away" or do I need to monitor some file, is there a API that should be exposed?
I can't rely on screensavers being active, or the computer entering a specific power state, and I'm not sure what is exactly off-limits, but I also don't know what's on-limits, as it were.
I think you're looking for GetLastInputInfo, which tells you how long it's been since the user hit a key on the keyboard or wiggled the mouse (or touched a touch-enabled screen?).