guaranteed delivery for uploads after network reconnect, even if my app is not running

Question

I'm spec-ing an iOS app (which will be built outside of our company) which will upload a user's data entry to a server. If the device is not connected to the Internet, we'd like to save data on the device and upload it when the network is re-connected. (The app will primarily run on iPod Touch devices that will be disconnected most of the time).

If the user unlocks the device and re-opens our app after the network is reconnected, then uploading to the server should be easy because the app is running.

But what if the app is not running, where "not running" can mean one or more of:

• device was power cycled
• user has locked the device and it's sitting in his pocket
• app crashed
• user exited the app
• user started using other apps so our app isn't running in the foreground anymore
• are there other cases?

In the cases above, is there a way (ideally a battery-efficient way) to ensure that local data is uploaded soon after Internet connectivity is restored? Is the answer different depending on which of the cases above caused the app not to be running?

And is there a minimum iOS version the device will need in order to enable some (or all) of the above not-running cases to still upload when the app is not running?

My apologies if these are obvious newbie questions-- I'm not an iOS expert.

Depolarize

What does the server-side interface look like? – Etter

It's flexible. Unless there's a reason not to, it will probably be a SOAP or REST web service. But we're open to other protocols if needed. – Depolarize

When you say "upload" are you just going to be uploading some sort of structured data, or binary data as well? And how large is the data? – Etter

Mostly small structured data (probably under under 1MB), although we might later add uploads of small pictures under 5MB in size. – Depolarize

Answer 1

There is an interesting technique that is used by among others Instapaper and News.me(the pioneers of this technique) where you use region monitoring to initiate background downloads or uploads. Marco (Instapaper) blogged and talked (in episode 80 of the Build and Analyze podcast) about his communication with Apple so it should be a allowed in the App Store.

---

In brief the technique is that you set up certain regions (geofences) like "home" or "work" and respond to the locationManager:didEnterRegion: (and similar) callback(s). Your app will wake up from the background once you enter the pre-specified region and you can check to see if there is any data to upload.

This technique won't guarantee that the data is uploaded when the network reconnects but it will allow your app to automatically upload the information when the iPod Touch users gets home to their WiFi network.

That should most likely be at least once a day which may or may not be frequent enough for you. You could add a timestamp to when the initial upload was attempted and send that along the upload once it succeeds to get the correct order of events (data entries) on your server.

Iolenta

Hi David - Great idea, but isn't battery-efficient location notification coarse-grained to 500 meters, meaning it will wake up my iPod Touch before it gets into WiFi range? – Depolarize

Your iPod Touch doesn't have a GPS so it won't be able to get any position at all without being connected to a network. This should mean that the position updated when the iPod gets within WiFi range in which case your app should wake up. – Sisk

Actually, when I think about it I'm not sure if region monitoring is available for iPod Touch. I don't have one my self so I can't test if it is but if you have you could simple check [CLLocationManager regionMonitoringAvailable]; on an iPod Touch. – Sisk

Answer 2

There is no way to ensure this. If your application is "not running" (by the definition described in your question), it will not be capable of responding to a change in the device's network status. It should be setup to resume upload operations the next time the application runs again.

EDIT: Some of the cases you've described may indeed provide different opportunities for your application. Specifically, if the user "exits" the app by pressing the home button or launches another app in the foreground, your application may continue to run the in the background and could potentially respond to a change in network reachability.

The nature of what may be done in the background and for how-long is well documented, and supported by any version of iOS that supports multi-tasking. I recommend you review the documentation pertaining to App States and Background Services.

Blockhouse

my question listed a long list of "not running" cases. are you saying that none of those will support resuming uploads? On any iOS version? Or are you saying that only some of those cases won't resume uploads? – Depolarize

I've expanded the answer. Some cases do provide different abilities. – Blockhouse

Answer 3

• device was power cycled --> really NO WAY of resuming, unless you open the App!!!
• user has locked the device and it's sitting in his pocket --> apps applicationStatus is UIApplicationStateInactive but it is running in the background. You still are able to react to notifications and i.e. accelerometer events. Try the Reachability Class and Log the changes!
• app crashed --> NO WAY, unless opening the App
• user exited the app --> App is sitting in the background. There you have a maximum of 10 Minutes Restriction of fully using your App (like the App "Pastebot" does)
• user started using other apps so our app isn't running in the foreground anymore --> Same as user exited the app

On multitasking Apple says the following:

• Real multitasking only for certain kinds of usage, as there is Audio Background playing, VOIP (like Skype), navigation applications
• All the other apps can request a specific amount of time after the app is closed/in the background, to finish certain tasks (as sending an email, sms or uploading/downloading important data)

Important Quote from dev docs:

Your app delegate’s applicationDidEnterBackground: method has approximately 5 seconds to finish any tasks and return. In practice, this method should return as quickly as possible. If the method does not return before time runs out, your app is killed and purged from memory. If you still need more time to perform tasks, call the beginBackgroundTaskWithExpirationHandler: method to request background execution time and then start any long-running tasks in a secondary thread. Regardless of whether you start any background tasks, the applicationDidEnterBackground: method must still exit within 5 seconds.

Editorial

Answer 4

If you're building a restful API then I would recommend using RestKit, it has a request queue that checks the network status on the device and starts uploading once network access has been assured. You can read more about this here: http://mobile.tutsplus.com/tutorials/iphone/advanced-restkit-development_iphone-sdk/. Read the sections about Request Queue and background download/upload. It should be noted that RestKit is a big library which has it's advantages and disadvantages. I'm not completely sure how this que works with the app lifecycle, if it saves the request que even if the app is terminated. You would have to investigate that. RestKit does support background uploading/downloading, but as already noted, I think it's impossible to do any uploading if the app is terminated and not in background state.

I wouldn't recommend using RestKit if the API isn't Rest though.

You can download and experiment with RestKit here: https://github.com/RestKit/RestKit.

Enroot