I have an app which can currently communicate with an server.
Imagine the following case:
User hits some buttons which triggers an server request.
The request is send to the server and is processed.
The user hits the home button (and maybe removes the app from the
memory by hitting the home button two times).
The script is done processing and returns it result.
Question: Will the device from the user gets this response (I am pretty sure it will not when removing from memory, but what when just closing the app)?
There are 5 active states in iOS:
Not running: The app has not been launched or was running but was
terminated by the system.
Inactive: The app is running in the foreground, but not receiving
events. An iOS app can be placed into an inactive state, for
example, when a call or SMS message is received.
Active: The app is running in the foreground, and receiving
events.
Background: The app is running in the background, and executing
code.
Suspended: The app is in the background, but no code is being
executed.
On your third scenario where the user hits the home button, the app will be sent into the Background state, #4, and can still receive data and allow your script to run. If the user kills the app, (state #1) your script will not complete running.
So, to answer your question, yes your app will continue executing code if the user places it in the Background state, but not if they close the app because that will put your app in the Not Running state.
Application is suspended (on the background, not running) - In this case the execution of you requests get paused. When your app gets to the foreground, usually the requests end with a timeout.
Application is terminated - in this case the context of your application is lost and after restarting there are no running requests.
That's the 2 cases you should be concerned about. For me it a good solution to cancel all running requests when the application is entering background because it is easier to restart everything when the app gets to foreground again.
Also, you can setup background mode and that enables the app to perform some code when on the background but that's a more advanced topic.
Related
I am writing an app which will receive remote notifications sent from Firebase.
It works perfectly fine when I first install the app on an iPhone, the notification can be received no matter the app is in background or foreground.
However, when I killed the app and restarted it, then press home button again to send it to background, the app can no longer receive notifications in background state, and can only receive on foreground.
Please help. Thanks in advance!
WatchOS app works normally if being opened from home screen. If I try to open it from remote notification screen (by tapping title label) two app behaviors can be spotted:
If application was loaded previously (I don't know how to name it, maybe better to tell that app is not killed by system or still present in memory). In this case application will load normally and do some action if asked (for example open some Interface Controller and show remote notification details).
If application was launched long time ago (or killed by system, unloaded from memory, in my case I'm stopping it in Xcode). If app receives remote notification in this state after tapping on title label of notification scene it will try to load for some time and finally crash (this may take 1sec or 1min). Or it will stuck with loading indicator shown - what is interesting that in this case if I'll try to attach watch extension process to Xcode debug it will show that app is launched and works (for example I can send some data from parent iOS app and watchOS app will receive it - triggered method in Extension delegate and do some stuff).
Googling I have found that watch apps can be killed by system if they take to much power when being launched, so I tried to remove any load while app is starting itself but with no success - it still keeps crashing.
The only close to mine situation that I've found so far was a topic in apple developers forum:
https://forums.developer.apple.com/thread/20553
I have been spotting the same logs like in topic when watching how watch app behave in Xcode/Devices, but after updating to WatchOS 3 (now 3.1 beta) and using new Xcode 8 (now 8.1 beta) I can't see any logs from WatchOS at all (just some system messages that watch screen was turned of and on).
Have any one spotted such issues while working with watchOS remote notifications? Any suggestion where to search for solution?
I am deciding between using a login item and launch agent.
In this respect I have few questions:
Is it possible for a non root user to quit a login item helper if it is launched with service management framework using SMLoginItemSetEnabled? Will the helper app be reloaded by launchD if it is killed by user or in some cases OS?
Why does apple not recommend presenting a UI with an app that can be executed via a LaunchAgent? Is there a problem if we present a minimal UI?
A login item as a helper application requires the main application to call SMLoginItemSetEnabled. This implies that the main app must be called at least once to enable the login item. This differentiates it from a launch agent which can be loaded as soon as the plist is installed on the system. Can we execute the helper login item irrespective if the user has opened the main app or not?
Any help would be appreciable
LaunchAgents that are configured using SMJobBless are intended to be non-gui services. They run without UI in the background, and don't run as the logged in user.
If you want a gui, you're going to have to use SMLoginItemSetEnabled, or manually install a user LaunchAgent via a .plist with the "LimitLoadToSessionType" = "Aqua" property.
Helpers launched by SMLoginItemSetEnabled run as the current user, so they can be terminated by that user. The process will get relaunched if launchd detects that the agent went away because of a signal or due to an abnormal termination. If it terminates due to a clean termination it will not be restarted until the next login of the user (by clean termination we mean terminating with an exit code of 0, which will not happen if the program is killed e.g. via the activity monitor. If the helper has an option to quit, and that option causes it to exit with a 0 return code, then it will not be restarted, which would be considered good form by the application.
It's a stylistic thing - a user cannot disable the agent without interacting with the command line which would be considered poor standing. There is no issue displaying a UI from a LaunchAgent. As long as it's registered with the appropriate keys, it will be launched in the user's gui login context which means that it can be fully interactive. I have several applications which act like that - TunnelBlick, 1Password (this is via the LaunchAgent plist) and they only put up a menu bar item on startup.
If you're just shipping an application - e.g. via the app store, then there's no way to have anything automatically start without some interaction by the user - you have to launch the main app to get the helper to be enabled. The helper login item can be launched manually without ever launching the main application; but it won't have the 'launch at startup' magic enabled. If you can register a LaunchAgent plist, then you can get the launch at startup & starting it up immediately behaviour.
For uninstallation, however, LaunchAgents require the removal of the .plist, and interacting with launchd to disable it, items registered with the Service Mangement framework will naturally vanish once the app is dragged to the trash.
IMHO, (bit soapboxy, bit opinionated) If you're shipping a standard app with a helper, then rely on first launch before configuring such things as helper start on login; primarily because it keeps the user in control. Autoinstalling startup items is one of my pet peeves with windows applications (so many status bar items...).
The docs for SMLoginItemSetEnabled state the login item will be "kept running", which seems to indicate it will be relaunched if it is killed:
The Boolean enabled state of the helper application. This value is effective only for the currently logged in user. If true, the helper application will be started immediately (and upon subsequent logins) and kept running. If false, the helper application will no longer be kept running.
https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled
I'm trying to take users of My App to the AppStore for several different functions - like Upgrade to Full Version, Rate/Review or simply View another App I've developed. However, all of these are causing my App to Terminate when iTunes is launched on the device. I'm using some simple code and
have tried many combinations of URLs, all of which successfully get to where they are going. Here are the behaviors:
User clicks Rate App
Code directs them to the web via:
[[UIApplication sharedApplication] openURL:
[NSURL URLWithString:[[MyApp defaultApp] itunesLink]]];
My App goes to the background, and my delegate's applicationDidEnterBackground is called successfully
As iTunes is coming up, my App is terminated. Happens whether I run via X-Code or on the device directly.
When I quit out of the store and look at the running processes on the device, my App is still shown there. I know it has been terminated from X-Code console, and when I try to restart it it starts fresh.
I've tried the itunesLink as either itms://itunes.apple.com/app/ or with http - all of which get to the correct end point. If I use www.google.com it works fine and my App is NOT terminated, just sent to the background and the website is displayed OK.
Other points are that when I run via the simulator, the openURL call returns failure and doesn't open any URL.
Any insights as to why my App would be terminating? It's acting like an iOS security feature or something which is shutting my App down, but I thought what I was doing was pretty standard stuff.
If anyone has seen anything similar, I'd really appreciate advice on the situation.
Your app could be terminated for a number of reasons. The best thing is to look at the device console using Xcode's Organizer:
Your app may simply be terminated as a result of low memory notifications. As soon as it moves to the background and the app store launches (iTunes and the app store both use plenty of memory) it can be killed to free up memory. In this case you will set messages from "jetsam" like this:
<Notice>: jetsam: kernel termination snapshot being created
<Warning>: Application 'UIKitApplication:com.yourapp[0x6337]' exited abnormally with signal 9: Killed: 9
You should use the Activity Monitor in Instruments to see how much memory your application is using. iOS will terminate the most memory-intensive applications first, so you should try to reduce your app's memory footprint.
i want to show a alert when my app is running but phone is locked..we can say in power save mode. is there a way to show alertview without Push-Notification service when phone is idle and app is running.
If the application is locked, then your app is blocked. The only possibility (which I've never tried) might be to push a notification to the phone.