I am trying to develop a simple calendar app with a live tile but in battery saver mode the background agent won't run and I can't have the live tile updated with the current day and day of week.
I noticed that the Calendar (1st party app) does not suffer from this problem even in Battery Saver mode.
Does it get special attention / capabilities being a first party app or there is some trick that I don't know (yet)?
The built-in (or system) apps are not restrained in the same way that 3rd party apps are. There are many examples of this on Windows Phone but two visible ones are...
The calendar app updating its Live Tile even when Battery Saver is turned on (which you noted).
The People Hub Live Tile which has many small tiles which rotate in sequence - as developers, we don't have access to that Live Tile Template.
The Photos Hub Live Tile displays photos using a panning animation - also not available to developers.
As there is no 'fix' if your PeriodicTask doesn't run as expected, you'll simply have to update the tile when your app runs as well as checking the status of the PeriodicTask each time.
Related
I am developing an app in Xamarin Forms which will show thing live position of the user on a map and all the users having the app can track other users movement.
Right now the app is working fine in android. But in the iOS foreground, android background it stops after some time. It is not at all running in ios background when I put the app in the background it stops showing the location and stops fully.
Please share some idea to keep the app live in background and foreground mode for the whole day.
Generally speaking, mobile OSs will stop your apps, when they are in the background for some time. How strict the OSs are depends on the OS and the version. iOS has "always" been very strict about it, Android has been a bit more loose in older versions, but is quite restrictive in newer versions. Anyway, getting the location in background is quite a common use case and OSs are providing you options to do it nevertheless, if you ask them politely.
iOS
As of iOS 11, there is a distinction between updating the location when in use and when in background. The user can choose which one to grant and you'll have to handle it appropriately.
According to this guide you'll have to add the NSLocationAlways key to your Info.plist to contimue getting the location when in background.
Android
From the Android developer guide
In an effort to reduce power consumption, Android 8.0 (API level 26) limits how frequently background apps can retrieve the user's current location. Apps can receive location updates only a few times each hour.
Anyway
The system distinguishes between foreground and background apps.
An app is considered to be in the foreground if any of the following is true:
It has a visible activity, whether the activity is started or paused.
It has a foreground service.
...
According to this, you can create a foreground service, see here more about it
For this reason, foreground services must show a status bar notification with a priority of PRIORITY_LOW or higher, which helps ensure that the user is aware of what your app is doing.
So if you are starting a foreground service that is shown in notification bar, you should be able to retrieve updates, even if your apps main Activity is not in foreground.
I've seen claims on the net that the newly released iOS 7.1's iBeacon support.
Specifically:
The system is supposed to still notify your app about
didEnterRegion/didExitRegion events, even if the user explicitly
kills your app.
didEnterRegion/didExitRegion notifications are
supposed to be faster from the background and/or with the device
locked.
I have not been able to confirm either of these claims with my own testing. In fact, I seem to be less likely to get didEnterRegion/didExitRegion notifications from a locked device. (more accurately I seem to get didEnterRegion notices, but not didExitRegion notices). That could be because Apple made me remove my BLE background mode entries in my info.plist - I'm not completely sure. I'm still trying to sort this out.
I had trouble setting up my tests at first, but I have witnessed background region entry callbacks after killing an app in iOS 7.1 on both iPhone 4s and iPhone 5s models. See comments below for testing details and instructions to reproduce.
I have also done tests on background detection times on an iPhone 4S, and I still see delays of 15 minutes on iOS 7.1. My full test results and methodology are described here.
Finally, I have also done some tests on the fluctuations on the "accuracy" (distance in meters) measurement on the same device before and after the upgrade to iOS 7.1. I do not see an obvious difference in the noise on the estimate. The graphs below show results before and after the upgrade, with an iBeacon 0.5 meters away for 60 seconds then moved to 3 meters away for 60 seconds. In both cases, the transmitter was a properly calibrated iPhone 4S w/ iOS 7.1 and the receiver was an iPhone 5S.
iOS 7.0.6 Estimated distance
iOS 7.1 Estimated distance
As has been mentioned in several articles circulating around the internet, beacon sensing is available even when you swipe your app away from the multi-tasking view. However in my experiments, a region enter/exit event doesn't call the didDetermineState: directly (Probably because I hadn't been using the AppDelegate to initiate any beacon sensing but instead triggering monitoring based on UI events). Instead if you have registered for Background Location Updates, your AppDelegate's didFinishLaunchingWithOptions: method would get called with the value for key UIApplicationLaunchOptionsLocationKey in the parameter launchOptions set.
You can do a simple check like this to test if this is indeed a location update that has bought your app into the background to perform some task.
if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])
You can then either register your monitored regions again or start ranging immediately.
P.S. CLLocationManager retains your previously monitoredRegions on app restore but without starting monitoring again using the same UUID and identity, you would not get the enter/exit region event in CLLocationManagerDelegate (which had brought your back up to life)
David has done some wonderful work on this, so I'm writing this cautiously... but I'm seeing something quite different from him in my tests.
I'm using two phones: an iPhone 4S running iOS 7.1 (11D167) and an iPhone 5S running iOS 7.0.6 (11B651). My iBeacons are manufactured and sold by Bluecats (www.bluecats.com), although I'm not yet using their SDK (ie. I'm just using CoreLocation) and I don't think the manufacturer makes much difference.
I'm getting response times of around 1-2 seconds on both devices when the app is running in the foreground and also when running in the background. The only difference is when I remove the app from the app switcher: iOS 7.0.6 never responds (or perhaps will do in 15 minutes), but iOS 7.1 responds in roughly the same time. When I say "respond", I mean that the CLLocationManager's locationManager:didDetermineState:forRegion: delegate is called by iOS.
I'm testing by actually wandering around my office with phones in hand, so I'm physically moving in and out of range. Strangely (?), in my early testing, where I was sitting at my desk and simulating moving in and out of range by removing and reinserting batteries, I was seeing much slower response times. Perhaps this is part of the difference?
In my testing I have seen the presence of a beacon go un-noticed by an app for up to 15 minutes, but I found something that's interesting. I'm using RedBearLabs mini BTLE sensors as ibeacons and their app to program the beacons, http://redbearlab.com/ibeacon/ (http://redbearlab.com/s/MiniBeacon_v1.zip), seems to have an something in it that immediately starts a scan / update of beacons. If I start a beacon up, and in my app it goes unnoticed, by starting then quitting the MiniBeacon app my app immediately notifies me that there are new beacons. This is the same result when entering or exiting. Their app uses CBCentralManager, which my app doesn't, so maybe a mixture between CBCentralManager and CLBeaconRegion is the way to go? I imagine CLBeaconRegion starts / restarts the bluetooth radio, so maybe that is the reason for this. Just taking a stab at it in hopes that someone with a more complete understanding can help resolve this.
Thanks
My testing also reproduces 15 mins to start scanning when my app is in background mode on iOS7.1.1. Just a bit curious, I have seen quite many youtube videos from different companies showing the app has been waken from background mode as soon as they approach their beacons. Is it sales trick?
I have made an app with live tile for windows phone 8. The tile is programmed to refresh every 30 seconds. When the run the app in the emulator or when I deploy the app in my cell (Lumia 920) the tile works fine. But surprisingly when I downloaded the same app from the market and run it on the same device the tile doesn't update.
I did quite a bit of research on this problem and found that a similar problem is observed by many other people which can be found here.
Kindly tell me what is going wrong.
Extra Info : I have tried resizing the tile, pin and unpin the tile and hard reset. I have also tried changing the refresh period (initially the refresh period was 5 seconds). I have also checked that the background task is allowed for the app.
Thanks,
Apurva Pathak
Background agents have certain limitations, as listed below.
Background tasks can minimally be run every 30 minutes. There is a debug-only API to run them more regularly, but this is not available for released apps.
Some low power devices do not support background agents
Background tasks are limited by number on each device and can be enabled or disabled from application settings.
They do not work when power saver mode is activated.
As Mahantesh correctly pointed out your tiles work when you deploy the application because the ScheduledActionService.LaunchForTest() is allowed to run for a 60 seconds period for debugging and testing purposes ONLY.
Therefore this method cannot be called and it wont work with a time limit less than 30 minutes if the application is published to the market and users download it from there.
I have an existing application developed for Windows Phone 7, which uses CameraCaptureTask.
The captured image is returned back to the app, which will be processed for grayscale conversion.
While testing the same app (same binary to be precise) in Windows Phone 8 Lumia 920, I figured that a copy of all the images captured through the CameraCaptureTask are saved in "camera roll" folder.
This is a bit annoying as the users of my app are not expecting the captured images crowding the "camera roll" folder. I looked up the documentation http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh394006(v=vs.105).aspx and found the below quote,
On Windows Phone 8, if the user accepts a photo taken with the camera capture task, the photo is automatically saved to the phone’s camera roll. On previous versions of Windows Phone, the photo is not automatically saved.
So far I couldn't find a way to avoid this case in Windows Phone 8.
Is there a way to turn off this feature before calling the CameraCaptureTask's Show() method in Windows Phone 8?
No. This is a consumer feature request implemented on WP8 that's transparent to developers. The usecase here is that a consumer uses the CameraCaptureTask to line up a perfect shot, doesn't use it an app for whatever reason and can't find it ever again later.
As a side-note, I actually had this happen a few times to me when using various twitter and photo editing apps and it's quite annoying.
Makes no sense. CameraCaptureTask was created to allow apps to capture photos for the app use, not for users to push them into Camera Roll. That is what Lenses are for (either custom code can write into camera roll as well).
It is not transparent to developers because one of my apps has just been removed from the WP8 market. They say because can cause "undesired upload of an app photo to skydrive".
Justin are you sure it isn't a bug? is it going to be fixed?
This forces me to break my development into 2 now: WP7 and WP8. I don't want that hassle right now...
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.