I am working on an online radio and it works fine, but gets problem when user received a call. When call finishes I start the radio automatically, by using AVAudioSessionDelegate.
Now radio is playing and if user open the app (moving it to foreground) and press that stop/play button again my app goes crashes. I might know the reason, the reason may be due to threading. But I am unable to handle this (I can't put the code, it is huge and private).
To prevent crash when your app goes in background and comes in foreground, call the pause button of radio app in background and releases threads. when user touches the play button it it will start threading. Try it,hopes it may work for you.
Related
We have a multiplayer game and sometimes user quit the game so we would like to know how did user quit the game. Can we use didEnterBackground for that?
We would like to know whether user quit the game by clicking exit button, or by incoming call, or by home button to exit.
When you press home button your application is sent to background and applicationDidEnterBackground will get call first and if it is by call, sms then applicationWillResignActive will get call first.
This is not perfect answer of your question but this might help you in some.
in the appDelegate.m File u have this function:
- (void)applicationDidEnterBackground:(UIApplication *)application
write the code you want in it. (saving data or anything)
First of all, the user interface guidelines forbid quitting an app programmatically and based on what I have read, apps the provide an exit button will be rejected.
If by 'quit the game' you mean something along the lines of 'terminated gameplay', then that should not be a problem.
Also note that pressing the home button does not exit the app. It simply sends it to the background. There does not appear to be any facility to detect why the app left the foreground, which probably means that Apple wants your app to handle all such cases in the same way: by saving state and being prepared to restart where execution left off. Note that an application in the background can be terminated at any time, hence the need to save state.
The answer to your question therefore would seem to be: don't do that.
Sorry, I am new to iPhone development and my google searches have failed me, so I have had to resort to posting a potentially idiotic question on SO.
I would like to write an app that, when suspended, performs an action when the user presses the home or power button (presumably to unlock the phone). I read the section in the iOS App Programming Guide's App States and Multitasking and the "Processing Queued Notifications at Wakeup Time" discusses handling queued events upon waking up. However, this isn't what I'm after.
I'd like to know if it is possible to:
From the phone sleeping state (I couldn't find a document for phone states, so I am talking about the case where the user presses the power button to turn off the screen), I would like my app to be ready to respond to the event where the user presses the power or home button (to unlock the phone)
I would like my app to respond to the event that occurs when the user unlocks the phone. I found an answer here that's close.
I don't want any funkiness when calls come in, get ignored, etc. :)
From what I can tell, it's a very gray area in the API around locking and unlocking, and I'd like to verify whether or not I'm wasting my time trying to do this.
It looks like I can use the accelerometer to detect when the phone is locked, but I also assume that I won't be able to count on this behavior in all future versions of iOS.
EDIT - I think I can handle the locking and unlocking requirements by assuming that the application has to be running at the time the phone is locked and unlocked, but I still cannot figure out if it is possible to determine #1 above, which is that the power button has been pressed and the unlock screen is displayed. Likewise, I'd like to know if the power button has been pressed again and is no longer displayed (i.e. screen is off).
All of the behaviors for your app being suspended/backgrounded are in the document you referenced. The AppDelegate will receive these messages and pass them on to whatever view you want to listen for them.
-applicationWillTerminate
-applicationWillEnterBackground
-applicationDidBecomeActive
-applicationWillResignActive
You can set up a notification observer in your view if you would like the view to be notified of any of these events. Then just override them or set up a custom method to do any work that needs to be done.
While the Apple docs might be a little foggy at first, all the information is in there to let you know which state your app will go to and how it will be handled. It is up to you to figure out what your app needs to do for each of these events. Hope this helps.
I'm debugging an iOS app, and I need to call some cleanup code in some C++ classes (really, i just want their destructors to be called). When I run the app via XCode with the device attached, and then stop it by pressing the stop button, none of the app delegate methods are called (I'm looking specifically at applicationWillTerminate). However, if I pick up the device and press the home button, it successfully calls both applicationDidEnterBackground and applicationWillResignActive.
What am I doing wrong? I've tried removing all references to any C++ code, effectively making a blank iOS app, and I simply cannot get applicationWillTerminate to be called, or even dealloc in the root view controller. I've even tried using the signal() method along with SIGABRT, SIGKILL, etc., and that does nothing (plus, I can't call the Objective-C methods from a C method anyway). How can I react to the stop button being pressed?
You aren't doing anything wrong, the system just kills your app when you press on the stop button.
There are no methods called because the app is just killed, the same thing can happen when you app is backgrouded and the system needs more memory.
For more precision for the methods called when the app exits / enter in background, check this page
Like #rckoenes said, when you stop the app with the debugger, it kills it.
If your app has the background capability (UIApplicationExitsOnSuspend = NO, it's the default mode), when you quit your app, it is placed in the background instead terminated.
i try to retrieve Calendar events between two dates. After that I try to delete all events. this program is working fine. The Events deleting process will take few second/minute based on number of events.
When device goes to sleep this application will work in background as usual. After coming to normal state(wake up) my application will exit. But, i did over come this problem, disable idle time.
But this same problem repeating when i press sleep/wake up button on the top of iPhone. How to over come this problem. What happens in my application, when changing state, any memory problem or any other...
When the sleep/wake button is pressed, your application is sent to the background/changes mode to inactive. Check UIApplicationDelegate documentation applicationWillResignActive: and applicationDidEnterBackground:. When this happens there are restrictions about your application doing background operations, which are described within the documentation.
First some background; for the tl;dr version skip to "the problem" below.
Background
This is really more of a user interface question than a technical one, but I think it fits better here than on the UI site anyway.
Since iOS (iPhone OS) 4.0 apps can run in the background, and actually always does so instead of quitting. Quitting an application requires pressing the home button, pressing it again, holding your finger on the application icon until it starts shaking, touching the "close" indicator, pressing the home button again. Not really intuitive.
The reason for this is of course that usually the user shouldn't care if the app is quit or just suspended, because it doesn't matter. But for some apps it does.
The problem
I have an app that logs location changes; think "RunKeeper" if that's familiar. The user starts the app, chooses to start recording (to a file), or just uses it to view distance, speed, etc. When the user is done (or wants to do something else), they hit the home button. The app disappears. Now one of several things happen:
The app quits, closing any ongoing recording (iPhoneOS 3.1.3 and below).
The app continues running in the background, using the GPS and draining the battery (iOS 4). This is appropriate if the user for example wanted to switch to the iPod app to change their soundtrack.
The app continues running in the background, using the GPS and draining the battery (iOS 4). This is completely inappropriate if the user was done and wanted to quit the app.
There is of course no way for the app to see the difference between cases three and four. A quick look around RunKeeper forums indicates that many users have no clue what is happening and get seriously confused by this.
Ideas
So what's the best way to solve this from a user interface point of view?
When the home button is pressed, go into background as is the default action. It's the user's problem to actually kill the app if they are done. It's the platforms fault that this is non-obvious and slightly tedious.
When the home button is pressed and a recording is in progress, continue in background. If we are not recording, quit the application.
Present a toggle widget somewhere in the application that allows the user to choose what happens when the home button is pressed. (This might run afoul of the HIG; I'm not sure)
...?
What do you think?
I though to the third option without reading at it ^^ (I don't think it would be against HIG)
So a "big" button when recording to change the "mode" ? Or a switch ;-) (Like "Continue Recording when in "background" ?")
And maybe asking the user about it when he start registering ? (with a default value available in prefs page ?)
And as you can change songs without quitting the app, maybe setting the default value as stopping record when the app is going to background.
But I haven't any other solution for you :-/