Is it possible that my iOS app can auto-restart, each and every time the user accesses their home screen? This is for a jailbroken device -- the app is not destined for the App store.
In general, how can I make my app restart given specific user actions outside the app?
Accelerometer
If all you want to do is make your app run when you encounter certain accelerometer conditions, you can use Activator for that. Activator is a great app, by Ryan Petrich, available on Cydia for free. It lets you configure your device to run any app (or toggle) whenever a certain user action is taken. That could be a home button press, power/lock button press, or accelerometer shake.
If a basic shake isn't what you want, or you are building an app to give to many users, and don't want them to have to setup Activator themselves, then you probably need to write some code yourself.
For example, you could write a Launch Daemon, in addition to your main UI app, and have the launch daemon monitor the accelerometer.
When you detect the specific kind of motion you're interested in, you can launch your UI app with the open command. If this is just for your own use, just download the open package from Cydia. If this is for release to others, make sure your app depends on open to ensure that it's installed. For example, if packaging in a Debian .deb package, the DEBIAN/control file might have this:
Depends: open
to make sure users installing your app will also automatically get open, which your app needs.
Unlock
Your other problem concerns launching the app when the user unlocks the phone. Again, I would use your Launch Daemon to listen for this condition. On iOS 5, I see this notification when I unlock the phone:
Notification intercepted: com.apple.springboard.lockstate
(I detected this by running the notificationWatcher utility from the command line, while SSH'd into my phone. NotificationWatcher is also available from Cydia, as part of Erica Sadun's Erica Utilities package)
So, I would have your launch daemon register for Darwin notifications for "com.apple.springboard.lockstate". Something like this:
CFNotificationCenterAddObserver(CFNotificationCenterGetDarwinNotifyCenter(), //center
self, // observer: can be NULL if callback doesn't need self
onLockStateChanged, // callback
CFSTR("com.apple.springboard.lockstate"), // name
NULL, // object
CFNotificationSuspensionBehaviorDeliverImmediately);
where the callback function is here:
static void onLockStateChanged(CFNotificationCenterRef center, void *observer, CFStringRef name, const void *object, CFDictionaryRef userInfo) {
// if you need access to member data (ivars):
MyLaunchDaemon* this = (MyLaunchDaemon*)observer;
//if (userInfo != nil) {
// CFShow(userInfo);
//}
NSDictionary* info = (NSDictionary*)userInfo;
// I'm not sure if the userInfo object has any useful
// description for the lock state event
if (/* unlocked */) {
// force app to open, or resume from the background
system("/usr/bin/open com.mycompany.MyAppName");
}
}
I see this same notification when the screen is locked, or unlocked, so you may need to have the launch daemon keep track of the locked/unlocked state, or inspect the userInfo object to see if that tells you whether this is a lock or unlock event. I'm sure there's other ways, too.
Update: if you want help sorting out whether the notification occurs when the screen is locked or unlocked, you can see my Update 2 in this other SO answer. notify_get_state() can be used to determine whether the event is an on, or off, event.
Set the value of UIApplicationExitsOnSuspend to YES in your app's Info.plist file.
UIApplicationExitsOnSuspend (Boolean - iOS) specifies that the app
should be terminated rather than moved to the background when it is
quit. Apps linked against iOS SDK 4.0 or later can include this key
and set its value to YES to prevent being automatically opted-in to
background execution and app suspension.
Related
Currently, when I change the camera permissions for my app in Settings, then navigate back to my app, the app will force a refresh and I will lose my place in the app. I follow these steps exactly:
Open an app that uses the camera permission.
Navigate to some screen within the app (so you can visibly see the refresh later)
Go to the Settings app, navigate to the app's settings, and toggle
the camera permission
Double click home and go back to the app.
After a few seconds, it will refresh, bringing you back to the
first screen
Note: I'm using an iPhone 6 running iOS 8.4
I've noticed this behavior on all apps that have the camera permission. My question is:
Is there some way to prevent the app from refreshing/restarting (on resume) after changing the camera permission? It doesn't seem to happen when you toggle location services, for example, and from a usability perspective this is horrible.
User scenario: If a user navigates deep into your app, then needs to change the camera permission (because say they accidentally clicked no last time), they will be forced to navigate back to that screen when they return. This is especially harmful for an app trying to sell you something, or sign you up for a new account. They might try to introduce a new feature where you can use the camera to take a profile picture or scan your credit card. Because the user didn't know about this feature, they might have previously denied camera access, but now want to enable it. After trying to reenable, they come back to your app to find they have to spend 5+ minutes signing up / making a purchase, again! After that, even I would probably give up.
I'm sure that there is no other ways to prevent restarting app. Actually you will get a SIGKILL message but no Crash log when toggling settings. See below links-
https://devforums.apple.com/message/715855
https://devforums.apple.com/message/714178
The only way to prevent this scenario is to save the previous state of you application while terminating.
Store app your current data into a json/plist/NSUserDefaults/archive user model at applicationWillTerminate: method and
restore saved data at applicationWillEnterForeground:
For example- #SignUpViewController register for UIApplicationWillTerminateNotification which will fire when the app is about to terminate. Store user information there.
- (void)viewDidLoad
{
[super viewDidLoad];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(applicationWillTerminate:)
name: UIApplicationWillTerminateNotification object:nil];
}
- (void)applicationWillTerminate:(NSNotification *)notification
{
// store your data here
}
Hope this will help you:)
The accepted answer is correct, however the workaround does not appear to work in the current version of iOS (9.2) - the application seems to terminate before UIApplicationWillTerminateNotification is fired. However by listening to UIApplicationDidEnterBackgroundNotification, the same can be achieved. e.g in Swift, put this in viewDidLoad()
NSNotificationCenter.defaultCenter().addObserver(self, selector: "enteringBackground:", name: UIApplicationDidEnterBackgroundNotification, object: nil)
and have a function like this:
func enteringBackground(sender:AnyObject){
// Save application state here
}
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.
Currently, when I change the camera permissions for my app in Settings, then navigate back to my app, the app will force a refresh and I will lose my place in the app. I follow these steps exactly:
Open an app that uses the camera permission.
Navigate to some screen within the app (so you can visibly see the refresh later)
Go to the Settings app, navigate to the app's settings, and toggle
the camera permission
Double click home and go back to the app.
After a few seconds, it will refresh, bringing you back to the
first screen
Note: I'm using an iPhone 6 running iOS 8.4
I've noticed this behavior on all apps that have the camera permission. My question is:
Is there some way to prevent the app from refreshing/restarting (on resume) after changing the camera permission? It doesn't seem to happen when you toggle location services, for example, and from a usability perspective this is horrible.
User scenario: If a user navigates deep into your app, then needs to change the camera permission (because say they accidentally clicked no last time), they will be forced to navigate back to that screen when they return. This is especially harmful for an app trying to sell you something, or sign you up for a new account. They might try to introduce a new feature where you can use the camera to take a profile picture or scan your credit card. Because the user didn't know about this feature, they might have previously denied camera access, but now want to enable it. After trying to reenable, they come back to your app to find they have to spend 5+ minutes signing up / making a purchase, again! After that, even I would probably give up.
I'm sure that there is no other ways to prevent restarting app. Actually you will get a SIGKILL message but no Crash log when toggling settings. See below links-
https://devforums.apple.com/message/715855
https://devforums.apple.com/message/714178
The only way to prevent this scenario is to save the previous state of you application while terminating.
Store app your current data into a json/plist/NSUserDefaults/archive user model at applicationWillTerminate: method and
restore saved data at applicationWillEnterForeground:
For example- #SignUpViewController register for UIApplicationWillTerminateNotification which will fire when the app is about to terminate. Store user information there.
- (void)viewDidLoad
{
[super viewDidLoad];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(applicationWillTerminate:)
name: UIApplicationWillTerminateNotification object:nil];
}
- (void)applicationWillTerminate:(NSNotification *)notification
{
// store your data here
}
Hope this will help you:)
The accepted answer is correct, however the workaround does not appear to work in the current version of iOS (9.2) - the application seems to terminate before UIApplicationWillTerminateNotification is fired. However by listening to UIApplicationDidEnterBackgroundNotification, the same can be achieved. e.g in Swift, put this in viewDidLoad()
NSNotificationCenter.defaultCenter().addObserver(self, selector: "enteringBackground:", name: UIApplicationDidEnterBackgroundNotification, object: nil)
and have a function like this:
func enteringBackground(sender:AnyObject){
// Save application state here
}
Swift 1.2
Xcode 6
Long-time listener, first-time caller.
Hello,
Straight from the horse's mouth: "To handle changes in iCloud availability, register to receive the NSUbiquityIdentityDidChangeNotification notification."
Here is the code they provide to implement this:
[[NSNotificationCenter defaultCenter]
addObserver: self
selector: #selector (iCloudAccountAvailabilityChanged:)
name: NSUbiquityIdentityDidChangeNotification
object: nil];
I Swiftified it in my app to:
var observer = NSNotificationCenter.defaultCenter().addObserverForName
(NSUbiquityIdentityDidChangeNotification, object: nil, queue: NSOperationQueue.mainQueue()
){...completion block...}
src: https://developer.apple.com/library/ios/documentation/General/Conceptual/iCloudDesignGuide/Chapters/iCloudFundametals.html#//apple_ref/doc/uid/TP40012094-CH6-SW6
What is the correct way to implement this? Does it go in the AppDelegate? Do we remove the observer when the app gets sent to the background?
The problem I'm encountering is that when the Ubiquity Token changes, the app is terminated anyway because the user has changed iCloud settings.
How do you all manage to subscribe to this notification, and, if you don't, what do you do instead to keep track of the current logged in iCloud user?
Thank you!
Short Answer
To be notified in iOS when a user logs in or out of iCloud while using your app, use CKAccountChangedNotification, not NSUbiquityIdentityChanged.
Long Answer
I've been trying to get this to work as well. I remembered something from one of the talks at WWDC16 that there was something like this that they recommended to use. However, from the sample code they provide, I've only been able to find NSUbiquityKeyIdentityChanged, which I haven't been able to get to work.
So I went back to the video (it's from 2015). That's where I saw them refer to CKAccountChangedNotification – and it works exactly as expected:
Launch your app on the simulator from Xcode
Exit to the Settings app on the simulator
Log in (or out) of iCloud account
Go back into your app (tap icon on simulator home screen)
A notification is received.
Exit to Settings app again
Log back out (or in) to iCloud account
Go back into your app again
Another notification is received.
In Swift 3.0 there was another renaming:
Now the NSUbiquityIdentityDidChangeNotification has changed into NSNotification.Name.NSUbiquityIdentityDidChange.
So the full registering is the following:
// Register for iCloud availability changes
NotificationCenter.default.addObserver(self, selector: #selector(...), name: NSNotification.Name.NSUbiquityIdentityDidChange, object: nil)
On iOS 10 I found that NSUbiquityIdentityDidChangeNotification was never sent. Provided I had a CKContainer (as per the docs), CKAccountChangedNotification was sent in very limited circumstances.
Built with xCode 9.1 then tested on iOS 10.02 iPhone 6+ and iOS 11.0.3 iPhone SE
CKAccountChangedNotification was sent if
User logged into iCloud account, or
User enabled iCloud Drive in iOS 11. This always resulted in iCloud Drive->App being enabled. However, fetching the account status afterwards yielded NoAccount!
User enabled iCloud Drive in iOS 10. The subsequent state of iCloud Drive->App was whatever it was when I disabled iCloud Drive. The account status was appropriate. However, if iCloud Drive->App was disabled at this point, enabling it did not produce a termination or a notification.
Application was terminated if
User logged out of iCloud regardless of iCloud Drive status
User disabled iCloud Drive->App
User disabled iCloud Drive (even if iCloud Drive->App already disabled)
User started the app with iCloud Drive enabled, then enabled iCloud Drive->App
I found the same issues, see this question for my comments.
To summarize: On iOS I think apps are killed anyway when the iCloud account changes (or is just signed off). So no need to listen to NSUbiquityIdentityDidChangeNotification.
If you are on tvOS, however, your app is not killed. When your app becomes active, you do receive one or more NSUbiquitousKeyValueStoreDidChangeExternallyNotification with NSUbiquitousKeyValueStoreChangeReasonKey set to NSUbiquitousKeyValueStoreAccountChange because tvOS exchanges your entire ubiquity key-value-store.
Maybe you could use that with some trickery to detect account changes, e.g. store a NSUUID in the ubiquity key-value-store, and when the value changes, it means there is a new account. But you cannot detect if an account is logged off.