After iOS 3.2, Apple allowed us to keep running our application in background mode. Using the same concept, in my application I have downloading functionality implemented which runs over in background mode.
The problem is that whenever I force quit my app manually, (Double tap on home button > long tap on app icon > tap on cross button of app) as per Apple specifications. I am not able to track that event in code, hence I am unable to track my downloading data.
Because of that, my data is being lost. So how to track this and track/save data before it gets force quitted.
Reference: AppDelegate Protocol
As far as I know, there is no way to handle that event, since it kills the whole process immediately.
You will need to save your data periodically or just leave it like it is. User killing apps, should be aware of that he is killing apps.
track each 'chunk of data' as you receive it and you write it to disk. that way you don't have to rely on a shutdown event
Thats how ASI and AFN do it and thats how you could also manually do it using NSURLConnection directly.
On startup, see if and how much of the data you already have in the file. Again ASI and AFN make this really easy!
Related
When I restart the device my app is on it won't preserve the state it had once I open up the app again, it will be as if it's the first time I open, losing the session and having to re-login, how can I make my app preserve its state even through a device reboot? Like Twitter does, for example.
I'll try a bit more formal answer based on the comments you added above. I'll start by saying that the link Tim posted is something you should familiarize yourself with.
When your app is running, it's in the Foreground state. When you "exit" an app with the Home button, you're not really quitting it; you're just pushing it to the Background state. after a few seconds in background state, the OS automatically moves the app to the Suspended state. If you come back within a few minutes, your app is still in memory, so the OS just puts it back on the screen the way it was.
However, if you leave the app alone for a while and use other apps, the OS can--at any time and without warning--purge your app from memory. This is known as the "Not Running" state. Now, when the open the app again, it has to start from scratch. Obviously, the same thing happens when the device restarts--all apps are purged from memory.
The trick, then, is to save essential information about the app state whenever it enters the background state. You can use the app delegate's didEnterBackground method, or register for the UIApplicationDidEnterBackgroundNotification and invoke a method in your active view controller (or any other class, for that matter). Either way, you should save whatever state information you can.
How do you save this information? There are several strategies. For a simple app, perhaps you can register a few setting as NSUserDefaults. Or maybe you can write out a file containing whatever data the user was working on. It's really up to you.
Then, whenever the app launches, check for the presence of that saved data (however you chose to write it out), and set up the UI accordingly. To the user, it will appear as though the app never quit, which is exactly what Apple wants them to think.
I want to update some data to my application. Consider the application is in the background state, it is neither Voip or Music or GPS. Is it possible to update/send data to the application which is in background?
NOTE: I dont want to notify the user so that the application becomes active.
Can anyone help me ??
The answer is yes and no.
Apple does allow you app to complete a lengthy process in the background. But if you does not fall in the Voip, music or GPS category then you can't run in background.
If for example you want to send some data to a server, which could take some time, then you can mark that process to back executed until it is finished (or 10min. have passed).
You will find some about Executing a Finite-Length Task in the Background
There is not way to run timers or any thing like that in the backgroud, you can only finish a task you started before the app is backgrounded.
The alert which is displayed is an inbuilt functionality. You can't do anything for that. If a notification is fired from the server and application is in background then the alert will be displayed.
I have done a lot of search in past for this stuff.
I have done this in one of my work. this is what i did.
when application enter : - (void)applicationDidEnterBackground:(UIApplication *)application
I send data to server using ASIHTTPRequest with property :
[request setShouldContinueWhenAppEntersBackground:YES];
But after finished, i didn't do anymore connection or data manipulation. So, only the connection is running at background and not your app. you can't do much after the connection finish.
As #rckoenes was mentioned, you may not execute task too long.
If you would like to update server data while your app is running in the background mode, the application should be active at that time. It can only be active if it uses "music, or voip, or location tracking", otherwise the app will be paused in background mode.
One way to avoid this is to develop your application, and to set it to use, for example, «location tracking». This will allow it to meet the requirements for active background process and you will be able to update server data.
Unfortunately, I do not know whether the app can pass app store approval with this set-up.
However, if you are interested in this solution, you can find an example here.
I am running my iPod touch application and then go in background and change the device language from Settings application and try to bring that application on foreground. My application gets restarted and I do not land on the screen where I left the application when I went into the background.
Is this because a KILL signal is sent by settings application when language was changed? Is it the desired behavior?
I wasn't aware the switching the language would cause apps to be terminated, but that's not shocking. It's a very straightforward way to get what the user wants. Your problem isn't the language change, though. The problem is that you're not responding correctly to a notification of termination. You can be terminated at any time when you're in the background, and it's your job to deal with it.
Your application delegate should implement applicationWillTerminate: (or you can observe UIApplicationWillTerminateNotification wherever it is convenient). When you receive this, you should save off sufficient information to get yourself back to where you were when you restart. As much as possible, you should make it look to the user that you did not terminate. The easiest place to save state is usually in NSUserDefaults, but you can use any mechanism you like.
Handling application restart is one of those things that separates excellent iOS applications from "good enough."
I'm creating an app which connects to server and sends some text.
If network (both wifi or 3g) is there, it will immediately send the text to server.
But if there is no network, it keeps on polling for server connection every 5 minutes.
All this part is working fine.
But when using iPhone 4 device, i want the app to check for server connection even when app goes into background. So, when app goes to background and when network comes back, it must be able to send the text to server.
How can I achieve it? I've seen some apps where they say that the app will upload photos to server even in background. How will they do it?
I suggest you read this article from Apple carefully, especially the Completing a Finite Length Task in the Background section.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html
Something to clarify:
Once your app is in the background and is frozen by the OS, there would be no way for your app by it self to wake up and re-connect to the internet.
However, according to the article above from Apple, you can call this beginBackgroundTaskWithExpirationHandler method from your app's delegate to apply for additional time when put in the background, which is to say, though your app cannot wake up by it self when in background, it can, when in the background and not frozen, try to apply for additional time to finish its lengthy task.
Hope it helps.
There is a trick that I think flayvr is using.
If you download and use the app, you will see that they require you to enable your location.
And why is that?
because they want like you to do something in the background even when the app is terminated (they creating an album out of your newly captured photos), and how do they do that?
They use the significant location change, where when someone is traveling some significant distance (something like 500m) each app that registered for significant location change will get awaken for a limited amount of time to perform some quick task and will be terminated in a few seconds.
So your app can register to that event also and when the event of significant location change fired you will be able to send the text to server (quickly).
Hope that helps.
Until now you can do that on iOS7 with Background Fetch.
Take a look at this article.
However you only have up to 30s to get the task done.
According to the article above, there's also another solution called Background transfer service.
If more time is required though, then the Background Transfer Service
API can be used
Create a new project in Xcode and you will see there are bunch of new methods auto generated in app delegate file. like applicationDidEnterBackground, applicationWillEnterForeground etc.
read the description you have to call your thread to upload data on server here.
What is a good way to handle iOS 4 app termination when using an NSUndoManager?
I have an iPhone (iOS 4) application that uses Core Data. The app allows the user to edit managed objects, and I implement undo using NSUndoManager in a straightforward manner: Before displaying an editor view modally, I create a new NSUndoManager for the managed object context. I also begin undo grouping so that any changes can easily be undone if the user taps the "Cancel" button. If the user taps "Save," I simply remove the undo manager and the changes become permanent. So far, so good.
If the user presses the Home button (or takes a call) in the midst of editing an object, the app gets suspended. It sends the app delegate an applicationDidEnterBackground message and I use that opportunity to save the managed object context. The context, of course, contains the new edits, just waiting to be undone by the NSUndoManager.
Here's the issue: If the app is later "unsuspended," the NSUndoManager still exists and everything works fine. However, if the app gets "killed in its sleep" by the OS, the undo stack is lost and the changes made to the object now become permanent. At relaunch I want to restore the app to the exact same state it was in before it was suspended, but that seems to require me to save and restore the undo stack. Unfortunately, I couldn't find an obvious way to do that.
Is there a good way to support undo so that it works consistently whether or not an app is terminated? I hope I'm missing something obvious. Any help or suggestions would be appreciated.
You can spend all the time in the world serializing your current app state to disk so you can relaunch where you left off...
... or you can sidestep the issue by reducing your memory footprint so you're less likely to be killed while in the background. I suspect the backgrounded-due-to-phonecall app is given priority over other background apps, if only because it is more recently used.
Low memory, updating the app, or tapping the box in the task switcher can all kill your app. It's up to you to decide whether you need to preserve the exact state the app was in. I think Android only preserves the serialized app state for about 30 minutes, because short-term memories don't tend to last much longer.
(What? .foo.txt.swp exists? It's several months old! How am I supposed to know where it's from? Why can't you just show me the changes between that and foo.txt so I can decide whether I want to keep it?)