https://github.com/facebook/react-native/issues/167
"I wanted to start a discussion about the timers and an API that exposes the capabilities of the system timers. A couple of things I noticed were that the timers use CADisplayLink on the main thread and also listen to the UIApplication state notifications. To my knowledge this works well for timers that are coupled to the UI (requestAnimationFrame comes to mind, there may be other uses). I'd like to discuss timers that do other work e.g. interact with the event loop or schedule background tasks, and how they co-interact.
Event loop timers seem to fall into two categories - those that run at the end of the current loop and those that run right after. This is like process.nextTick and setImmediate. These aren't too hard to implement though there are a couple of gotchas like warning if a process.nextTick handler endlessly schedules itself before blowing the stack. I would also expect both of these timers to run even if the app is inactive or backgrounded (e.g. say you get a network response while the app is backgrounded and schedule some work to run soon after - it should run in the background).
Background task timers (setTimeout, setInterval) raise a couple of questions like the semantics of a zero-ms timeout. I would also propose that these run in the background as well to address the use of running code that does not need the app to be foregrounded. And, if the app is backgrounded there is little harm in running UI code anyway -- in cases where it does matter, the timer handler can check the UIApplication state.
Background task timers that repeat are also good candidates for energy optimization. One thing that OS X systems do is coalesce timers where possible, partly aided by the programmer providing a tolerance value. If many running apps schedule timers that can overlap within their respective tolerance windows, the system may wake the CPU just once to run all of those tasks together." - @{ide}
Is this available now??
@Gerry Tan Jr: questions that need answers
I've opened a PR that adds background timer support for iOS here: https://github.com/facebook/react-native/pull/21211
Note that these timers will only fire if your iOS app has a valid Background Mode in use to prevent it from being suspended after a couple seconds (which is the fate of all iOS apps, native or not, if they move to the background without a Background Mode in use).
+1 Any solution? I need this feature to finish my project.
@Pablo Figueiredo Alberto: There are libraries that simulate the effect, but by and large they're task schedulers and probably only work while the app is open. There might be a way to perform this by writing native code
@Harsha Goli: Thanks Harsha. I will look for this.
@Pablo Figueiredo Alberto: HI, were you able to do this ? I need this feature to complete my project :/
I can't believe we don't have such a thing yet ! :(
Yes, it will be very helpful if we can run task in background periodically
It is much needed feature plus it should allows you to schedule background task at specific time.
To @Anthony Benkhebbab 's point: I started using Headless JS for background execution on Android but noticed that the "main" app with respect to non-UI aspects was still functioning, could even continue to persist to the redux store. What does Headless JS do that the main/UI app can't?
@Bren W: as I said the JS context is not getting destroyed while there are some services up and running. On android, once your app goes to background it's eligible for being destroyed by the OS to free memory required by an other active application (e.g music, videogame..). This is when your JS context get lost. To overcome this, Headless JS uses a Service (that can run even through the app is in background, or even closed) and acquire a wakelock for it to operate even when the phone is locked. As the service can only start after the app itself started, and as the JS Context is kept until the main activity itself gets destroyed, your JS code can still run, your redux store is still alive.
I think the main error is to think that when your app goes to background/when you closes the app, the JS context gets destroyed. I don't know the details, but it is not really until the whole process is finished.
@Anthony Benkhebbab: Thanks, that explains it. So while I am currently seeing activity in the UI app even when it goes to the background (not views, but business/redux logic), there's no guarantee that it won't be destroyed by the OS at some point, to free up resources or what not. And of course not to mention wake lock. So I will keep all of this logic that needs to run in the background in headless js.
@Bren W: That's exactly the point on Android at least, you have no idea when the OS will destroy the app, the best you can do is put a maximum of red flags for the OS to know how important your app is (so far i've found STICKY service, startForeground, and ignoring battery optimizations when API > 23)
By the way watchout for phones with API > 23 running Stamina modes and stuff to optimize battery usage. I've taken quite a lot of time to figure out my app was getting closed due to battery optimizations.
@Anthony Benkhebbab: I have not had any luck with startForeground, STICKY and API > 23. setInterval still stops when the app loses focus. Example code - https://github.com/rgstephens/RNForegroundExample
You can quite easily do the job using Android Services, or Wakelocks. The JavascriptCore get loaded only when the application is launched for the first time, so while maintaining a service, the JS Context is not lost. By doing such you can maintain timers and network activity while the app is "closed". But React views are getting destroyed when the app closes so careful, don't put your business logic in your React components.
this is marked as in progress in 2018 but still is not available