I'm working on a big app that has a huge Firebase footprint, and is constantly updating to stay in sync with other similar apps and a web service.
The app was designed as a kiosk app, but we discovered users are switching between it and other apps - in some cases often.
While we don't know of any problems, the question came up - when we get moved to the background, should we disable keepSynced, wait some seconds to allow inflight messages to complete, then on coming into the foreground re-enable it?
In a general sense, I don't see any advantage to doing this. iOS and Android automatically manage the lifecycle of apps the move to the background. Backgrounded apps may be killed outright to save memory and battery, and in that case, it doesn't matter what Firebase APIs you may have invoked previously - the app process is dead. I would just let the OS deal with moving things around and not try to optimize any further, unless you have some very specific requirements.
I have an iOS app connected to a peripheral and as such running in the background. Sometimes when there is a low memory situation, jetsam decides to close my app even though according to the jetsam log it is not the largest running process. So far my app didn't get any memory warnings so it is not even possible to respond to such event by releasing resources.
First I would like to know if there are any criteria for closing an app due to a low memory event.
Second, what are the keys in the log? for example the state key - does it represent the current state of the process, i.e. when it is suspended, it means that the app was closed by jetsam? or maybe that was the app's state regardless of the low memory event
Can several processes be closed? Because when I look at all JSONs, only one process has the killDelta key, and it doesn't always happen to be the largest one, and even so I can see that several processes are suspended, meaning again that not only one was closed?
I'd appreciate any help
Thank you
Well, I want to know about app 'capabilities' when app receives memory warnings.
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {
DDLogVerbose(#"applicationDidReceiveMemoryWarning");
[self executeTasks];
}
Could bluetooth connections be established? ( [central connectPeripheral:perihperal options:nil] )
Could bluetooth peripherals be scanned? ( scan started at this point )
Which kinds of background tasks could be executed?
My concerns:
I put establishConnections code in this applicationDidReceiveMemoryWarning handler. This code tries to establish connections to peripherals by known uids ([central connectPeripheral:perihperal options:nil]).
I thought that this functionality could be restricted and app would be rejected.
UPD:
Am I right about core bluetooth long-time usage?
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application; // try to clean up as much memory as possible. next step is to terminate app
So, If background service will be terminated, I can put 'establish connections' code inside didReceiveMemoryWarning preventing loosing connections. After that system kills service and take care about these connections as 'events for reviving my service from sleep when devices appear nearby'
There are a few questions in here. I can only answer the first.
applicationDidReceiveMemoryWarning is what it looks like and nothing more: a message from the operating system that free memory is in short supply. You can do whatever you want in response to it, or nothing at all. You can allocate an array of a million ints if you want.
But when the operating system can no longer allocate your app as much memory as it requires, your app will be terminated. Memory warnings are just a nicety you get before this occurs, and ideally you can take some action to free up memory.
I'm kinda confused with the following actions:
1) Pressing the home button - The application is now in 'background mode' - what does it really mean? (In more technical terms)
2) Double click the home button and drag the application out - What does IOS do in that case? Does it completely terminate the program? or it only wipes it out from the RAM while not giving it CPU time at all? (Just a suggestion).
And if that is the case, how do I get my application some CPU time even when it is 'dragged' out ? How does one terminates an application completely in iPhone?
Thanks !
1) In the background mode the application is till either kept in memory or it's memory is stored on disk (subject to the amount of memory used). It can be reactivated if it uses certain background modes, e.g. playing audio, monitoring location or receiving the relevant push notification telling it to wake up.
2) The application is totally killed. This is the way that one terminates an application and the app cannot get any CPU time in this state.
I am using core location framework inside my application and I set the location string in UIBackgroundMode or Required background modes(in Xcode 4.2) for getting the updated location from didUpdateToLocation method when app is running in background and also sending this updated location to server by hitting the specific link inside didUpdateToLocation method of core location framework.
My question is that will the app be terminated after some time when running in background or not?
No, there is no specific time defined for this.But app will definitely terminate based upon certain parameter - battery drain, memory footprint issue etc.
In developer documentation it is clearly mentioned - "The system keeps suspended apps in memory for as long as possible, removing them only when the amount of free memory gets low. Remaining in memory means that subsequent launches of your app are much faster."
Go through this for complete details -
http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
I am sure it is not useful for the author because the question was asked in June 2012 and I am giving an answer in June 2019. This answer maybe is useful for other users.
I am posting this answer because Everyone is said that it is OS default behaviour, We can not change it....bla....bla.
Recently, I was working with the same requirement. After 2-3 week hard
work, I did it. For other users, I create a helper class for it. My
app will never be killed by OS until the location tracking enabled.
You can also verify that OS will never kill this app tracking app
Use HSLocationManager for infinite location tracking in the active and inactive state.
Refer my app which is available in the app store(App will never kill by OS if location tracking is enabled)
Location manager that allows getting background location updates every
n seconds with desired location accuracy.
Advantage:
OS will never kill our app if the location manager is currently
running.
Give periodically location update when it required(range is between 2 -
170 seconds (limited by max allowed background task time))
Customizable location accuracy and time period.
Low memory consumption(Singleton class)
iOS app may get terminated due to following reasons:
Watchdog Timeout
As you’re probably aware, since iOS 4.x, most of the time when you
quit an iOS app, the app isn’t terminated – instead, it’s sent to
the background.
However, there are times when the OS will terminate your app and
generate a crash log if the app didn’t respond fast enough. These
events correspond with the implementation of the following
UIApplicationDelegate methods:
- application:didFinishLaunchingWithOptions:
- applicationWillResignActive:
- applicationDidEnterBackground:
- applicationWillEnterForeground:
- applicationDidBecomeActive:
- applicationWillTerminate:
In all of the above methods, the app gets a limited amount of time
to finish its processing. If the app takes too long, the OS will
terminate the app.
User Force-Quit
iOS 4.x supports multitasking. If an app blocks the UI and stops
responding, the user can double-tap the Home button from the Home
screen and terminate the app.
Note: You may have noticed that when you double-tap the Home button,
you also get a list of all the applications you’ve run in the past.
Those apps are not necessarily running, nor are they necessarily
suspended.
Usually an app gets about 10 minutes to stay in the background once
the user hits the Home button, and then it gets terminated
automatically by the OS. So the list of apps that you see by
double-tapping the Home button is only a list of past app runs.
Low Memory Termination
When subclassing UIViewController, you may have noticed the
didReceiveMemoryWarning method.
Any app that is running in the foreground has the highest priority in
terms of accessing and using memory. However, that does not mean the
app gets all the available memory on the device – each app gets a
portion of the available memory.
When total memory consumption hits a certain level, the OS sends out a
UIApplicationDidReceiveMemoryWarningNotification notification. At the
same time, didReceiveMemoryWarning is invoked for the app.
At this point, so that your app continues to run properly, the OS
begins terminating apps in the background to free some memory. Once
all background apps are terminated, if your app still needs more
memory, the OS terminates your app.
I have seen that the background location updates will work for several hours. But if I go to a place without reception the device will stop to send GPS updates it wont start when I go to a place with reception. This occurs after approximately 30min.
But if I add this, in iOS6, the app won't terminate
[locationManager setPausesLocationUpdatesAutomatically:NO];
Quick answer is pretty much no. Read below though for in depth.
Since multitasking has been enabled on iOS devices that a)your app gets allocated amount of memory and b)the device limits the amount of tasks, that is applications using memory, that occur at any given time. If you take an iOS device and open several apps you'll begin to notice that the app you opened first may have been terminated and reload from the viewDidLoad.
Generally it's safe to say if your app is a recently opened app (or even on a phone where someone clears the multitasking menu often) that the device will not terminate your application in the background.