On Wed, 2014-06-25 at 15:39 -0400, Marc Deslauriers wrote: > That's not how bluetooth devices work on iOS. If your app is in the > foreground, > you can get realtime events. If your app goes to the background and gets > suspended after a couple of minutes, your BT device needs to accumulate data > and > send it periodically at which point iOS will start up your application in the > background for a maximum of a few seconds just long enough to receive and > process it.
It is how bluetooth devices work in iOS, according to the docs. The system wakes the app when a backgrounded app needs to process data from the bluetooth device. It does not require any special buffering to be implemented in the device. See https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW6 > >>>> I'm sorry, but AFAIK, iOS has very limited background service > >>>> capabilities, and > >>>> it seems to be doing just fine. That is the model we should be looking > >>>> at, not > >>>> the Android model. > >>> > >>>> How would you write those apps for iOS? > >>> > >>> https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20 > >>> > >>> Apps can have long-running background tasks for certain things, on iOS. > >> > >> Apps can only run in the background for a limited time, and they can use > >> certain > >> APIs to get woken up regularly, but they can't run in the background save > >> for a > >> few exceptions. This is why IRC apps on iOS disconnect after a few > >> minutes, or > >> are designed for jailbroken devices. > > > > No, apps can run in the background indefinitely, per the documentation > > link I provided above, in order to handle a situation in the specific > > list of situations described in that documentation. Skype does not > > automatically disconnect after a few minutes. And AFAIK, it does not > > need to remain in the foreground to stay on a call. > > No, but they need to use the services provided by iOS, they can't just run in > the background. This is what we want to do also. The services in iOS are generic framework services. There is no OBD-II service for example. There is simply the core bluetooth service, and it handles the waking of the app and passing the data to it. The support for background processing is clearly documented in the iOS App Programming Guide. It does not require implementing a new type of service to handle new types of data over USB or Bluetooth. The statements from this and other threads implies though, that one would have to implement new system services for such things, on Ubuntu. If however, we implement something in the same way that iOS implements, I am fine with that. I don't need a separate process to do background processing. I just need the app to be waked and handed the data when it is appropriate to do so, without me having to get a new system service written and shipped on the image, in order to do what I need. > > > > Maybe the app with full UI needs to remain open always on iOS, and there > > are not actual separate background processes without UI, but they do not > > need to remain in the foreground to remain processing. > > > > Perhaps you should tell the developers of all the iOS IRC apps how to make > their > application run in the background: > > http://colloquy.info/project/wiki/MobileFAQs#CanIrunMobileColloquyinthebackground > > http://www.macworld.com/article/1153252/linkinus_irc_iphone.html > > http://www.appannie.com/apps/ios/app/limechat-irc-client/ I don't know what those apps are doing exactly for creating a connection, but prior to iOS 7 at least, I don't think "IRC" fit into any of the acceptable long-running background tasks allowances. As of iOS 7, it seems to fit under the "Fetching small amounts of content regularly" as documented in the iOS App Programming Guide. To quote the guide: Fetching Small Amounts of Content Regularly In iOS 7 and later, an app that retrieves content regularly from the network can ask the system for background execution time to check for new content. You enable support for background fetches from the Background modes section of the Capabilities tab in your Xcode project. (You can also enable this support by including the UIBackgroundModes key with the fetch value in your app’s Info.plist file.) At appropriate times, the system gives background execution time to the apps that support this background mode, launching the app directly into the background if needed. The app object calls the application:performFetchWithCompletionHandler: method of its app delegate to let you know when execution time is available. When the application:performFetchWithCompletionHandler: method of your delegate is called, use that method to check for new content and to download that content if it is available. When your downloads are complete, execute the provided completion handler block, passing a result that indicates whether content was available. Executing this block tells the system that it can move your app back to the suspended state and evaluate its power usage. Apps that download small amounts of content quickly and accurately reflect when they had content to download are more likely to receive execution time in the future than apps that take longer to download their content. When downloading any content, it is recommended that you use the NSURLSession class to initiate and manage your downloads. For information about how to use this class to manage upload and download tasks, see URL Loading System Programming Guide. So, those IRC clients will need to implement this per that documentation. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
