Search the Community

Hi there, I have a very nasty problem again with BLE background mode. Since I have the feeling that I have read all available articles and references about this topic worldwide, I still got no clue howto get this working. All is working as expected under forground mode. I hope that I can find some help or new ideas from here, because my head is going to be empty right now. My setup is: Rx10.3.3, XCode 11.4.1, iOS13.4.1, modern iPhone/iPad devices, all running fine with debug and release My task: I need to connect external Bluetooth LE peripherials, which works well in foreground. They send data string (20 bytes) via unspecific custom characteristics, and I receive a HEX string, all that is fine. With integrated logging functions in the app, I can monitor all behaviour in fore- and background. Also debugging in fore- and background is no problem. The devices send new datastring every < 2 sec., and the other every < 12 sec., anyway, both get killed after a while. Maybe there are some restrictions in the datarate, I have read somewhere that peripherals > 2 sec. might considered to be killed (?), but I cannot find anything about that in the official docs (also not much in the forums, seems only one case). The connected devices stay connected, I cannot see any unusual behaviour, moreover I test with three different hardware types, all behave same. So the issue seems not to be caused by the peripheral hardware. I use the following settings: Background modes: audio, bluetooth-central (audio is used for Tts text-to-speech also in background, but its not used currently when receiving the data sting). Info PList NSBluetoothPeripheralUsageDescription (deprecated, but shouldn't it be there for older devices ?) I didn't see any hint that this might be harmful. NSBluetoothAlwaysUsageDescription (defining both should be any problem, right ?) Permissions FMLocalNotificationPermission = true; Location: I do not use that, since Apple rejected this once, for adding an "unused background operation". Some time before I added this background location as workaround to keep background mode permanently running. I've made also some experiments before to add bluetooth-peripheral mode, as workaround to keep background mode permanently running. Both workarounds should be not necessary, but I was searching for a stable way to keep background active. I touch the location in foreground, so that the Location permission alert appears to the user,, since I think that location might be relevant for Bluetooth as well, same as is under Android. But I don't use Location in foreground, but in the past it seems that location permission alert seemed to help keeping background active.. When I take the location out completely, then also the Bluetooth LE permission alert seems not to appear every time, so sometimes BLE stays unavailable, and I need re-install to fix that problem. Thats why I touch the location in foreground, to enable location, and then I don't use the location any more, but BLE works with that approach in foreground. Device capabilities: I don't set specific BluetoothLE capabilities (UIRequiredDeviceCapabilities - bluetooth-le), as I never had to, and it works in foreground. Application events, I handle all of them, and especially at WillEnterBackground I stop some unneeded timers and delay the Threaded ringbuffer for receiving and processing the data, by TThread.Sleep(500);. (I used this sleep method before, and it seem to work well under older iOS, but I never checked that too deeply). on BecameActive I restart the timer and threads With TThread.Sleep(500); I throttle the thread which processes the incoming data (there is no data overflow, datarate is too small). I can see the processed incoming data, also in background, the ReadCharacteristic appends the data to the ring buffer, and then every 500ms the thread still seems to run and process this. In background I stop running timer, and I can see data from the periperal coming in. So far, so good, but longer operation (> 1min, > 10min) might kill the app in background. With kill I mean, its not only in background stopped, but the app is killed and restarts fresh. There is no other resource shortage, enough memory, etc., no need to be killed IMHO. I don't see any place where my app could get stucked, so that Apple might push me out of business, I tried to implement all measures to keep everything lightweight, asynchronously, only the threaded ringuffer sleeps for 500ms every cycle. I can see the data package running through the process handler, even debugging in background is possible. Please let me know if you have some helpful hints here, because I got stucked a while now by this issue, I'm at my wits end right now.

Hello, please tell me who knows how to switch the application from the background to foreground. iOS Thank you!

Hi there, I'm checking in iOS (and later for Android, Windows, etc.), what is the best, right way to Sleep in a background mode of the OS. The implementation for iOS seems to be same, as Posix, for iOS, Android, Macos, but I didn't checked that. My goal is to stop any OS operation in the background mode, to avoid killed apps by the OS. While the Thead loop is still active, but only throttled. TThread.Sleep - uses usleep, which is external function, as far as I know based on nanosleep - is this really affecting the current thread only ? class procedure TThread.Sleep(Timeout: Integer); begin {$IF Defined(MSWINDOWS)} Winapi.Windows.Sleep(Timeout); {$ELSEIF Defined(POSIX)} usleep(Timeout * 1000); {$ENDIF POSIX} end; System.SysUtils.Sleep - is bascially same {$IFDEF MSWINDOWS} procedure Sleep; external kernel32 name 'Sleep'; stdcall; {$ENDIF MSWINDOWS} {$IFDEF POSIX} procedure Sleep(milliseconds: Cardinal); begin usleep(milliseconds * 1000); // usleep is in microseconds end; {$ENDIF POSIX} System.SyncObjs.TEvent.WaitFor - is defintively based differently - uses a sem_timedwait (here and here also) - this probably waits by counting in a semaphore, so its not a "real" sleep of the OS, right ? Shall I better use Sleep or TEvent.WaitFor, to let threads sleep in the OS, while avoiding too many wakeups and operations in the background ? Is TEvent.WaitFor really sleeping, from a iOS OS perspective, or will it be seen as running app ? What I assumed before is that TThread.Sleep really stops the thread, and passes back CPU operation to other tasks, but I'm not so sure anymore under IOS.