How do I programmatically lock and unlock the main screen (i.e. the device itself) of an iPhone?
It's not possible. However, you can "prevent" your phone from locking when your app is running. [UIApplication sharedApplication].idleTimerDisabled = YES should do it.
It can be done by caling GSEventLockDevice (); from your app. This function can be found in GraphicsServices.framework.
This has already been resolved . You can find it on Github: https://github.com/neuroo/LockMeNow (work below IOS 7)
char*framework="/System/Library/PrivateFrameworks/GraphicsServices.framework/GraphicsServices";
void *handle= dlopen(framework, RTLD_NOW);
if (handle)
{
void (*GSEventLockDevice)() = dlsym(handle, "GSEventLockDevice");
if (GSEventLockDevice)
{
GSEventLockDevice();
NSLog(#"Phone is Locked");
//.........
}
dlclose(handle);
}
It is probably possible with undocumented Apple functions (maybe GSEventLockDevice() ?) but it certainly leads to automatic App Store REJECTION.
Apple simply don't want anyone to fiddle with core functionalities like this.
If you want to do this so, Apple never approve this, your app must be jailbreak. you can do this by calling Private framework on your project. you can use GraphicsServices.framework.
NOTE :
This GraphicsServices.framework is a private framework. Apple will never accept your app. By calling GSEventLockDevice() method you can lock or unlock your Device easily. This GSEventLockDevice() resides in the GSEvent.h.
I hope this one helps you.
Please let me know if you still facing any problem
I don't believe that there is a way to achieve this.
One thing that i believe is possible is to stop the IPhone from locking. you could then build a view that copied the lock unlock function and you would still have control over the phone.
it basically isn't possible because this probably is part of the private frameworks which can be used by Apple only. There are apps such as the fake caller apps that utilize a "fake" lockscreen but as you've pointed out, pressing the home button quits the app, rendering your lock screen useless.
Describe lock and unlock. I would try a switch that enabled = YES and enabled = NO for the view property. So basically you can disable all the UIGestureRecognizers and 'lock' the screen, if this is what you mean. I do it with UIbuttons once I add them as an IBOutlet as well as IBAction, so they are an object and can be modified at the property level. I am working on this very thing right now. I will post my findings.
Related
I'm developing an iPhone/iPad application through Phonegap, is there a way to implement a sort of "click here to quit app"? I mean quit for real, not "put it in the background and go to home screen".
Thanks in advance.
you can use following code to quite your app on click,
device.exitApp()
OR
navigator.app.exitApp()
Hope this may help you.
is there a way to implement a sort of "click here to quit app"?'
Yes, there is a way for really exiting the app and killing its process.
But never do that. Not only because Apple rejects your app if you do this. The problem with this is bad user experience. iOS is not a desktop operating system. You have a Home button for leaving apps (and again, there's a reason apps don't exit completely).
The window size is, conceptually, not spacious enough for maintaining an extraneous 44x44 pixel frame (44 pixel is the minimal size that can comfortably be touched, according to Apple's Human Interface Guidelines) dedicated only for exiting.
However, if you still want to exit after this lecture, there are several ways:
exit(0);
pthread_kill(pthread_self()); // on the main thread
[[UIApplication sharedApplication] terminateWithSuccess];
etc. Some of them may have a binding in PhoneGap (if not, it's easy enough to write one yourself).
You should not do that as this may considered as violation of iOS Human Interface Guidelines, lead rejection of your app.
Always Be Prepared to Stop
**Save the current state when stopping at the finest level of detail possible so that people don’t
lose their context when they start the app again.** For example, if your app displays scrolling data,
save the current scroll position. To learn more about efficient ways to preserve and restore your
app’s state, see “State Preservation and Restoration”.
Apple guidlines link :
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/UEBestPractices/UEBestPractices.html
in the application's plist put
UIApplicationExitsOnSuspend = TRUE
and when the user hits the home button, the application will quit. No need for a button, no need for exit().
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW23
I have a problem which describes here
app crashes after checking network reachability in iphone?
this problem occurs when app launches at first time, and not yet solved! next solution I found is to close the app if no internet connection found at the first time of launching and tell the user to reopen.
can I use exit(0) if the action sheet ok button pressed, someone says that we can use exit(0); if we have a reason to use that.. any other solution?
Check your code and try to solve crashing problem because Quitting your application programmatically is a violation of the iOS Human Interface Guidelines, which usually doesn't well for getting through the review process:
You can use this sample application for your requirement. Provided by APPLE.
In this they have kept it under Application Delegate to be available to all the classes.
The Idea is, you will have to check status of internet connection and if it is not available than you can add a blank view containing information like you are not connected to internet and also make userinteraction to false with your application rootviewcontroller. In this way you will notify user and he/she will not be able to act further.
Again in reversal of this when u are connected to internet you need to remove that view from rootviewcontroller and make userinteraction to true.
Sample image attached herewith.
Hope it helps.
http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html#//apple_ref/doc/uid/TP40006556-CH20-SW27
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
In iPhone OS 3.0, UIApplication allows you to set a applicationSupportsShakeToEdit flag. The documentation says "The default value is YES. Set the property to NO if you don’t want your application to display the Undo and Redo buttons when users shake the device."
This is all great and it ties in to the new NSUndoManager class nicely. However - I don't want to use the built in NSUndoManager in my app! I'm writing a drawing app, and I already have an undo/redo manager that does some fancy stuff (it manages the data required for each undo operation, and will page it to disk if the app is low on memory). I'd much rather just listen for a notification from the UIApplication and trigger undo myself. (I could just make a bogus NSUndoManager, but I also don't want the "Are you sure?" panel to show...)
Does anyone know if such a notification exists? I figure it must - but I can't find it documented anywhere. Is there a way to monitor all notifications going through the app, maybe?
Thanks!
You may well have solved this issue by now, but in case someone comes across this searching for a Shake solution as I did I laid out how you can get the 3.0 Shake event messsages easily in this thread:
How do I detect when someone shakes an iPhone?
It outlines how you can respond to shake without using an UndoManager or presenting the Undo API. Even if you set applicationSupportsShakeToEdit to NO, these events will still be received..
is it possible to change the iPhone background from code?
If you write a new png to /User/Library/LockBackground.png and then call notify_post(" com.apple.language.changed"); the device will respring and your new background will be present.
This isn't technically a private API, but does fall outside of what Apple allows on the store.
Nope, you can only save a picture for the user to set as a background.
Mel is correct, there's no way to skip over the save process.
The reason this will always be the case:
Apple doesn't want apps to be able to set the background immediately upon opening. Theoretically, they could have a permission box (like the location dialog), but I doubt that will happen anytime soon.