I have read a lot of information regarding the foreground/background scan periods and issues for long scans on Android 7 but I am confused as to what should be configured for best results in the latest alt-beacon library ( 2.15.4 ).
We have implemented a foreground service and bootstrapping and require the library to do the following:
App in Foreground scan for 1100ms, sleep 0 ms
App in Background scan and 1100ms, sleep 10000ms
We are aware that there will be edge cases when beacons are not detected due to start/stop scanning but would prefer this over the potential of the app scanning being killed by the OS due to long running scans.
What setForeground... setBackground... values should be used for the above requirements? OR should we not use these methods and just use the defaults?
Will this cause the "Scanning to frequently" issue and how would we get around this with settings as close as possible to our requirements?
The scan rates you describe will work on most phones by doing this:
beaconManager.setForegroundScanPeriod(1100); // Default, so this line not needed
beaconManager.setForegroundBetweenScanPeriod(0); // Default, so this line not needed
beaconManager.setBackgroundScanPeriod(1100);
beaconManager.setBackgroundBetweenScanPeriod(10000);
BackgroundPowerSaver bps = new BackgroundPowerSaver();
However, on Android 8+, time between scans will be throttled to about ~15 minutes by the operating system. If you cannot accept this, then the only alternative is to instruct the library to use a foreground service. If you do configure a foreground service, then you can get that exact background rate of scanning you want even on Android 8+.
I say this works on "most phones" because big Chinese manufacturers (e.g. Huawei, OnePlus, Xiaomi ) have started forking their Android versions starting in late 2017 to implement aggressive power saving features that block beacon scanning in the background. The proprietary forks either block scanning when the screen is off (Huawei see here and here) (Xiaomi see here) or block foreground services (OnePlus see here). These effectively break Android apps from working properly on their operating system forks.
Related
I would like to know if there are limitations regarding how often I can execute something in the background. I found this library : background fetch and it says that on the iOS part I cannot execute it more often than 15 minutes.
Are there workarounds for this?
My purpose is to check in the background the available Bluetooth devices detected and to send them to a database.
I only have experience in android and I'm not sure how to convert it to iOS or if it is possible.
Yes, there are limitations imposed by iOS. It will decide when your app is given time to execute background tasks such as a fetch of web data. It can be more frequent than 15 minutes but on average it may be every 20 minutes at best. It might be two hours or more. We are not privy to the algorithm and cannot predict the result.
Known factors are power state, how well your app conforms to the rules and gets its work done in the time allotted, and some measure of how (and when) the user uses your app. Low battery? Fewer background tasks allowed. User never uses the app before 8AM? Few fetches called overnight. It's all beyond developer control.
A developer can use a timer to trigger a routine task but it's only relevant if the app stays active in the foreground.
I want to create an iOS app using React Native. One of the primary features of the app is that it runs constantly in the background. It also requires using GPS btw (in case that is important).
I have had a number of devs tell me its not possible to do this for iOS, however I have read that it is do-able.
Is this possible to do in the iOS environment? Mainly, if the app is running when the phone is powered off, can you make it open when the device is restarted without the user opening it?
I should say that I am a RN novice and any help is much appreciated.
If your app gets permission to get location while it's not in the foreground, then you will get periodic updates and some time to process it.
For example, if you are giving driving directions.
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW10
If there is no good user benefit for you to get the location in the background constantly, you might be rejected. Apple suggests region monitoring instead
iOS supports the delivery of location events to apps that are suspended or no longer running. The delivery of location events in the background supports apps whose functionality would be impaired without them, so configure your app to receive background events only when doing so provides a tangible benefit to the user. For example, a turn-by-turn navigation app needs to track the user’s position at all times and notify the user when it’s time to make the next turn. If your app can make do with alternate means, such as region monitoring, it should do so.
I have no idea how RN wraps this behavior, but no matter what it does (or what a plugin might do), the core iOS behavior is how it is described in that URL.
I verified yesterday (at least on iOS 11.2 simulator) that automatically restarting the app (and the location tracking) after phone reboot works.
The key point is that startMonitoringSignificantLocationChanges needs to be on to wake up the app after reboot. For me the difficult part was figuring out when to turn it on, because I couldn't find a reliable way to detect when the phone is being rebooted or run any code at that point. However, based on initial testing it looks like startMonitoringSignificantLocationChanges is independent and doesn't negatively impact the usual location updates, so now I just leave it on all the time and toggle startUpdatingLocation / stopUpdatingLocation on top of it based on Core Motion-detected activity.
Otherwise requirements are the same as for any location tracking on the background, i.e. handle permissions and don't process too much. Apple documentation explains how to detect that the app was relaunched by a location event.
Here's a react native module which basically helps you achieve what you're describing: https://github.com/transistorsoft/react-native-background-geolocation
I have looked at some posts within this domain (e.g. iOS background fetch custom interval) and I am concluding that what I need to do is not possible.
I have an external device communicating to ios over bluetooth (NFC chip card reader). The external device goes to sleep if not pinged every minute (59 seconds).
When the app is in the foreground I can manage the pinging. When in the background I want to continue to ping. Is this impossible?
The ping operation is fast; it is just to send a message and I dont need a response back to ios.
(What works really well is the opposite, bluetooth communication can flow from the device to ios from the background. That is done via UIBackgroundModes in Info.plist to bluetooth-peripheral.)
Please note that I am feeding the iphone from external power in the application here. It is an industrial application; and the normal iphone usecase is not applicable.
Short answer, no. The best iOS offers is back ground fetch. But there is no guarantee when background delegate method is called. You can specify a timespan as a guide but it primarily based on how often the app is accessed.
https://www.raywenderlich.com/143128/background-modes-tutorial-getting-started
I have an app that monitors iBeacons entry/exit events. When it receives an event it forwards the event off to a server. The app continues to work (e.g., the server continues to receive updates) after the user minimizes and/or force closes it (so it works correctly in the background).
However, after a phone has been away from any iBeacons for a sufficient amount of time (e.g., overnight) and is brought near iBeacons again, the app stops receiving enter/exit updates until the user opens it up again (brings it into the foreground). If the user minimizes/closes the app at that point, updates continue to work correctly in the background.
Is anything that I need to do to allow long running monitoring updates in the background? After a while does iOS stop background monitoring?
Note: I am running iOS 9.3.1
iOS Apps are supposed to be able to detect beacons indefinitely in the background when they have been granted "always" location access.
This is the second report I have heard like this, so I wonder if it is a bug or a change in a new iOS version. Reporting your iOS version would be helpful.
One possibility: the network calls may be being blocked and not the beacon detections. You could test this hypothesis by adding NSLog statements to :
Log on beacon detection
Log on successful and unsuccessful connection to the server.
Once you add the above, reproduce the issue where you don't see events on your server. Then connect your phone to XCode and go to Devices, and look at the recent NSLog output to see:
Is there a line indicating the beacon was detected?
Was the server connection successful or not?
If you find it is the network connection that is failing, you may be able to correct the situation by requesting additional background network permissions.
EDIT: One other thing you might try when a detection is not made is launching a different beacon scanner app in the foreground like Locate. This will force an OS bluetooth scan and it might kick off your app's detection. If this works, it would tell you that bluetooth scanning had been suspended across the phone.
I'm currently developing an app where the device's location should be send to a server. I've worked through the MSDN articles on the background agents and accessing the location. This works so far. My location is transmitted to the server when I've triggered a location change which is farther away than the set MovementThreshold.
However, I've read that testing of background agents can be complicated. If you use the Emulator, you can easily change your device's location very often. But on a real phone, location background services are limited in their idle runtime to 30 minutes and execution of commands should only take up to 25 seconds. Background agents can also be disabled by the user from the phone's settings screen. They are also deactivated, when the agent crashes more than two times in a row. Another limitation is that inactive background agents are stopped after 4 hours, if they don't update an apps live tile.
My app updates a live tiles counter, so I think my background agent should be running up to 14 days without restart from my app. I've tested the app from yesterday to today and saw the background agent running (when looked up from the settings). There was also the small dot in the upper bar visible, indicating that a programm is accessing the phones geo location. However, sometimes the dot vanishes and my background agent is killed for no obvious reasons.
Therefore my question are:
How can I reliable test geo location on a real device without the need to travel with phone and attached debugging laptop?
How can I test in a timely manner for the timeout scenarios I've mentioned (30 min, 4hrs, 14 days)?
How can I check for these two crashs of the background agent?
I think I've made some missinterpretations of how WP8 defines Background Agents. The new WP8 background agent for location is only active, when the app is running. This means that the app must not be closed with the back button. However, it can be switched to the home screen with the windows button or with a long hold back button to access other apps from multitasking.
Regarding my questions:
How can I reliable test geo location on a real device without the need to travel with phone and attached debugging laptop?
How can I test in a timely manner for the timeout scenarios I've mentioned (30 min, 4hrs, 14 days)?
I still have no suitable solution. You are somewhat limited to testing with real devices and the necessary time required to test your constraints.
How can I check for these two crashs of the background agent?
I don't know how to check for this programmatically. It may be, that a user can see this crashing app as a blocked app in the list of background tasks of the phone's setting. There should be a way to detect a blocked app from this list with the help from the links I've supplied above.
For my project, I needed a location background agent, which runs even with locked screen or with no open app. Therefore I've used a PeriodicAgent to require the location once every 30 minutes so that I can send it to the server. But be aware that this background agents cannot access your application settings or classes (see Communication between foreground app and background agent).