I'm creating an application which should count how long the user stays without using his device.
For that, I have a timer which stops when the app become suspended. But, before stop the timer, I need to test two things:
Incoming Call: The user can answer or reject the call. If he rejects the call, the timer will keep counting. Otherwise, the timer will stop, and when the app becomes activated again, it will show an alert.
The iOS system alerts: Reminders, Calendar events, Low Battery, etc. I need to identify if the app become suspended by one of these kind of alerts.
The app already handles the first case. Everything is working for Incoming Calls.
The problem is that I don't know how to check for the second case. How can I identify if the app became suspended by one iOS system alert? Is there any way of doing this?
Related
I can't seem to find the right documentation, tutorial or SO post to point me towards the right implementation so far... even though there are many posts about this topic floating around.
Problem
I have an app that connects (pairs) to a BT device I built. What I want, is when the user presses the home button or backgrounds the app I want to send an update through a BT service layer to a BT device on a regular interval. I am doing this now (only fires once) in the applicationWillResignActive and applicationDidEnterBackground methods and it works perfectly. The problem is that I can only perform this once it seems. Any loops, timers, background type services that I start up in these methods, die very soon there after.
What I need
Is for the application to keep looking for my BT device in the background and every 10 seconds or so and send an update to the device. I first need to check to make sure the app is still backgrounded, but once I know its in the background I wanna send the update. When the app comes back in focus I can stop the updates to the BT device but its crucial that it sends them when the app is not in focus.
Research
I have found these SO posts (long-running tasks, background task execution handler, using this in an NSTimer loop... but it dies) but they have not helped with implementation at all.
When I wrote this post I was far too new to OBJ-C and didn't quite understand the concept of delegate methods with the proper access level to fire in the background (i.e. info.plist access under bluetooth-central).
The end result a month later was to build a peripheral device that could wake up the application in a timed loop via subscribed characteristic updates. Once the app wakes up, you have 10 seconds to handle the event that has just occurred and since I am only saving off a copy of the data that the device posted, all is well.
I am working on an app that, among other things, provides alarms in emergencies. Users can toggle a setting to have alarms be put through even if their iPhone is muted, but this service has another hurdle to leap: when the app has been force quit, it cannot receive (content-available) notifications until the app is relaunched by the user.
There is a geofencing event in place which buys me some processing time even if the app has been force quit, and in that time, I would like to check if such a block is in place, and if so, request the user to open their app again, and not aggressively force-quit in the future. (Many people still think it's just a way to keep things clean, even though it actually costs you battery life to not just leave apps in the background)
SO THE CORE OF THE PROBLEM: I need an (API call? Something else?) that will tell me whether the app is in such a 'force quit, cannot receive notifications' state, assuming that I do have processing time to do this check.
Anything is welcome, I have not been able to find proper Apple documentation on the notifications block.
Thank you very much.
While there is no API I am aware of to find state after, you can infer the state just before the application is terminated, and record that.
Code
applicationDidEnterBackground
will be called when an app has received a terminate signal.
More Info
This question describes what lifecycle functions to use, and
I have a volume control app in the iOS store, but one problem that my users have frequently is that the device kicks it for memory control. Is there any way to either force it to stay active (by permission) or to at least alert the user when its no longer active or in danger?
All the answers are under Background Execution in the iOS Developer Library.
Of course, here's the philosophy:
Always try to avoid doing any background work unless doing so improves
the overall user experience.
See Table 3-1 for the types of background execution. There's a category for audio but it requires audio to be played from the app. It does not sound like your app fits in here. So you'll want to look at notifying the user.
You could send a notification to the user when the app falls to background with applicationDidEnterBackground(), or just before it quits with applicationWillTerminate(), supposedly time-permitting.
Running in the background is permitted. I have an app that does it and while the rules have changed and adapting to it has been gut wrenching at times, it is pretty straightforward. In your case, I would think that you could setup to be notified and then just disappear, no? waking from a notification is part of the state changing protocol and you should be able to do that.
As a point of comparison, in Android, background operations like yours would be implemented as services and would have no fear of being terminated. The strangest thing about the way ios chooses to allow background activity is that you are applying for status one time. In Android, I was able to indicate that a single activity should be kept alive when the app is backgrounded, all others could be terminated. There is no way to do that in ios.
I take it my disappear and wait for notifications is probably not going to work for you because there is no way to be notified of volume changes. You must be polling? In which case, you probably are going to have to ask to be kept alive. Would be nice if you could just piggyback on other services, e.g. keep me alive while music is playing.
To answer your other question, yes you will get notified if/when you really are going to get termed, so you could send a notification at that point.
I'm working on an Cordova mobile app, currently targets iOS platform. I would like to know how to handle errors when the user quit the app abruptly on middle by pressing the Home button. Let'say the user has clicked a button that navigates the file-system, read a file, encrypts the content and save into a different location. In the middle of the process the user has clicked the Home button and so the app has moved to background. Can I expect all the operations will complete even-though the app has moved to background or do I need to handle these cases?
I would say there are two things you need to know:
1) iOS will not perform background operations unless you explicitly tell it to do so, so in the case you described, iOS would just cancel the actions that are currently active in your app. However, you have the chance to perform some operation between the point in time where the user pressed the home button and the point in time where the app actually changed its status from active to not being active. This can be done in the AppDelegate, since this is the component that controls the lifecycle of your app. The method you use here is - (void)applicationWillResignActive:(UIApplication *)application, this gets called before your app enters the background, from the Apple docs:
This method is called to let your app know that it is about to move
from the active to inactive state. This can occur for certain types of
temporary interruptions (such as an incoming phone call or SMS
message) or when the user quits the app and it begins the transition
to the background state. An app in the inactive state continues to run
but does not dispatch incoming events to responders.
So, this would be the place to either cancel the current action or save the current state so that it can be restored later.
2) iOS allows for multi tasking, but its quite tricky and only allowed in certain cases. This means you can not perform random operations while your app is in the background.
Some of these cases are:
Core Location Update: If you are using Core Location in your app, your app can receive updates on when the GPS position of the device changes and gets the chance to perform some operations in the background based on the new GPS data
Voice Over IP: The app provides Voice-over-IP services. Apps with this key are automatically launched after system boot so that the app can reestablish VoIP services. Apps with this key are also allowed to play background audio. (from the Apple Programming Guide on Background Execution)
Background fetches: With background fetches you can perform network requests on a regular basis, however you are still not able to perform the operations at points in time that you can precisely specify, you can rather tell iOS that you want to perform network requests in regular intervals and iOS will schedule the requests for you. Here is an excellent read on background fetches.
Hope it helps!
How does Navita https://itunes.apple.com/us/app/navita-t.e.m.-personal/id590228620?mt=8
manage to display a call log?
If I swipe the app out of the task manager then it misses the calls, this indicates that it must presumably be using CTCallCenter's callEventHandler and is creating its own call log by saving the time/duration in response to the callEventHandler callbacks.
However if that is the case then how does it manage to do this in the background? I was under the impression that callEventHandler can only be used by apps in the foreground and not in the background?
The app is using location services, however even after disabling this it was still able to get information about the calls (provided the app isn't suspended). I though it might be using background location updates to keep itself primed to receive callEventHandler callbacks but apparently not.
The Navita app is additionally able to display call time and call duration.
The bounty will be awarded to an answer which contains sufficient, accurate and detailed information that enables me to emulate the behavior of the Navita app, specifically I must be able to write an app that can obtain the time and duration of a phone call that occurred while the app was not in the foreground, while the device's location services was turned off, and after the app had been in the background longer than the ~3 minutes granted by using beginBackgroundTaskWithExpirationHandler:
Here is what I observe with the Navita app that I want to be able to reproduce:
1) Run app
2) Task away from app
3) Go to device settings, privacy, and turn off Location Services.
4) Go to device settings, privacy, background app refresh and turn off for the app
5) Wait > 10 minutes to make sure the app is not still in the background as a consequence of using beginBackgroundTaskWithExpirationHandler:
6) Call the device from another phone, answer the phone call, then hang up.
7) Launch the app again and display the call time and duration
(This is iOS7 and unjailbroken)
Here is what I've found from Navita TEM disassembly and it's resources.
Application uses two background modes - location and audio. You can see it in the Info.plist file. When you enable phone calls logging application will also enable "alerts" and "Real-time" switches. When "alerts" enabled application infinitely loops in background "bg-sound.mp3" file which has no sound, it's just silence. Because of that it doesn't use hacks like this one How to get a call event using CTCallCenter:setCallEventHandler: that occurred while the app was suspended? . It's similar trick to location used in order to keep the app running in background and receive phone call events. Somehow this was not rejected from the AppStore.
If you are observing the call center while the app is in the background you get a set of updates when the app is brought back to the foreground. This set of data may not be as accurate as if the app had been mostly in the foreground but it does include quite a bit of info.