I have an app that uses the Address Book. When running in iOS 6 it runs this code when the user does something that requires Address Book access.
if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusNotDetermined)
{
ABAddressBookRef addressBookRef = ABAddressBookCreateWithOptions(NULL, NULL);
ABAddressBookRequestAccessWithCompletion(addressBookRef, ^(bool granted, CFErrorRef error)
{
if (granted)
{
showContactChooser();
}
});
CFRelease(addressBookRef);
}
else if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusAuthorized)
{
showContactChooser();
}
else
{
showAccessDeniedAlert();
}
This works perfectly: I am able to read the contacts information and when the user denied access, the app reacts accordingly.
However, if the user:
Allows Contacts access in the app,
Quits the app,
Goes to Settings->Privacy->Contacts and disables Contacts access for the app,
Runs the app,
While the app is running in background goes to settings and enables Contact access for the app,
the app immediately crashes inside main() with no exception information or a meaningful stack trace. I tried turning on the "all exceptions" and [NSException raise] breakpoint, but that didn't give me any more information.
The crash can be reproduced even if the app doesn't run the above code during the launch.
What's happening here? Is there a callback that I should be subscribing to?
I've seen this in my own app. And I've seen others report this as well. I'm pretty sure this is deliberate behavior. The OS kills any background apps that react to changes in privacy permissions. Apple appears to have taken a sledgehammer approach to this. It's not a crash (though it may appear so when running in the debugger). Apps get terminated for various other reasons. Add this to the list of reasons. This gives us more reason to do a good job restoring app state upon a full restart of our apps.
Note that this behavior applies to all of the various privacy settings such as contacts, photos, microphone, calendar, and camera.
Usually, when an application comes back from being suspended, it should call application:didEnterForeground from your AppDelegate. In my opinion, that would be a good place for you to readjust your address book permissions.
Related
Our app is using WLAN to communicate with a wireless device. When our app is installed in iOS 10. Sometimes, udp socket doesn't work. The reason for that is, in iOS 10 they added a new setting or permission under your app that allows the user to switch on or off the user of WLAN or cellular data.
The following would appear in the settings of the app:
When I tap on the Wireless... It will bring me to this UI:
After allowing WLAN use. The app would work fine.
Now, the problem is, sometimes, or in some devices running iOS 10, the settings that I just showed you doesn't appear(I am referring to the setting shown on the first image). So, is there anything I can do to make that settings always appear? It seems that sometimes iOS system doesn't recognize that my app is using wireless data. And it would result in my app would never get to use WLAN forever.
There is no user permission to use WIFI in iOS10.
The application in your screenshot (BSW SMART KIT) is using Wireless Accessories (WAC), i.e. is able to connect to wireless speakers. To accomplish this the Wireless Accessory Configuration capability is required. This is what you can dis/enable in the systems settings (your screenshot).
The switch in the settings shows up after connecting to a device via WIFI through WAC. You can see this behaviour in your sample app (BSW SMART KIT) too.
This sample code might let you get the idea. Detailed information in Apples documentation.
After a time of researching. I ended up seeking help with Apple Code Level Support. Apple states that this problem would most probably occur when you reskin your app. They say that probably it's because of the Image UUID of the main app and the reskinned app are the same. When you install both of them in your phone, the system will treat the reskinned app as the same app compared to the main app. So, if the one app fails to access WLAN, then it will also affect the other one. According to them, this appears to be a bug in iOS. And currently, they don't have any solution for the developers. This is the radar bug number:
What I did to somehow lessen the occurrence of the problem is to add tracking to the Network Restriction by using the following code.
- (void)startCheckingNetworkRestriction
{
__weak AppDelegate *weakSelf = self;
_monitor = [[CTCellularData alloc] init];
_monitor.cellularDataRestrictionDidUpdateNotifier = ^(CTCellularDataRestrictedState state)
{
[[NSOperationQueue mainQueue] addOperationWithBlock:^
{
NSString * statusStr;
switch(state)
{
case kCTCellularDataRestrictedStateUnknown:
{
statusStr = #"restriction status:Unknown";
}
break;
case kCTCellularDataRestricted:
{
statusStr = #"restriction status:restricted";
[weakSelf performUrlSession];
}
break;
case kCTCellularDataNotRestricted:
{
statusStr = #"restriction status:not restricted";
}
break;
default:
{
abort();
}
break;
}
NSLog(#"Restriction state: %#", statusStr);
}];
};
}
Take note that you have to import CoreTelephony to do this.
#import CoreTelephony;
when I detect that the network is restricted. I will open a URL session to force internet access attempt and would hope that the restriction alert dialog would pop out. Once the alert is pop out, then the WLAN Access Settings that I was talking about would definitely appear under the settings. There are times that this doesn't work. If it happens, then you'll just have to rename the bundle ID, and make a couple of changes to your code and then rebuild it a couple of times (Well, that's what I did when I was experimenting this). Reinstalling the app won't do a thing. Restarting and resetting the phone won't do either.
Hope this helps.
I have an app that uses the Address Book. When running in iOS 6 it runs this code when the user does something that requires Address Book access.
if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusNotDetermined)
{
ABAddressBookRef addressBookRef = ABAddressBookCreateWithOptions(NULL, NULL);
ABAddressBookRequestAccessWithCompletion(addressBookRef, ^(bool granted, CFErrorRef error)
{
if (granted)
{
showContactChooser();
}
});
CFRelease(addressBookRef);
}
else if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusAuthorized)
{
showContactChooser();
}
else
{
showAccessDeniedAlert();
}
This works perfectly: I am able to read the contacts information and when the user denied access, the app reacts accordingly.
However, if the user:
Allows Contacts access in the app,
Quits the app,
Goes to Settings->Privacy->Contacts and disables Contacts access for the app,
Runs the app,
While the app is running in background goes to settings and enables Contact access for the app,
the app immediately crashes inside main() with no exception information or a meaningful stack trace. I tried turning on the "all exceptions" and [NSException raise] breakpoint, but that didn't give me any more information.
The crash can be reproduced even if the app doesn't run the above code during the launch.
What's happening here? Is there a callback that I should be subscribing to?
I've seen this in my own app. And I've seen others report this as well. I'm pretty sure this is deliberate behavior. The OS kills any background apps that react to changes in privacy permissions. Apple appears to have taken a sledgehammer approach to this. It's not a crash (though it may appear so when running in the debugger). Apps get terminated for various other reasons. Add this to the list of reasons. This gives us more reason to do a good job restoring app state upon a full restart of our apps.
Note that this behavior applies to all of the various privacy settings such as contacts, photos, microphone, calendar, and camera.
Usually, when an application comes back from being suspended, it should call application:didEnterForeground from your AppDelegate. In my opinion, that would be a good place for you to readjust your address book permissions.
I have an app that uses the Address Book. When running in iOS 6 it runs this code when the user does something that requires Address Book access.
if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusNotDetermined)
{
ABAddressBookRef addressBookRef = ABAddressBookCreateWithOptions(NULL, NULL);
ABAddressBookRequestAccessWithCompletion(addressBookRef, ^(bool granted, CFErrorRef error)
{
if (granted)
{
showContactChooser();
}
});
CFRelease(addressBookRef);
}
else if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusAuthorized)
{
showContactChooser();
}
else
{
showAccessDeniedAlert();
}
This works perfectly: I am able to read the contacts information and when the user denied access, the app reacts accordingly.
However, if the user:
Allows Contacts access in the app,
Quits the app,
Goes to Settings->Privacy->Contacts and disables Contacts access for the app,
Runs the app,
While the app is running in background goes to settings and enables Contact access for the app,
the app immediately crashes inside main() with no exception information or a meaningful stack trace. I tried turning on the "all exceptions" and [NSException raise] breakpoint, but that didn't give me any more information.
The crash can be reproduced even if the app doesn't run the above code during the launch.
What's happening here? Is there a callback that I should be subscribing to?
I've seen this in my own app. And I've seen others report this as well. I'm pretty sure this is deliberate behavior. The OS kills any background apps that react to changes in privacy permissions. Apple appears to have taken a sledgehammer approach to this. It's not a crash (though it may appear so when running in the debugger). Apps get terminated for various other reasons. Add this to the list of reasons. This gives us more reason to do a good job restoring app state upon a full restart of our apps.
Note that this behavior applies to all of the various privacy settings such as contacts, photos, microphone, calendar, and camera.
Usually, when an application comes back from being suspended, it should call application:didEnterForeground from your AppDelegate. In my opinion, that would be a good place for you to readjust your address book permissions.
When we install new app on iOS device, it ask for as a Alert view as a "Do you want to access iPhone contacts in your application. But when I am installing the app first time in iOS device, it is not showing any alert view, So How user will know that he can access iPhone contacts in my application.
Any Solution,
Thank You
This will ask by the apple when you try to use address book.
in the future if you wants to show you can use the following code
-(void)requestAddressBookAccess
{
ViewController * __weak weakSelf = self;
ABAddressBookRequestAccessWithCompletion(self.addressBook, ^(bool granted, CFErrorRef error)
{
if (granted)
{
dispatch_async(dispatch_get_main_queue(), ^{
});
}
else{
}
});
}
iOS shows that alert when you try to access the address book for the first time. So to show it, just read something from the address book.
However, it may be a better experience to "pre-ask" using your own alert first, if you want to give the user information about why you need access to contacts.
This approach was recently discussed here.
Note that, during development, if you ask permissions in your app, then delete and reinstall the app, the permissions are remembered and will not be requested again. You have to go to Settings - General - Reset and reset the location and privacy settings.
I have an app that uses the Address Book. When running in iOS 6 it runs this code when the user does something that requires Address Book access.
if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusNotDetermined)
{
ABAddressBookRef addressBookRef = ABAddressBookCreateWithOptions(NULL, NULL);
ABAddressBookRequestAccessWithCompletion(addressBookRef, ^(bool granted, CFErrorRef error)
{
if (granted)
{
showContactChooser();
}
});
CFRelease(addressBookRef);
}
else if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusAuthorized)
{
showContactChooser();
}
else
{
showAccessDeniedAlert();
}
This works perfectly: I am able to read the contacts information and when the user denied access, the app reacts accordingly.
However, if the user:
Allows Contacts access in the app,
Quits the app,
Goes to Settings->Privacy->Contacts and disables Contacts access for the app,
Runs the app,
While the app is running in background goes to settings and enables Contact access for the app,
the app immediately crashes inside main() with no exception information or a meaningful stack trace. I tried turning on the "all exceptions" and [NSException raise] breakpoint, but that didn't give me any more information.
The crash can be reproduced even if the app doesn't run the above code during the launch.
What's happening here? Is there a callback that I should be subscribing to?
I've seen this in my own app. And I've seen others report this as well. I'm pretty sure this is deliberate behavior. The OS kills any background apps that react to changes in privacy permissions. Apple appears to have taken a sledgehammer approach to this. It's not a crash (though it may appear so when running in the debugger). Apps get terminated for various other reasons. Add this to the list of reasons. This gives us more reason to do a good job restoring app state upon a full restart of our apps.
Note that this behavior applies to all of the various privacy settings such as contacts, photos, microphone, calendar, and camera.
Usually, when an application comes back from being suspended, it should call application:didEnterForeground from your AppDelegate. In my opinion, that would be a good place for you to readjust your address book permissions.