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
Related
I just have a simple question regarding the button on the upper right corner of the iPhone (power button). Is there anyway you can receive notification from it when it´s being pushed?
Thank you
The –applicationWillResignActive: and -applicationDidBecomeActive: application delegate methods are the closest you can get, although they can be triggered for other events such as an incoming call. What exactly are you trying to achieve here?
You can not directly access the hold button, that is reserved to Apple and must always behave the same independent of app. Because of this you are not allowed to use it to do other things.
However, as Mike had said, you can get information about when the app is going to go to sleep or become active, which can be triggered by pressing the hold button
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 really don't think this can be done, but still my boss wants me to provide a link where it says so. What he wants is to add an 'are you sure you want to exit?' warning when the user presses the home button, and if the user says 'no' the app won't go inactive.
It can't be done, can it?
No, you cannot do this - the application has no say in this. Ask your boss whether he has ever seen a single example of an iOS application that would do this. There isn't ... not one I would bet.
The application can continue to execute some functionality in the background - streaming music, getting location information for example, but no application can block the home button. If you could do this, you could block an application from ever closing.
A) You couldn't technically do this and
B) Apple wouldn't allow it to be released on the App Store if that was the distribution route you were taking
If you look at the methods stubs created by XCode when you create an application delegate
-(void)applicationWillResignActive:(UIApplication *)application
-(void)applicationWillTerminate:(UIApplication *)application
That are filled will comments about how you can use this method to pause tasks, disable timers, throttle down frame rates, save data - there is nothing about being able to delay, query the user with an "Are you sure" message.
This whole idea is rather counter to the user-experience of the iPhone/Pad/Pod-Touch.
From the App Store guidelines (slightly abbreviated):
Apps that alter the behavior of switches on the device will be
rejected
This is a proposed change the behavior of the home button - so would be rejected.
This is possible on a jail broken device, using un-aproved API's. The concept is in multiple violations of apple's usage policy however so you would never, ever, ever get an app attempting to implement this in any way on the official app store. Here's just a few reasons:
You can't alter the functionality of any buttons (including the volume buttons, some camera apps used to use them to take pictures, but they got booted from the store as a result).
You can't interfere with standard user interactions with the device. The home button takes people home, you can't prevent that, or ask for confirmation as that would be interfering with the interaction.
There is no public API to detect actual usage of the home button. As such you would need a private API, and you can not use private API's without explicit permission from Apple, which they would never give due to #1 and #2 above.
I'm sure there's plenty of more reasons, but regardless it would be in direct violation of app store policies as well as iOS human interface guidelines.
You can detect when the app is about to lose focus, has lost focus, or could loose focus (such as a phone call is coming in) but you can not alter the flow (i.e. not allow the app to lose focus).
You can continue to execute code in the background within the backgrounding guidelines and limitations. The backgrounded code could submit a notification to the user that would allow them to switch back into the app... that's about as close as you could get, and expect apple to reject you if it happens every time the app closes...
Already answered by numerous others, but no, you can't do this. When the user presses the home button, your application delegate's applicationWillResignActive is called which disables touch events to the application. Then applicationDidEnterBackground is called, which, per the Apple docs:
Your delegate’s applicationDidEnterBackground: method has
approximately 5 seconds to finish any tasks and return. In practice,
this method should return as quickly as possible. If the method does
not return before time runs out, your application is killed and purged
from memory
You need proof to show your boss that obviously isn't an iOS developer.
Apple Human Interface Guide
That should be all the proof you need. But to be clear, Apple will not allow an app to override the home button in any way. You can surely put action sheets or pop ups to warn before logging out, but once the home button is pressed, you are on notice to give up your memory, you are being shut down.
You might want to look into the Store Demo Mode of IOS. This way you can disbale the Home button and lock the device in the first app you start after booting.
I know I'm too late to answer this question.
But I recently came with the issue which Samssonart had.
The answer given by #iandotkelly is deprecated with iOS5. Now none of delegate method will be used to distinguish between locking the device or sending app to background using Home button.
you can now use applicationState variable to define what action is triggered.
applicationState is an inbuilt id provided by appDelegate.
**
if it returns 2 then, it will identify the Home button is pressed
if it returns 1 then, it will identify the lock hardware button is pressed
**
So, in your case you can check out this condition in **applicationDidEnterBackground** method
- (void)applicationDidEnterBackground:(UIApplication *)application
{
NSLog(#"decision >> %d",[[UIApplication sharedApplication] applicationState]);
}
Enjoy Programming!
The best reference I can find is this one. It's not quite explicit, but Apple's Human Interface Guidelines have a couple of headings 'Always Be Prepared to Stop', followed by 'Don't Quite Programmatically', which spell out what the home button does and that you shouldn't be implementing your own quitting strategies.
I know this is an old topic, but I just want to update this answer. In iOS 7 this is not working.
So I use screenbrightness when the app will go to the background to identify difference between the Home and Lock button.
-(void)applicationDidEnterBackground:(UIApplication *)application {
if ([[UIApplication sharedApplication] applicationState] == UIApplicationStateInactive) {
NSLog(#"Sleep button pressed");
} else if ([[UIApplication sharedApplication] applicationState] == UIApplicationStateBackground) {
if ([[UIScreen mainScreen] brightness] > 0.0)
NSLog(#"Home button pressed");
else
NSLog(#"Sleep button pressed");
}
}
I hope this is gonna be of any help for in future for anyone
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 :-/
My application brings up a different view each time it is built in Xcode. This is exactly what I want it to do. However, if I simply press the back to menu button in the simulator and then reopen it the view does not change. I am changing the view by overwriting the viewDidLoad function in a Custom View Controller. Why is it that ViewDidLoad is not called every time I click on the icon? Will that mean that on a real iphone it also will not be?
Thanks,
Sam
When you press the menu button in the simulator (or the actual iPhone) the OS, basically, stops running your app. However, it doesn't necessarily terminate the app; if you reopen the app before the OS has decided to terminate it, you will find yourself in the same state you were before. Since the app isn't reloaded, viewDidLoad isn't called.
However, viewWillAppear should still be called each time, I believe, and this might be a better place to put your code that changes how things look. Edit: A quick test shows that this isn't the case. I'll poke around and see if I can find another notification mechanism.