6

I am developing an app for iPhone that collects lots of data from vehicles and then uploads it to a remote server. The app itself will be sitting in the vehicle, connected to its battery for power, and collecting data without much user interaction for most of its life. Given that, it is important that these uploads be happening in the background and that the app be "woken up" be the system to do the upload. Also, this is an enterprise app, so the app will NOT need to be put through Apple's approval.

Given these requirements, I had thought that Apple's new iOS 7 background fetch API would be a good solution for my problem. Of course, since I'm not using it entirely as intended, there are some things that could cause some issues for me that I wanted some clarification on.

  1. After watching the WWDC video on the new API, I understand that iOS will attempt to recognize the app's usage patterns and have it woken up only right before it's used. If the app is rarely opened, will that cause it to, eventually, stop doing these background updates?

  2. When I do use this API, the completion handler block I'm given takes a UIBackgroundFetchResult as an argument. If I pass in UIBackgroundFetchResultFailed each time, would that cause iOS to think that I still need that new data and keep waking the app up?

  3. Lastly, since I'm clearly using this API in a different way than it was intended, could someone recommend a better way to do this that would still meet my requirements?

Kara
  • 6,115
  • 16
  • 50
  • 57
Zachary Gay
  • 93
  • 1
  • 9
  • 1
    +1: I too found the WWDC video to be lacking on these points. IMHO, I wouldn't pass `UIBackgroundFetchResultFailed` unless the upload/download actually did fail. If you're doing uploads, and they're successfully completing, I would prefer passing `UIBackgroundFetchResultNewData` instead. This is what I infer from the talk, but I'm still looking for documentation to back it up... – JRG-Developer Dec 13 '13 at 22:37
  • Hmmm... a good point. My only worry in that regard is that the system could then decide that my app shouldn't be woken up again because I have new data... Although, if iOS can't get a handle on when the app is going to opened next, maybe it would just keep waking it up. I'll have to do some testing to see for sure. – Zachary Gay Dec 15 '13 at 06:27

4 Answers4

3

With this given: "app itself will be sitting in the vehicle, connected to its battery for power, and collecting data without much user interaction for most of its life" and "Also, this is an enterprise app, so the app will NOT need to be put through Apple's approval.", why bother with background fetch API at all?

Pick a background mode such as VOIP, and run your task in background mode. Your network connection will stay alive and carrying out any sending/receiving even if screen was locked.

user523234
  • 14,323
  • 10
  • 62
  • 102
  • 1
    -1: Even if the network connection is kept alive and the device is *always* connected to battery, using VOIP (or any of the other background modes prior to iOS 7) isn't ideal as this isn't what they were intended for. In such, what if the behavior of these modes change in the future? You're misusing them, so your implementation is likely going to be fragile and break. Or what if eventually it's decided they want to upload the app to the App Store? The app would need to be re-written or risk rejection. For these reasons, I think this is not a good idea. – JRG-Developer Dec 13 '13 at 22:46
  • @JRG-Developer: Your reason for up voting the other answer is "+1: These are definitely good links to understand NSURLSession better. However, this doesn't actually answer the related questions posted by the asker. " . I guess I can debunk your reasoning for down voting mine. But that would not be necessary. – user523234 Dec 14 '13 at 07:11
  • @JRG-Developer is actually right on with this one. This is actually the second version of a system we'd previously built and in the first version, we used the VOIP background mode to transmit data. That didn't work for us because it only allowed our app to be awake for 10 seconds before it would suspend the app again. Given the amount of data we were transmitting (over the cellular network, no less) this 10 second window was not enough. – Zachary Gay Dec 15 '13 at 06:31
  • Maybe I could start a background task or use the new iOS 7 background transfer service API while the app is open during that 10 second window and the app would continue executing until I told it to stop. Any idea if that would work? – Zachary Gay Dec 15 '13 at 06:34
  • +1 this should be the accepted answer. But instead of voip use background location services, create a location manager and set it to the lowest gps accuracy. this gives your app unlimited background time and because it is a car app this will be accepted to the app store (after some arguing) I've done this for several apps (in the store right now) – woens Jul 07 '15 at 08:16
2

I know It's been awhile, but just for the record.

I suggest you use AFNetworking, it has background support. Almost everything you need to know is in github page.

For running in background, check this question: afnetworking-background-file-upload. Do not know if the code in the question is working, but the answer might help.

Community
  • 1
  • 1
Frade
  • 2,938
  • 4
  • 28
  • 39
0

IMO, the new ios 7 api is not powerful enough for your app.

  1. background transfer service requires wifi (do you have wifi on the vehicle?) if you don't use background transfer service, you will only have ~30 second to upload your stuff.
  2. background fetch is not called that frequently. From my testing, most of the time fetch happened when user unlocks the phone.

That said, the location service might be a good fit here. any time your vehicle moved to a different cell tower your app can run for about 3 min.

https://developer.apple.com/library/ios/documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html

Erben Mo
  • 3,528
  • 3
  • 19
  • 32
0

I believe you could use silent push notifications to wake up the app which in turn would do a background upload.

David Pettigrew
  • 299
  • 2
  • 10