I have a Cordova app that records user's trips. It works fine in the background, and I'd like to get it automatically restarted if it's killed for some reason (user swipes it away, phone restarts, etc.).
I'm monitoring a region, and the app partially restarts when the user enters/exits from that. 'Partially' here means the app only runs in the background - Cordova loads my app's plugins, but it never loads the WebView.
For this partial restart, I'm listening for UIApplicationDidFinishLaunchingNotification with UIApplicationLaunchOptionsLocationKey from my plugin's pluginInitialize method and starting location services right away to stay running.
Why doesn't the WebView load? Is there something I need to do to trigger the next stage of initialization when started by iOS?
EDIT 2016/3/7
I did some research and debugging. Apparently, iOS starts my app in the background; here's what I get when auto-started this way vs. a manual start, from the logging line:
NSLog(#"Launched in: bg:%d active:%d inactive:%d", state == UIApplicationStateBackground, state == UIApplicationStateActive, state == UIApplicationStateInactive);
Launched in: bg:1 active:0 inactive:0
Launched in: bg:0 active:0 inactive:1
I verified this code was being reached in both cases (from cordova-ios' v.3.9.2 (Cordova v.5.4.1) CDVViewController:
NSURLRequest* appReq = [NSURLRequest requestWithURL:appURL cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:20.0];
[self.webView loadRequest:appReq];
I see this load finish in the manual case, but not the auto-start case, with the log line:
Finished load of: file:///var/mobile/Containers/Bundle/Application/[device id]/[app name].app/www/index.html
Why would this load fail when auto-started?
I ended up using an Apple support ticket; their answer is basically "you can't load a web view when started that way":
If I understand correctly, you are expecting your app to visibly launch to the foreground when you get a location update.
that is not how it works at all. Your app will be launched into the background. If you see the UIApplicationLaunchOptionsLocationKey, only your app delegate and the location manager’s delegate class will be initialized. No views will be initialized whatsoever.
Once an app is launched in the background, it is expected to process the data for a few seconds silently and then yield back to the system. It is not possible to load a web view, or any kind of UI at this stage.
The only user interaction that would be possible is to schedule a local notification with a message to the user to launch the app. If the user taps the notification, your app will be fully launched.
Only then you can load your web view.
Related
I am trying to run some code during the applicationWillResignActive when the user opens the task switcher and it has worked fine until I began using bluetooth in my app.
When bluetooth tries to connect to a device it shows an alert window asking if the user wants to pair the device. This alert is enough to trigger the applicationWillResignActive method and then runs my code for when the app is being navigated away from (task switcher). This causes a large problem since the code I intend to run when switching away, turns off some much needed functionality within the actual app. So once they press "pair" or "cancel" on that alert, all of my app stops functioning as it should because the app has lost focus.
I have tried to detect the state of the application during this time with this... NSUInteger state = [[UIApplication sharedApplication] applicationState]; thinking of course that it would be considered active when the alert pops up and inactive when in the task switcher. However, this was not the case it shows up as active for both use cases.
Update #1
The question...
How can I differentiate in the application between the app causing a system level inactive focus state like running code to connect to bluetooth, versus the user causing the system level inactive focus like double tapping the home button? All in the efforts to distinguish what is causing the applicationWillResignActive method to fire.
Update #2
The intention of this functionality is to set a flag in NSUserDefaults when bluetooth connects to the device. This flag is being "observed" and used to trigger the changing of view controllers to a page related to this new BT connection. When the user double presses the home button and moves to task switcher I turn off BT and switch to iBeacon so I can notify of events. All is well with this current implementation all bar 1 use case.
If the user hasn't yet connected to the BT device and it connects for the first time and that pairing alert comes up it fires the applicationWillResignActive method just the same as double tapping the home button does. In this method the code then checks for that NSUserDefaults flag to see if it switched on (which by this time it is because the BT has already reached the CBCentralManager's didConnectPeripheral method and turned it on) and if it's on, it turns off BT and switched to scanning for iBeacon. Because the app is still open this obviously causes problems. The app is running so the user see's the BT connect, the new view slide in, the pairing alert come up, then the new view slide right back out and iBeacon starts sending notifications intended for when the user is in the task switcher.
I already have this exact functionality happening in the applicationWillEnterBackground method so that's not the answer. I need to have a way of saying "the app is running right now and we've received an alert instead of double tapping home, so please don't turn off BT and turn on iBeacon yet"
Two possible solutions:
1. The answer may lie in this statement:
When bluetooth tries to connect to a device it shows an alert window asking if the user wants to pair the device.
Your app must do something to cause this alert to appear. You could set a Date field to the current time in your AppDelegate when this happens, and then when you get a call to applicationWillResignActive you can compare that timestamp to the current time, and if it is < 1 second or so, you have a pretty good clue that the bluetooth dialog went up.
Of course, this is not foolproof. As #danh notes in his comment, the design of iOS makes this really difficult. You won't know for sure if the bluetooth dialog went up, or if the user or OS just happened to bring something else to the foreground at the same time. What's more, it's always possible that even if the bluetooth dialog comes up, the user might decide at that very moment to go check his or her email or start browsing Facebook. In that case, it is both true that the bluetooth dialog is what sent your app to the background, AND the user navigated away from the app. Unfortunately, iOS doesn't really give you a way to differentiate the two.
2. You might use a background task to handle your cleanup logic.
You can request up to 180 seconds of background running time after the call to applicationWillResignActive, so you could defer your cleanup tasks until say 175 seconds have passed since your app is resigned to the background. If the user doesn't come back within 3 minutes, it's probably time to do this cleanup anyway. My blog post here shows the basics of setting up a background task. It is specifically targeted to extending beacon ranging time, but you can put whatever logic you want inside the background code block like this:
- (void)extendBackgroundRunningTime {
if (_backgroundTask != UIBackgroundTaskInvalid) {
// if we are in here, that means the background task is already running.
// don't restart it.
return;
}
NSLog(#"Attempting to extend background running time");
__block Boolean self_terminate = YES;
_backgroundTask = [[UIApplication sharedApplication] beginBackgroundTaskWithName:#"DummyTask" expirationHandler:^{
NSLog(#"Background task expired by iOS");
if (self_terminate) {
[[UIApplication sharedApplication] endBackgroundTask:_backgroundTask];
_backgroundTask = UIBackgroundTaskInvalid;
}
}];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(#"Background task started. Waiting 175 seconds before cleanup.");
[NSThread sleepForTimeInterval:175];
//TODO: perform cleanup code if app is not in the foreground by now
});
}
Some background
I am currently writing a UI Test for a settings pane, and click on buttons to enable certain permissions such as push notifications and location services.
However, if the alert for the permission has been displayed before (regardless of the user allowing or denying access to the permission), the alert will not display again, and will just take the user to the settings app. Unfortunately, these settings do not reset, meaning the first time I run the UI tests, alerts will show; and on all subsequent UI test runs, the buttons will take me to the settings app unless I reset the device before the tests begin.
My issue
Thus, my test needs to know if the app went into the background, and attempt to foreground it to continue the testing:
if app.state == background {
foregroundApp()
}
// continue with other tests
Is there any way to determine if the app is in the background?
What I tried
I researched methods to determine the state of the application (running/background/etc) from a UI test, and was not able to find much. I tried to check whether certain elements exist:
if (app.navigationBars.element.exists) ...
but this gives me runtime errors[1] if the user is taken to the settings page because the app under test is in the background, and the test cannot lookup the navigationBars (or other elements).
I tried using some of the methods from Facebook's private headers for XCUIApplication() and XCUIElement().
XCUIApplication().state always returns 3 no matter what state the app is currently in, and any attempts to call XCUIApplication().resolve() to foreground the app give me the same errors as before[1]
I tried to rewrite the logic to foreground the app before resuming the tests, but methods such as XCUIApplication().launch() kill the app before restarting, which I cannot do. Only siri service seems to work for me, but I cannot access the siri service through the corporate proxy, and modifying proxy permissions is not possible.
Is there any other way to check the app state?
Errors
[1] This error is printed every time I try to do something involving state. I do not call snapshotView anywhere, and thus the suggestion to use afterScreenUpdates is useless.
Failure to get snapshot within 15.0s
Cannot snapshot view (<UIKeyboardImpl: 0x7febcc75d000; frame = (0 0;
414 226); layer = <CALayer: 0x608000625720>>) with
afterScreenUpdates:NO, because the view is not in a window. Use
afterScreenUpdates:YES.`
tl;dr
I need to check whether the app I am UI testing has entered the background (i.e. user pressed the home button). Checking for existence of particular elements such as navigation bars doesn't work, neither do most methods from Facebook's private headers for XCUIApplication/XCUIElement. Foregrounding the app also causes issues, and relaunching the app is not an option; neither is siri service.
You can do this in Swift 4, using XCUIApplication.state, which will give you information about the state of the app - whether it's in the foreground or background etc. however, it's not possible to find this information in Swift 3 and below. Essentially, UI testing in Swift 3 doesn't support leaving the app.
Sorry if this question is too basic, but I'm stuck.
Scenario:
My app uses background and suspended locationUpdates using startMonitoringSignificantLocationChanges.
in my AppDelegate I have:
if let options = launchOptions {
locationKey = options[UIApplicationLaunchOptionsLocationKey] as! Bool
}
So when app is launched by location manager, my locationKey = true.
I was hoping to use locationKey inside the app to distinguish location manager launching or user launching.
The problem is:
When the app is launched by location manager, the behavior is exactly as when user launch the app, I mean, all views (from launch process) are instantiated, but app still "closed".
When I tap to open the app, it is "like" is already opened, so, I can't verify my locationKey, because it is always true and AppDelegate (didFinishLaunchingWithOptions) is not triggered again and then is quite hard to figure out how I can process the startup in its different ways, user and location.
My question is, how can I identify that the app was launched by location and when user really open the app I "restore" its normal way ?
Thank you and sorry if it's not clear
can you be a bit more clear about the behaviour you expect for your app?
The app won't ever be launched by location :
once the user launch the app (triggering didFinishLaunchingWithOptions),
the app can go into background mode (aka being suspended) and can do some work (like updating locations, finishing some tasks, or delegating unfinished downloads to the system so then can finish) or is killed.
When the user come back to the app either the app was in background and switch to foreground mode or it was killed and didFinishLaunchingWithOptions will be invoke again to relaunch the app completly.
I have implemented NSURLSession for downloading fairly large files from our servers. Now as long as I'm working in foreground or background and go back to the app the transactions are working and getting finished.
But if I force-quit the app using the the multitasking screen and re-open the app again. the downloading process is not getting finished although as I understood from the docs, it should, here what the docs state:
If an iOS app is terminated by the system and relaunched, the app can use the same identifier to create a new configuration object and session and retrieve the status of transfers that were in progress at the time of termination. This behavior applies only for normal termination of the app by the system. If the user terminates the app from the multitasking screen, the system cancels all of the session’s background transfers. In addition, the system does not automatically relaunch apps that were force quit by the user. The user must explicitly relaunch the app before transfers can begin again.
Meaning if I relaunch the app the transaction before the force-quit should started again, or are they? Is there an additional operation I need to commit in order this to work?
UPDATE: I stumbled on this project:
https://github.com/Heikowi/HWIFileDownload#force-quit
That states:
Force Quit
After the app has been killed by the user, downloads do not continue in the background. On iOS 7 (and later) resume data is passed back.
Meaning there is a way to receive resume data even if the application was killed by the user in the background. Only the project is written in Objective-C and I can't understand what are they doing to achieve this.
After a force-quit the:
NSURLSessionTaskDelegate - (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didCompleteWithError:(NSError *)error
delegate method will be called when the app is restarted. If the download task can be resumed the error object will contain the resume data:
[error.userInfo objectForKey:NSURLSessionDownloadTaskResumeData].
Using this data you can resume the download process by creating a NSURLSessionDownloadTask with:
(NSURLSessionDownloadTask *)downloadTaskWithResumeData:(NSData*)resumeData.
More info about that can be found in Life Cycle of a URL Session with Custom Delegates, step 13.
I think that after your application did force-quit you should start all over again (.
If the user terminates your app, the system cancels any pending tasks.
and
When all of the tasks associated with a background session are complete, the system relaunches a terminated app (assuming that the sessionSendsLaunchEvents property was set to YES and that the user did not force quit the app)
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
-> use URLSession background Sessions download doesn't stop at all....you don't have to explicitly code for resuming the download or something..
https://developer.apple.com/reference/foundation/urlsession
check for background session in this link...if you're not able get the still...comment me and i would help in detail.
How programmatically restart an iPhone app in iOS?
I find this way http://writeitstudios.com/david/?p=54
But may be something simple.
The only way I know to do this is not ideal, but it works.
First, your app has to opt out of background execution (multitasking) The app has to quit when exited, not run as a background task. This is done with the plist key UIApplicationExitsOnSuspend.
Second, your app needs to register a custom URL scheme that can be used to launch the app.
Third, you need a web page hosted somewhere that when loaded will redirect to your app's custom URL scheme.
Forth, the user needs an active Internet connection.
To exit and restart, call UIApplication openURL on your hosted redirecting web page. Your app will exit and safari will launch and load your page. The page will redirect Safari to your custom URL scheme, prompting Safari to internally call openURL, causing iOS to launch your app.
my post that you linked to is referring to a Cocoa Application, not the iOS. On the iOS, you can quit an application (but Apple doesn't like this) by using exit(0); but I don't recommend that. You cannot restart iPhone apps though.
Unless you're developing for jailbroken devices, Apple won't even allow you to programatically terminate your app. So restarting the device is out of the question.
Your AppDelegate instance has a method
(void)applicationDidBecomeActive:(UIApplication *)application
{
}
In here, you can put logic to figure out if the app should restart, or continue doing whatever it was doing. For example you can have a BOOL variable appMustRestart that is false at first but gets triggered as true whenever something happens in your app that you'd like the next time to be a fresh relaunch.
if (appMustRestart)
{
[self resetVars]; // call a method that resets all your vars to initial settings
// INSERT CODE HERE TO TRANSFER FOCUS TO INITIAL VIEWCONTROLLER
}