For iOS, I am aware that apps can upload in the background, as according to this thread:
Uploading in background thread in iOS
When I refer to "background", I mean the user has clicked the home button, using another app, or the phone's screen is off.
Follow-up Questions:
1.
Is there a timeout limit to the background uploading? This may be an issue if the file being uploaded is huge.
2.
Is it possible to upload a list of files in the background, or does it only support the finishing of one upload that was in progress before the user switched to another app?
3.
I suppose if the user quits the app completely, the upload will be stopped? Quitting completely as in, user double clicks home button, touches and holds down on the app until it starts shaking, then clicks the "X" to shut it down.
Answers:
1) The timeout limit is probably server - imposed, but you can certainly add some timeout detection code on the client (iOS) side.
2) Uploading a "list of files" is effectively the same as uploading a file. A list of files is just another file, effectively.
3) If the app is killed, yes, everything (and all the background threads) get killed along with it.
Related
My app has registered a document handler to open certain files from other apps using the "Open in" feature (for instance from Safari or Dropbox).
This works without problems until files are getting larger than ~300 MB. For files greater than this size the file is copied to my apps "Inbox" folder but the app is not brought to foreground but instead I just see the iPhone desktop and the calling app is sent to background. My app is not killed, it is just not brought to foreground. This happens in all situations, e.g. it does not matter if my app is already running or has to be started.
What could be the reason for this behavior?
Regards,
Is it possible you are getting a low memory notification and not handling it correctly?
I would look into your
-applicationDidReceiveMemoryWarning:
functions to see if perhaps you are running out of memory.
We are building an iPhone app and we are having a problem with downloading in-app purchases in the background and I was wondering if anyone had a solution …
Our in-app purchases are quite big 35-40mb, each purchase consisting of 5 items each 7-8mb so the phone typically goes into standby or the user switches apps before the purchase is downloaded so it is essential the in-app purchases are downloaded in the background seamlessly.
When we download the purchase we have to download about 35-40mb from the server and simultaneously update the local sqlite database in the app. We have tested downloading the items in the foreground and its working fine and we have done some handling to keep the download process continuing in the background and the download is continuing and we can see it working in the debugger.
However we have the following issue …
User starts download
Download page on app shows that the app is downloading
User leaves app or phone goes into standby
User returns to app
At this point the app splash screen loads and stays on the screen until one of the 8mb downloads has completed, when completed it then switches to the download page on the app. This is really confusing for the user as they think the app has crashed.
So how can we manage the in-app purchase so that when the user presses download it starts the download in the background and the app behaves as normal while the download is in progress? So user leaves app and when they return it shows the correct page with download progress. User navigates within app and it works fine.
Some observations ...
I have to run the NSURLConnection consecutively five times to perform downloading, because each in-app purchase has 5 items.
The thing I noticed is that when the first download is in progress the "didEnterBackground" method doesn't get called even if the user presses the home button but after the 1st download process is completed then "didEnterBackground" method does get called. And if the user puts the app into the background and then returns to the foreground the "didEnterForeground" should be called but it isn't.
I am downloading data using a different thread then "MainThread" ,but still running in same issue.
Any help would be much appreciated.
Have a look at AFNetworking it's used by many and loads on different thread. In the readme there's an file-download-with-progress example.
You can prevent iOS going into standby mode during download:
[UIApplication sharedApplication].idleTimerDisabled = YES;
Try to look at... a new AFNetworking'extension AFDownloadRequestOperation
This class has additional support to resume a partial download, uses a temporary directory and has a special block that helps with calculating the correct download progress, etc
"Don't forget to set shouldResume to YES" :)
For AFDownloadRequestOperation you can check also this AFNetworking not resuming download
UPD
in the worse case.. you can try "Task Completion for Long-Running Tasks" or "Task-Specific Background Processing" in background.. http://www.codeproject.com/Articles/124159/Hour-21-Building-Background-Aware-Applications
Is it possible to keep a socket connection alive in background, to be able to push new data and alert users at all times?
The answer to this question is a definitive yes. If you are in the background state, then you can keep a connection open and process messages from a server.
Unfortunately the complexity here is that you don't have a lot of control over the state your application is in:
foreground - The user has tapped your icon and the app is running with the UI visible.
suspended - The user was previously running your app in the foreground, but suspended it by hitting the home button or receiving a call. Basically your app is 'freeze dried' and will remain inactive until it is resumed by the user (starting where it left off) or it is terminated by the OS (see below).
background - The app was previously running in the foreground but has moved to the background state as a result of something the user has done. Normally your app will move to the suspended state in this case, but there are things you can do as the developer to prevent the instant 'freeze dry' and go into the background instead (see below). Your app will also be in the background state if it is woken up for a significant change event.
terminated - Your app has been unloaded from memory and the next time it starts will be from scratch. This is what happens when you double click the home button and then tap the x next to your app icon. It moves the app from the suspended state into the terminated state. This will also happen if the OS decides it needs room for more recently running apps and your app has been suspended for a long time.
So obviously the trick here is how do I stay in the background state as a long as possible. There are a couple of ways to do this:
Beg for more time - You can get up to 10 minutes of additional background processing when your app is closed if you ask for it.
Use UIBackgroundMode - You can declare youself a voip, audio or location app by adding the corresponding UIBackgroundMode value to the pList. There are special requirements for these types of apps which you can check out here.
So these approaches are not without their own problems (getting approved on the store being one of them) and as such I tend to agree with the other answers that using push notifications is probably your best approach for notifying your users. With the notification improvements in iOS5 this is going to be the best user experience going forward.
You can keep a socket connection alive (or do whatever else you want) in the background for about 15 minutes after your app closes. There are also more specialized background processing modes (specifically, audio, voip, and location) which Apple supports if your app fits into one of their supported categories. See here.
If you want to keep sending the user notifications indefinitely, you want to use the Apple Push Notification Service. This allows your app to continue to receive notifications when it's not running, and it conserves resources since there's only one connection to the APN service at a time.
You can definitely alert users with local and push notifications.
And as far as I know, you can keep a connection open only for limited time.
Look here for more details.
I have a problem with working in background mode ... I have an application for iPhone and it download some information from internet (for example RSS Feed) when my application enter to the background it stops download. When I call from background function that open connection and begin to download it stops, like something happens with my internet connection like it closed. Con somebody answer me can I continue downloading or starts a new one in background mode or I can't. I read This but I can't understand if I can do work except
* audio - The application plays audible content to the user while in the background.
* location - The application keeps users informed of their location, even while running in the background.
* voip - The application provides the ability for the user to make phone calls using an Internet connection.
in background mode.
Thank you for answer ...
First of all, that Apple document you mentioned has exactly what you need.
Second, read this post, Download data in background with iOS4
Third, to make things clear, what you need is not audio/location/voip, what you need is the Completing a Finite Length Task in the Background section, which was discussed and was presented with a short code sample in that Apple document.
I need to save a big file, sometime it takes a very long time to finish, user might just close the application. I am wondering whether the iPhone SDK could take over the unfinished big task.
Appears iPhone's own mail system could do background send. I prepared a email, click send, then close the mail app immediately. In home page, after several seconds, I heard a sound and the email was delivered.
You're out of luck. Only Apple's own apps are allowed to operate in the background. But I think your app gets some time to finish up when the user closes the app.
You can't run the app in the background as PEZ says. However you could spin off a thread to perform the task and then at least the user can get on with doing other things in your application.
If I remember correctly, your app gets 5 seconds between the user pressing the home button and the iPhone OS killing it if you're not done.