guys :)
I have an iOS alarm app, which uses UILocalNotification-s to schedule the user defined alarms if the app enters background. Since this (in my implementation) can be a relatively long process, I need to make sure that the registering of the notifications is completed before the app goes inactive. I read that there is a method in UIApplication: beginBackgroundTaskWithExpirationHandler, which asks iOS for more time, so that it can complete its tasks, but I have no idea how to use it. These (void(^)(void)) parameters scare me :). I know it's too much to ask, but... if I have a method [self registerLocalNotifications], which registeres all local notifications, can you please point me how to make sure the method finishes before the app goes to background. Huge thanks!
This looks like good sample code where you can see the usage of blocks ^{} together with applicationDidEnterBackground: http://iphonesdkdev.blogspot.com/2010/04/local-push-notification-sample-code-os.html
Related
I'm new to swift and programming so I'm not sure if or how this is possible, but could anyone tell me if I can designate code to be executed when the user terminates the app from the multitasking menu? I just have a line of code that I would like to execute at that time, but I'm not sure where to put it in my project.
Thanks!
If the user terminates the app from the multitasking menu, your app is killed dead. It is not terminated "in good order". You do not get an event at that time. It's just like the scene in 2001: A Space Odyssey where the scientists are already in suspended animation and HAL pulls the plug on them.
The art of Cocoa / iOS 8 programming is the art of the possible. Adjust your desires to fit the reality of the events you do get. You get an event when the user leaves your app, so if there is something you need to be sure to do, do it then, as you may never get another chance.
As matt said, when the app is terminated from the multitasking menu, none of your code is run, it's just killed.
Try putting your code into the application delegate's applicationWillResignActive(_:) method. This will run any time your app becomes inactive, though. In other words, more often (all the time) than being terminated in the multitasking menu. It'll run when there's an incoming phone call or text, I believe it will run if there is a notification with an alert, it will run when the user presses the home button.
My app has to run for a long time (also) in the background, due to Location Services.
When a certain condition is met the app has to move to the foreground.
I was able to run my app in the background and bring it to the front manually.
Reading up on this issue I got confused on how to move my app to the foreground by code.
It has to be in an if statement but what to do from here?
No do not think this is possible. You will be able to spawn a UILocalNotification to show application state to the user, but it is my understanding that iOS prevents you from making your app take focus.
you can't do that without user interaction. You can present a UILocalNotification
-- you can't even be sure iOS leaves it running though!
on a jailbroken phone I guess it is possible
This is clearly not possible, as it would be a mess if any app could just take over control at any point in time. As mentioned, you have to post a notification, and then it is up to the user if he or she wants to launch the app. If you notification states a good reason why they should launch your app, they might very well do it :-) And remember, don't mix up the user's needs with your/your app's needs.
Hee
Does anybody know how to recognize a multitask-kill.
When the user puts the application in background state and then kills the app through the menu in iOS 4.2 my application shuts down.
Before there used to be an function called:
- (void)applicationWillTerminate:(UIApplication *)application
This method is not called anymore in iOS 4 and higher.
Is there a way to recognize it?
Thanks already.
Actually that's not entirely true. It is called on iOS4 devices that do not support multi-tasking and the documentation says that it can be called on other handsets (though I've never seen it myself).
But to answer your question, no, you can't recognise when a user kills your app. If you have state that you want to save you need to do this when your app goes into the background and not when the app is killed.
If you look at the crash reports you'll see that iOS sends SIGKIL which you can't catch.
You cannot catch this, your processed really is killed. Hard. Without notice. That us why you need to save state when you enter background now.
Maybe setting up a signal handler might work (don't know which signal to catch, though).
I have an idea for a pretty unusual alarm clock fir the iPhone. But as of now I have some thoughts on how to actually implement this. First off: forgetting about background services for now, how would I do the actual timer that fires the alarm etc? A separate thread? Or does the SDK include any nice alarm features I missed? Of cause I need to be as battery efficient as possible. But for now I do no background process.
Please advise me on this as it is a crucial concept of this app, if it will work or not.
I would create a local notification. Compared to NSTimer, local notifications have the advantage that they work regardless of whether your app is running or not.
You must create a UILocalNotification object and schedule it with scheduleLocalNotification, it is quite simple but there are strong limitations. You app may or may not be notified that the alarm occurred. When the alarm is presented, it will be in form of a AlertView. If the user taps "Close" you do not get a notification. If he taps "View Details", then you get the event didReceiveLocalNotification, your app moves to the foreground and can do whatever you want.
You can also register with iOS4 to receive updates on location change. The parsing of XML can be done but again there are limitations as to how much time you have to run methods in the background.
All information along with sample code can be found here: http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html
In my iPhone app I would like to run several queries when the
application is in background.
I already use ASIHttpRequest to make the queries, that works fine but
now I try to find a way to trigger them in background.
In the app delegate, I have added a call to the method making the request:
[self getItemsFromServer]
getItemsFromServer runs an asynchronous request (on the simulator I
saw the log of this methods once I get back the application to the
foreground).
How can I use some kind of timer to have this method ran every 10
minutes (I just need to run it 4 or 5 times, not each 10 minutes until
it goes back to foreground :-) )?
thanks a lot,
Best Regards,
Luc
iOS4 allows your app to run for X amount of time, granted that iOS4 grants you the time you request. Check out: Completing a Long-Running Task in the Background.
Specifically,
Any time before it is suspended, an application can call the beginBackgroundTaskWithExpirationHandler: method to ask the system for extra time to complete some long-running task in the background. If the request is granted, and if the application goes into the background while the task is in progress, the system lets the application run for an additional amount of time instead of suspending it
You could probably use Task Finishing to do that. In iOS you can mark a thread as finishing and give it a specific time to live. This would let you do a few more calls to your web server.
Have a look at Executing Code in the Background
Actually, you are specially not allowed to make general HTTP calls while in background. The only apps that can be active in the background are those that play audio, do location or are running VOIP calls. I believe Apple's whole philosophy with background is that apps shouldn't be doing 'work' other than these limited cases because there are limited resources available. THe suggested way to work around this is to use (ugh) notifications or just do a refresh when your application wakes up. The doc that willcodejavaforfood references explains this.