I am testing our iBeacons on iOS 7.1 and I can detect beacons correctly when I am in foreground and invoke the app from the background. However the issue comes when user has killed the app. The "didDetermineState" callback get invoked twice when I am in the beacon region while the app is killed. Am I missing the obvious or has anyone experience this same behavior ?
I have seen this happen not just when the app is completely killed, but in other cases, too. You will need to add filtering logic to your region callback methods, so if you get multiple calls it doesn't cause trouble in your app.
Another common issue is that you will get an exit region notification, followed within a couple of seconds by an entry region notification. Again a software filter is the way to deal with this. An example of a software filter for iBeacon callbacks is described here.
Related
There are different ways to run tasks in the background in Android and iOS respectively. I have found What is the best way to schedule task in android? as well on stack overflow.
I am wondering which is the best way using react-native only. Would it be good enough to use setInterval or setTimeout for tasks that have to run daily or every few hours?
Would not those tasks be killed by the OS?
Any ideas or suggestions?
I will answer my own question to see if this information can be of used by anyone looking for it.
Since the different mobile OSs tend to kill background jobs, or stall them to save battery, there are few deterministic methods to schedule tasks in react native. I use a combination of the following:
Offload timers to the background, which work with the app in both fore and background https://github.com/ocetnik/react-native-background-timer (!If you use create-react-native-app you must eject it)
Use a background-fetch for iOS and HeadlessTask in Android, here is a decent library https://github.com/jamesisaac/react-native-background-task
Use geolocation updates to wake up the app and start threads https://github.com/mauron85/react-native-background-geolocation.
I guess you can follow similar strategies using bluetooth wake-ups.
Push notifications from a server to ensure deterministically that the app wakes app (except it having been killed by the OS). In iOS, ensure that you call notification.finish() to avoid being discriminated by the task handler algorithm.
For Android you can try to use AlarmManager API https://github.com/vikeri/react-native-background-job.
Beware of the dragons: your app might be closed if it abuses execution time or memory usage after a system wake up. You may have to rehydrate all listeners after the phone was left without battery. So the user still needs to interact heavily with your app.
Update:
From Android O there are very strict background execution limits. When using a HeadlessJSTask service, ensure that it is launched as a foreground service if you want it to last longer than a few seconds. It may require a notification with it. Take into account that only loading the bundle can take up to a few seconds, depending on your app and the device.
As a matter of fact there is not any sufficient way for that. but we can remark mauron85 as a way which is better then others on android but also it doesn't work perfectly on IOS. for example if app has killed by user the job would not keep working or there is not any control of job execution quantity the job fires each time device changes its position.
other components like react-native-background-fetch and react-native-background-task have the limitation of job execution period(the job repeats after each 15 minutes and there is no way to decrease this time period) and they just work on android.
it would be great if Facebook react native has some practical solution for this problem.
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
I have created the application, which track the GPS Location of user at specific time period. This process is run 3 times in background. So, App need to keep alive in background.
To achieve the our requirement, we use the Location manager (GPS) running in the background. So, it will never been killed by OS. Also, we have run the background task thread while App is in background.
This approach working fine on iOS 6 and before and running more than 10 minute in background.
But in iOS 7 Application going to killed after 10 minute.
Please need suggestion for keep the Timer alive in background.
We would appreciate the earliest response. Thank you in advance.
How to keep app running alive in background in IOS 7 without affecting the battery life.
There's no reason for the app to be killed if it has background location tracking functionality in the Info.plist file and doesn't try to abuse the benefits of that permission.
I'm not sure what's your use case for the tracking functionality, but -- together with an assumption that if there's no record from some period, the tracked device didn't change the location -- setting a distance filter would allow to track the location all the time.
That also allows to put a smaller burden on device's battery, because in certain activity types handled by CLLocationManager, the device may put the location service in idle state if it doesn't detect any significant movement.
if you want to keep app active in background and don't want to go to appstore for some reason (for example you are developing something for your company with using enterprise developer program), you should check deferredLocationUpdates(even on devices which doesn't support them, you just get error in your delegate but app will work) and don't call stopLocationUpdates while in background.(if you use this on app for appstore you have to explain why you needed this to apple of course).
So I've read that in iOS, all timers will pause when your app is running in the background. I've also read that you can run tasks in the bg using beginBackgroundTaskWithExpirationHandler (like so).
What I am trying to achieve is to call a method once every 3 minutes, and another method a fixed-amount of time before the first one. I have managed to do this within one NSTimer which repeats in a way that lets me do this. It works fine but is obviously disabled (or paused) when the app is in the background - I can only assume because of the reason described above.
Does anyone know if there's a way to run a timer or at least call something after a specific amount of time so I can do this?
Basically if you want to continue running active in the background you have to meet one of the following requirements. From the Apple docs:
Implementing Long-Running Background Tasks
For tasks that require more execution time to implement, you must
request specific permissions to run them in the background without
their being suspended. In iOS, only specific app types are allowed to
run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Apps that implement these services must declare the services they
support and use system frameworks to implement the relevant aspects of
those services. Declaring the services lets the system know which
services you use, but in some cases it is the system frameworks that
actually prevent your application from being suspended.
http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW24
I started off on the Win8 metro app (javascript) development recently. For notifications, it is clear how the WNS notifications will be useful for creating live tiles.
However the use case for local notifications is not clear to me. I have these two questions:
is it correct to assume local notifications make sense only for apps that would run in the background e.g. when other apps are running or when the system is locked?
if the above is not true, then kindly suggest some examples of when local notifications will be useful.
regards
CGere
Local notifications are useful to update your tile on the start screen that persist after your app was closed/suspended. For example you might want to update the tile when your app closes with some context, perhaps an image from the last level of the game they were on or such.
When your app goes to the background it has a short period of time to suspend after which your app will no longer be running and thus unable o update the tile. You can however create a background task to run on an event/timer to do some work (such as update your tile).