I can see nothing in google's documentation to indicate how to prevent a user from closing a chrome app. Has anyone come up with a way to accomplish this? I think there is clue in the documentation about the onSuspend event. It says - After receiving onSuspend no further events will be delivered to the app, unless the suspension is aborted for some reason.
How can the suspension be aborted?
Some events can trigger an onSuspendCancel. I found that making a new XMLHttpRequest to any URL will do the trick. You could also call chrome.runtime.reload and make the app start anew.
In general there should be no need to prevent the background page from suspending, because it can be woken up with either a persistent listening socket, or runtime message, or google cloud message, etc.
If you just want to prevent the user from closing an app window, there is no way to do this, apart from implementing your own custom app window frame and intercepting for example control-w. You need to just save your work or app state outside the window context (should not be too hard to do this) so that you can still have it even when the window is closed unexpectedly.
Related
After iOS 3.2, Apple allowed us to keep running our application in background mode. Using the same concept, in my application I have downloading functionality implemented which runs over in background mode.
The problem is that whenever I force quit my app manually, (Double tap on home button > long tap on app icon > tap on cross button of app) as per Apple specifications. I am not able to track that event in code, hence I am unable to track my downloading data.
Because of that, my data is being lost. So how to track this and track/save data before it gets force quitted.
Reference: AppDelegate Protocol
As far as I know, there is no way to handle that event, since it kills the whole process immediately.
You will need to save your data periodically or just leave it like it is. User killing apps, should be aware of that he is killing apps.
track each 'chunk of data' as you receive it and you write it to disk. that way you don't have to rely on a shutdown event
Thats how ASI and AFN do it and thats how you could also manually do it using NSURLConnection directly.
On startup, see if and how much of the data you already have in the file. Again ASI and AFN make this really easy!
My App relay heavily on server data, when i have no connection to my server i cant present any data. so i present to the user a screen explaining him the no connection situation and give him a button to exit the application
my question is: will it pass Appstore tests? i never tried it before and i know they dont like apps to use exit(0), i was also was suggested to put a screen with no buttons and block the user from going back to other app screens and put a message on this screen and make the user to click on the home button in order not to use exit(0)
is that allowed?
No, you must not call exit. Your app will be rejected. This has been repeatedly discouraged by Apple and is known to cause serious bugs with iOS multitask switching. You should simply leave the user to use the home button themselves.
Do not call the exit function. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen.
http://developer.apple.com/library/ios/#qa/qa1561/_index.html
So here is the issue I am facing. Certain portions of the application I am building open some c network sockets that allow connections to various servers/services. However, if the application goes to sleep, these socket connections are lost, and error out when trying to reload them. So what I want to do is basically notify the user when the app launches again, that the application needs to be restarted. The main question is, can I present them with a button that will kill the app by using exit(0) without my app getting rejected?
Apple says that the user should be in control of when the app is killed, and in this case I see that they are, but I am not sure of Apple's opinion on this. Has anyone else used this? Have you been rejected for this? Thanks in advance for any advice!
EDIT:
Thank you everyone for your advice. I am trying to take everything into consideration, but because the app needs to be submitted ASAP, I just need to know, if we can not get another solution, if the above proposed solution, will get rejected or not.
Your application delegate receives notifications when significant events affect the life of the application. Rather than ask your user to recreate a session, you should attempt to discontinue network operations and then resume them at the appropriate times in the application's lifecycle automatically.
You can gracefully kill network sockets (amongst other things) in any number of places as the application prepares to exit or enter the background via callbacks in your application delegate:
applicationWillResignActive:
applicationWillEnterBackground:
applicationWillTerminate:
Potentially reconstruct sockets in:
applicationDidBecomeActive
applicationWillEnterForeground
Have you tried not allowing the app to run in the background? Then it will be killed whenever the user exits to the home screen. This might be a bit aggressive, but would solve the problem. From Apple's opting out of background execution:
"If you do not want your application to remain in the background when
it is quit, you can explicitly opt out of the background execution
model by adding the UIApplicationExitsOnSuspend key to your
application’s Info.plist file and setting its value to YES.
When an application opts out, it cycles between the not running,
inactive, and active states and never enters the background or
suspended states.
When the user taps the Home button to quit the application, the
applicationWillTerminate: method of the application delegate is called
and the application has approximately five seconds to clean up and
exit before it is terminated and moved back to the not running state."
See also: How to prevent my app from running in the background on the iPhone
The documentation is pretty explicit about this, "There is no API provided for gracefully terminating an iOS application." See Technical Q&A QA1561
How do I programmatically quit my iOS application?.
To be blunt, terminating an app to cleanup a socket is just like dealing with memory management by forcing an app to exit instead of calling release.
What about bringing up a modal view controller telling the user to quit the application? You could make this view controller without any dismiss button, so the user is obligated to kill the app.
I'm using the AsyncUDPSocket third party library in my iPhone app and for the most part it works great. I have a singleton instance of an AsyncUDPSocket that I use for all my network traffic. My app is registered for location tracking in the background and will wake up and send location update packet(s) over the network while running in the background. This all works smashingly running in the background, foreground, phone locked or unlocked, except when I do the following:
Start my app
Disable location tracking in my app settings
(so no background waking up)
Press the home button (app goes into background, socket is "freeze-dried" with rest of app)
Lock phone
Unlock phone
Resume app
Attempt to restart tracking and send something out the socket. As soon as I try, I get a SIGPIPE/EPIPE error and the app crashes.
I figured the best way to deal with this would be to close and release the socket whenever the application exits and background tracking is not enabled, but when I try [socket close] or [socket release] on the AsyncUDPSocket, I get various EXC_BAD_ACCESS errors. I've filed a bug with the dev team, but was wondering if anyone here could give some ideas on how to either avoid the SIGPIPE error entirely or other ways to keep the socket alive without releasing it. Thanks.
Great observation - yes, seems that after you send task to background and then lock the phone, sockets get dropped and next time you try to use it one gets bludgeoned with a SIGPIPE.
Ideas on how to deal with it here:
SIGPIPE crash when switching background task
(it's either set ignore for SIGPIPE for the whole app, or for the socket, or provide hanler for it)
ps. also - seems that setting to ignore SIGPIPE does not work with attached debugger, so compare with and w/o.
Just in case anyone's curious (which, judging by this question's stats, they're not), I was not able to determine what was causing the SIGPIPE error, but did eventually sort out my memory management issues (which were due to a faulty implementation of onUdpSocketDidClose in my delegate) so that I am able to reinitialize the socket each time the app restarts.
I would like to close an iPad application as a result of clicking on a UIButton. However, I have not seen how to do this in the Apple documentation.
What call needs to be made to close an app?
Thanks.
You can call exit(0) to terminate the app. But Apple don't like this as this gives the user a feeling of sudden crash. If you still want to have an exit function (with a potential risk of rejection) then you should also send your app delegate the applicationWillTerminate message (if you have anything important there) before performing the exit.
It says:
Don’t Quit Programmatically
Never quit an iOS app programmatically because people tend to
interpret this as a crash. However, if external circumstances prevent
your app from functioning as intended, you need to tell your users
about the situation and explain what they can do about it. Depending
on how severe the app malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures users that
there’s nothing wrong with your app. It puts users in control, letting
them decide whether they want to take corrective action and continue
using your app or press the Home button and open a different app
If only some of your app's features are unavailable, display either a
screen or an alert when people use the feature. Display the alert only
when people try to access the feature that isn’t functioning.
The only way for a user to exit an application is by pressing the Home button. You can't do it in your app, at least not in a way that Apple would accept.
You can try to use command:
exit(0);