I wonder if the background time that an app receives when entering an ibeacon region can be used for opening a session with an external accessory object. Can the app then also keep on running in the background while the session remains open?
This of course assuming that the external-accessory background mode is enabled.
While I have not tried this myself, I do not see any reason why it wouldn't work. You would need to have a legitimate reason in Apple's eyes to use the external-accessory background mode in order to get your app approved.
Assuming you have this, as soon as the app sees an iBeacon in the background, the app gets about 5 seconds of run time, which should generally be sufficient to establish a connection to an external accessory. If the connection is made, and the app is exchanging data with it regularly, the external-accessory background mode should keep it going in the background indefinitely, so long as the connection to the external accessory stays open. So long as this is true, the app will probably be able to get ranging updates in the background indefinitely, too.
It doesn't take a huge leap of logic to see that you could build a device that behaves as an external accessory and an iBeacon simultaneously, and use this to get around the usual iBeacon background rules. That said, you'd need to be careful that Apple doesn't think this is illegitimate, or the app could get rejected quickly. To avoid this rejection, you probably would need to be providing some benefit to the end-user via that external accessory channel.
Related
I'm an Android developer and working on a wearable app that runs on Galaxy watch 4.
In short description, this app use a foreground service that's connected to Mqtt broker and receives real-time alerts and displays them to the user.
Up until recent system SW upgrade I used a Wifi Lock to keep the network alive for my app and the foreground service allowed my app to keep running in the back during idle mode. I also used a Wake Lock to wake the watch when an alert was received so it can be displayed to the user.
On 16.02.22 the watches were updated and after that, whenever the watch turns off the screen and goes into idle mode, my application disconnects from all OS resources (network, even CPU). It seems like the process is suspended. When I bring the watch back from idle, my application continues running but its stays in the background and not returned to the fore.
I tried different approaches to solve this, such as Ambient mode and more, all my efforts to come up with a workaround met a brick wall.
Am I missing something?
I see other apps that use body monitoring via the sensors for example, that keep working and throw notifications even when the watch is idle.
Please help, how can I keep my app alive and the service running (and using the network) during watch idle mode?
I am building an Android App to control power outlets with a smartphone. The app features an Android Wear app so people can control their lights right from their wrist.
When the user wants to control a light I send a String action via the MessageApi from the smartwatch to the smartphone, which receives this action in a WearableListenerService and sends the appropriate network signal to the power outlet/gateway in an AsyncTask.
This works fine as long as the phone has not been in idle for too long. However if the phone is still on the table for too long and doze kicks in Wear actions do execute very slow or sometimes not at all. I guess this is in part intended behavior however it is not practical in my case as the user cant wait that long for his lights to turn on if he wants to enter a dark room.
I am aware that doze completely cuts the networking for everything except FCM/GCM if you are not on the doze whitelist. But even when my app is on this whitelist and the networking part works actions can take a long time to execute on the phone.
So my specific question is:
Whats the recommended way to handle this scenario, where an action from a wearable device needs to be done via network on the connected smartphone which is in doze mode?
Is there a way to exit doze for a quick amount of time to execute calculations triggered by the wearable companion app faster?
I know the AlarmManager has a new method that works even in doze mode, but will this fix the processing delay too? Firing an alarm after receiving a MessageEvent from MessagApi seems like a workaround to me.
Or maybe is an AsyncTask just the wrong way to handle background networking and thats where the delay comes from?
Actually, there are a few options that you can do to handle Doze's effects as given in Adapting your app to Doze. You may want to consider the following options:
If your app requires a persistent connection to the network to receive messages, you should use Google Cloud Messaging (GCM) if possible.
GCM is optimized to work with Doze and App Standby idle modes by means of high-priority GCM messages. GCM high-priority messages let you reliably wake your app to access the network, even if the user’s device is in Doze or the app is in App Standby mode.
To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle(). With these methods, you can set alarms that will fire even if the device is in Doze.
However, please note that with these methods, neither setAndAllowWhileIdle() nor setExactAndAllowWhileIdle() can fire alarms more than once per 9 minutes, per app.
Please try going through Optimizing for Doze and App Standby for a more detailed information or discussion.
In addition to these given documentations, the same options in handling Doze were also given and discussed in Diving into Doze Mode for Developers which might also help.
I have an app which build on Xcode objective-c, I have a code and I need that code to run even if the user press the home button.
Is it possible to do it?
Refer to the Background Execution chapter of the App Programming Guide for iOS.
There are three difference scenarios for background network requests:
The user initiates a simple request and expect the server to respond reasonably quickly, but want to make sure that if the user leaves the app before the request complete, that it really has a chance to finish gracefully in the background.
See the Executing Finite-Length Tasks section of the aforementioned guide for a discussion on how to request a little extra minutes after the user leaves the app, and that may be sufficient to finish the network request.
You are requesting large volumes of data (or uploading a lot of data), where it is anticipated to possibly require more than a few minutes to finish, especially on slow connection.
In this case, as Phillip Mills pointed out, you can use a background NSURLSession (as discussed in the Background Transfer Considerations section of the URL Loading System Programming Guide: Using NSURLSession guide.
You want to periodically make very quick calls to your web service to check to see if there is any new data, even if the user isn't using your app at the time.
In this case, you should look into "Background Fetch". See the Fetching Small Amounts of Content Opportunistically section of the App Programming Guide for iOS. You can't control precisely when it checks, but it is a way to initiate short network requests even when the app isn't currently running.
Note, if this opportunistic background fetch determines that there is a large volume of data to be downloaded, you can combine this pattern with the previous pattern (the background NSURLSession I discussed in point #2).
For more information on this, see the WWDC 2013 video, What's New with Multitasking.
Here is the deal, I have an application in which the device listens to iBeacons in the background and timestamps the moment user passes the area in range. Initially, as soon as I get a didEnter call back I used the chance to save the information to the iCloud using CloudKit. But sometimes on a bad luck, the internet is not available at that very moment and saving fails (e.g. when the user is in elevator).
I tried to use FMDB to write the information to database and sync them when app enters foreground. That doesn't work either. Since iOS8 by default encrypts the disk and does not allow me to write to disk after the phone gets locked by the user or the phone get a reboot (eventhough there are some APIs in NSFileManager to let you write to a file until it's open called "NSFileProtectionCompleteUnlessOpen" but they don't work after few hours of phone being locked. Perhaps a bug).
Third solution was to write them into a array and use reachability to sync them to iCloud as soon as I get a chance (on location callbacks, appdelegate callbacks or reachbilityChanges notification). But this solution is not secure to app termination. If the user termiate the app I dont have enough time to do anything.
The last solution is a mix of all together. Write to array if the disk is encrypted. write to disk if not encrypted. sync them all together and save to internet at any time possible. Do not want to put myself in alot of hassles before getting some help.
Do you have any idea how to deal with this?
You have 10 seconds of time to execute in the background after a region entry/exit event. You can save the data into an Array in UserDefaults during this time. Then do the syncing with CloudKit when the app is active.
The sole user interaction for my app is through the accelerometer, so there is never a reason for the user to touch the screen. What I need is the ability to elevate a non-touch event so that the system recognizes it as user interaction, delaying the screen timeout. Either that or I need to be able to manually extend the timer.
I have already read (and commented on) the thread about disabling the timeout. That is not what I need. The interaction my users are performing is very explicit (turning it over 180 degrees) so it won't happen if it is set down or stuck in their pocket (unless they are riding a rollercoaster.
Currently, the device is constantly shutting down when the user is in the middle of actively using my app.
Have you tried flipping UserIdleDetectionMode from enabled to disabled again to see if it resets the timer? If that works you could do it in response to your application events.
Otherwise there is no means of simulating user events, so I would say you are out of luck on this one for the moment.