Is it possible to track the accelerometer value while under the lock screen?
I managed to write a simple application which counts from 1 up to 100 using a timer which fires an event on which I increment a counter.
But when I use register a handler for the ReadingChanged event of the accelerometer it will not be fired anymore once the screen has been locked. Even if I unlock the screen again I will have to readd my handler.
the msdn documentation tells on the one page:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff941090(v=vs.105).aspx
"Valid reasons to disable idle detection in Windows Phone OS 7.1 applications include ones where core functionality continues while the phone is locked (for instance, an exercise tracking app)"
but the sensor api also tells:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202968(v=vs.105).aspx
"The Sensor APIs cannot be used while the application is running under the lock screen. For more information, see Idle Detection for Windows Phone. The Sensor APIs also cannot be used in background agents. For more information, see Background Agents Overview for Windows Phone"
I hope they will change the api soon, because of that it is not possible to write any good sleep tracking / sport tracking applications ... :(
I was helping a guy with this a couple of days ago. He had an app that tracks GPS and accelerometer data under lock screen.
Turned out the app accelerometer data stopped tracking when under manual or auto lock screen.
There may be an issue here to be looked into.
Under lock screen it is a good idea to minimise power usage... disable all uncessary code, like ui updates. My understanding of one the motivations for idle detection and running under lockscreen being opened up during CTP was in response to a lot of feedback from developers of map/tracking apps that basically need this for their app to be of any use.
I'm not sure of the usage case where you'd want to use the accelerometer under the lock screen.
Apps typically run under the lock screen when you need them to do something when you're not interacting with the device. e.g. playing music or downloading a large file.
If you wanted accelerometer data I'd assume that the device is being held and, therefore, presumably, looked at. Given this, why would you therefore want to run under the lock screen?
That being said, if you had a good reason to do so, you should still be aware that:
when your application runs under a locked screen, it ... must minimize
power usage
(from the Marketplace Certification Requirements.)
In my understanding, reading values from sensors is not minimizing power usage.
Related
I just had an app rejected because I have a user changeable setting which allows the user to disable screen lock via
[UIApplication sharedApplication].idleTimerDisabled = YES;
Apple says I used an undocumented API but it IS indeed documented here: https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplication_Class/index.html#//apple_ref/occ/instp/UIApplication/idleTimerDisabled
My app graphs the barometric pressure and if you want the graph to run longer than a minute or two, it is important to disable screen lock. The default behavior is screen locking as usual, but there's an option in the settings to disable screen lock and this seems to be what Apple took issue with. I've had academic users request this feature, and I have used it in other apps successfully, however this time Apple rejected my app for using it. Is this normal? Is disabling screen lock via UIApplication really now allowed?
I am not sure but I think the issue is that note under the important heading with the documentation you shared;
"You should set this property only if necessary and should be sure to
reset it to NO when the need no longer exists. Most apps should let
the system turn off the screen when the idle timer elapses ..."
You should write into resolution center and confirm this;
We use that capability to prevent idle sleep when we are updating the firmware on a BlueTooth device. Immediately upon completing the update, we restore idle timeout. Apple never said a thing to us about it.
However, in your case, there is no technical reason to disable the idle timer. Your data collection is not going to fail because the system went idle. There is no adverse or unusual customer experience going to be had. That is probably what Apple took exception to.
Three possible paths exist:
1) Gather your data at intervals in the background while the system is idle and update the graph when the app again comes to the front.
2) Add messaging to your app to tell the user that if they want continuous display, they will need to change the idle timeout period in system settings. (With caveats about impact on battery charge duration.)
3) State your case to Apple.
I would go for both 1 & 2
I am developing a windows phone app that uses users current location, I am making the app in 7 OS. My question is, Can I track the location in background, that is when the screen is locked?
I know this is a possibility in wp8 as it provides us with GeoLocator class, but can I achieve this in wp7? I am basically making a runtracker app hence I would like my app to track the location even when its in background, is it really feasible?
Your help is always appreciated!!
It is possible to keep the app running under lock screen, as it does, for example, Endomondo app.
Using Idle Detection, you can keep the app on, although screen is locked, and you can keep on tracking the location. Actually, it is not running in background, but in the foreground. Just the screen is locked. So, be careful not to drain user's battery.
You have to set the PhoneApplicationService.ApplicationIdleDetectionMode property to Disabled, for example in InitializePhoneApplication() method in App.xaml.cs:
PhoneApplicationService.Current.ApplicationIdleDetectionMode = IdleDetectionMode.Disabled;
Note that there are special certification requirements for this type of apps. Refer to section 6.3 (Apps running under a locked screen) of the following page:
Additional requirements for specific app types for Windows Phone
I got the same problem in one on my apps..
I don't think it' s feasible for wp7..
Bt if you want to do it with wp8 you can refer following link.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681691%28v=vs.105%29.aspx
And to know about background supported and unsupported API's http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202942%28v=vs.105%29.aspx/css
GeoCoordinateWatcher Class exists in WP7, but here is the documentation from MSDN -
This API, used for obtaining the geographic coordinates of the device,
is supported for use in background agents, but it uses a cached
location value instead of real-time data. The cached location value is
updated by the device every 15 minutes.
More Info : http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202962%28v=vs.105%29.aspx/css
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.
I want to use accelerometer in my app when the user sleep. When WP7 is locked then accelerometer is turned off so I must set UserIdleDetectionMode to disable and then I disable lock screen but now the phone woudn´t be saving battery so what I must do for saving battery, for doing fake lock screen?
The other apps I've seen which do this recommend that the user plug their device in while using it.
I don't think this is an unreasonable solution as it's safe to assume that most users will charge their phones over night anyway. (Due to current battery technologies and the power consumption of the phones.)
I'm a complete noob when it comes to WP7. From what I know of it, in WP7 you wouldn't be able to make an alarm clock app. As in, start app, set alarm for an hour from now, close app, app launches and rings alarm after an hour is up.
Is this not possible in WP7? Or is there some way of doing it that I'm not aware of? I have seen a workaround for a stopwatch using tombstoning, but that doesn't seem like it would work here.
With Windows Phone 7 [for 3rd party developers] it's not possible to write an application that runs in the background on the phone. (This was a deliberate decision with regards to maintaining performance and battery life - not a limitation of the OS which is fully multi-tasking.)
If you really want the user to be notified of something at a specific time, regardless of whether your application is running you'll need to have this monitored from a process on an external server and then send a [toast] notification to the user at the appropriate time.
Learn more about push notifications at http://msdn.microsoft.com/en-us/library/ff402537(VS.92).aspx