When I set my iPhone to sleep, switch to another app, etc., and then come back again, a prior visible MPMoviePlayerViewController (presented with presentMoviePlayerViewControllerAnimated:) is not there anymore. How can I maintain it, when my app loses the focus?
I found, that the "audio" background-mode has to be specified in the Info.plist-file to achieve the desired behavior. But interestingly my app got rejected after I added this, because it is not allowed when the app doesn't do actual background audio stuff. I think this is called a "dilemma". ;)
Related
In one of my apps when returning from background I get a non consistent behavior:
Sometimes I get the default.png and sometimes I get a snapshot of the last screen which the app was in.
In both cases it takes the UI a good second or two to respond again.
Therefore I would rather show the default.png rather then "unresponsive UI"
Is there a way to make the app display the default.png always until the app becomes active again?
Currently the "stupid" way to do it I thought about is by displaying some Modal view with the default.png and removing it on return to foreground.
Few Clarification:
I am doing this to avoid unresponsive UI.
I am using the default.png as it looks like loading and gives a better experience then unresponsive UI
The app has to run in background.
(And to whoever asked - no it is not closed when I sometimes return and see the default.png and not the last UI state - App loading from the start has a very different path and I'm sure of that)
Thanks in advance.
This is not a correct behavior and you may experiencing a bug. Basically as long as your app is in the background, when you launch it, you should not see the default.png, unless you remove it from background (double click on home button and delete that app).
For future people interested in this you can use the fact the last view in the app is used to be displayed when the app loads back.
You can display a VC as your moving to background which will represent some loading - hence achieving the desired behavior.
I've already seen a few other apps using the same behavior in cases operations are ran when coming back into the app.
Most probably, you are taking too long (performing too many calculations) in methods such as applicationWillEnterForeground:, applicationDidBecomeActive:, etc. As a simple test, try commenting out the code in these methods and see if the problem occurs again.
Simply set in your Info.plist the property "Application doesn't run in background" to YES. The app will never go in background and when the home button is pressed it will be simply terminated. So you're back to the pre-iOS4 behavior.
Note that when you see now the default image at start-up it is simply because your app has been terminated while it was in background. This is normal especially for apps that take a lot of memory and then don't free it enough before going in the background (I think the threshold for the OS is about 18MB but I'm not sure)
I've seen many news apps do this, where when you click on the app (on the iphone desktop) that has been in background mode, it starts again by showing a loading screen, etc. It basically looks like it starts again like it was never in background mode (I think what is called "refreshing the user interface). Does anybody know how you do this? I assume this is call from the app's delegate applicationWillEnterForeground or applicationDidBecomeActive method.
The application probably never went into the background. Try adding this to the Info.plist file.
UIApplicationExitsOnSuspend=YES
As a boolean value.
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 :-/
For the moment I don't want to care about multitasking. My app has a very long development trip behind it, and now it has been engineered that way that when the user hits the home button, the app gets killed. When he comes back, the app appears like he left it.
If I wanted to get this same behavior back, which methods would I have to implement in the app delegate? I assume that I would have to treat the case where my app becomes a background app just like if the home button was pressed, i.e. if applicationWillTerminate was called. That would be the simplest way, right?
You need to set a boolean flag in your Info.plist file called UIApplicationExitsOnSuspend to YES. When you do so, when the user hits the home button, -applicationWillTerminate will get called, as normal.
Set UIApplicationExitsOnSuspend to YES in your Info.plist. Your customers will hate your app for not supporting fast app switching, though.
Include the UIApplicationExitsOnSuspend key in your Info.plist. See this for more information.
Is it possible to override the default behavior (close app) of the Home Button? And if how do you do that?
well, there's a reasonable alt to the need to detect if the Home button was tapped. i'm currently working on just such a scenario.
my app allows user input (into UITextViews). a customer has asked for an "autosave" feature where, should they (accidentally) tap the Home button during data entry, could i still capture the data entered and save it.
my testing of the sequence of viewWillDisappear in the view that is collecting the data and applicationWillTerminate show viewWillDisappear getting called before applicationWillTerminate. now i fully appreciate that this is the architected sequence Apple intended, BUT this sequence also precludes setting a simple Boolean in applicationWillTerminate to let the particular viewWillDisappear know that it is disappearing specifically due to applicationWillTerminate.
so the issue still stands. how can a UIView detect that it is disappearing specifically as a result of the app terminating?
Even if it is possible, your app will probably not be approved by Apple.
Are you planning this feature for your own private App or do you want to distribute it later on?
The home button is probably the most critical button on the device on not a good idea to change