How can I prevent iOS apps from resetting after changing Camera permissions? - ios

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
}

Related

How to detect if user navigates away from my app in iOS?

I am trying to develop an app which helps people focus. Essentially, users start a session in which they would like to focus. This session lasts as long as the user does not open another app (for example, the user cannot open Facebook). If the user does so, the session is marked as a failure. Users try to last as long as possible.
The issue I see is that iOS does not allow apps to run for more than 3 minutes once the screen turns off. That means that a user can start a session, then put the phone down for 3 or more minutes, and when they unlock the phone, they are presented with their home screen. The app has been killed. A user is then free to roam around and look at any other app, defeating the purpose of my app.
I could use a timer running on a server to maintain overall session duration, and resume the session once the user reopens the app, but this does not solve the issue of users being able to roam before reopening the app.
Are there any ways to get around iOS killing my app? The behavior I want is:
1) User starts session.
2) Session timer begins.
3) If user navigates away from app, session terminates after 30 second warning.
4) If user locks phone, app still runs.
5) When user unlocks phone, app is displayed (not homescreen). Thus, the termination logic is the same.
Thanks!
You can use an observer (add it to your ViewController's viewDidLoad):
NotificationCenter.default.addObserver(self, selector: #selector(applicationWillResignActive(notification:)), name: UIApplication.willResignActiveNotification, object: nil)
And the function will look like this:
#objc func applicationWillResignActive(notification: NSNotification) {
// do something
}

How to open a Swift App from same screen after phone settings configurations [duplicate]

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
}

Ios Location Permission is displayed even before App is launched and disappears Also didFinishLaunchingWithOptions is not called in this Scenario

When i delete the app from Iphone and Run my project again The app is installed and Location Permission is asked even before the app is launched after that it disappears too quickly before user can interact with it. In this scenario the breakpoints in didFinishLaunchingWithOptions and main.m is not working at all but the app is Loading the first screen And Notification permission is Loading .I cannot forward the app to signup screen since the app requires Location for finding the nearest counties users can register But when I stop the project and run again everything is working as it should be I cannot find the reason for this problem How is the app asking for permission without even entering didFinishLaunchingWithOptions? And proceeding to first page in storyboard without even entering viewdidLoad of that particular class
If you once allow or granted the permission then it will not ask second time. So your flow is normal. Location service asks for permission with high priority so it will shown little bit earlier. If you want this on sign up screen then you should implement that code in your viewDidload of signup screen.
Update : (In response to comment)
If you uninstall or delete app from device or simulator that means you are deleting it's all data and configuration or settings(include your location permission). So, if you install it again then there is no permissions set in your device's setting app for your app. So, you got asked again for permission. that's it.

NSUbiquityIdentityDidChangeNotification and SIGKILL

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.

iOS Dropbox Sync API - detecting newer status

I'm integrating the Dropbox Sync SDK into my iOS app. I want to set it up so that when the user is in a UIDocument, and then the app becomes inactive (home button, lock, etc.), and then the file is changed by someone else in Dropbox, and then the user returns to the app, they will be notified that changes were made elsewhere. Here's what I have now:
In my viewDidLoad I have:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(checkForNewerStatus) name:UIApplicationDidBecomeActiveNotification object:nil];
Then I have this method:
- (void)checkForNewerStatus
{
if (self.dropboxFile.newerStatus)
{
//alert user of changes
}
}
This works semi-desirably. When the app first comes back, self.dropboxFile.newerStatus returns NO. If I leave the app and come back a second time, then it returns YES. But I need it to return YES the first time the app comes back. This isn't time related - I can wait several minutes before coming back, and it still fails the first time and succeeds the second. Any ideas?
Many thanks!
Note: this problem only occurs if the app becomes inactive and then the file is changed. If the file is changed while the app is still active, and then the app leaves and comes back, it alerts as expected.
#rmaddy's comment above is correct. Just moving it into an answer.
You need to add an observer on your DBFile to get notified when it changes. What's happening is that your app is being restarted and your immediately checking the status, but since the app just started, it hasn't had time yet to talk to the server and learn about the newer file content. An observer on the DBFile will fire as soon as the app is able to communicate with the server and find out about the change.

Resources