Trying to Integrate TouchId in my application, and i was successful too.
The Question is
Can we customize the Default TouchID UIalertview ?
Can we Disable it?
No, you cannot. As Popeye said in a comment, the system controls that prompt, not your app – you simply request that the system display it for you. This is due to obvious security concerns.
For example, what if you initiated a $100 in-app purchase, but changed the prompt to say, "Place your thumb on the home button to start the game!" Clearly that would not go over well.
You can customized it the message in the alert can be set with the localizedReason parameter
- (void)evaluatePolicy:(LAPolicy)policy localizedReason:(NSString *)localizedReason reply:(void (^)(BOOL success, NSError *error))reply
You can also set the action button (default is "Enter Password") with
LAContext *context = [[LAContext alloc] init];
context.localizedFallbackTitle = [your message]
The "localizedFallbackTitle" is not in the docs but part of the LAContext .h file
Related
Trying to Integrate TouchId in my application, and i was successful too.
The Question is
Can we customize the Default TouchID UIalertview ?
Can we Disable it?
No, you cannot. As Popeye said in a comment, the system controls that prompt, not your app – you simply request that the system display it for you. This is due to obvious security concerns.
For example, what if you initiated a $100 in-app purchase, but changed the prompt to say, "Place your thumb on the home button to start the game!" Clearly that would not go over well.
You can customized it the message in the alert can be set with the localizedReason parameter
- (void)evaluatePolicy:(LAPolicy)policy localizedReason:(NSString *)localizedReason reply:(void (^)(BOOL success, NSError *error))reply
You can also set the action button (default is "Enter Password") with
LAContext *context = [[LAContext alloc] init];
context.localizedFallbackTitle = [your message]
The "localizedFallbackTitle" is not in the docs but part of the LAContext .h file
I am trying to ensure that the iOS app that I am working on is accessible and am trying to implement VoiceOver to ensure this.
One strange thing that I cannot find any help for is when the Touch ID view is displayed (in my case for signing into the app). VoiceOver pronounces ID as a word and not I.D.
I have tried implementing the accessibility attributes to both NSString and the LAContext object but neither seem to change what is read out by VoiceOver. Code snippets below:
LAContext *context = [[LAContext alloc] init];
[context setIsAccessibilityElement:YES];
[context setAccessibilityLabel:#"TEST 2"];
NSError *error = nil;
NSString *label = #"Please authenticate your ID using the Touch ID";
[label setIsAccessibilityElement:YES];
[label setAccessibilityTraits:UIAccessibilityTraitStaticText];
[label setAccessibilityLabel:#"TEST"];
showingTouchID = TRUE;
if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {
[context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:label
reply:^(BOOL success, NSError *error) {
......
The output from VoiceOver with or without context having the accessibility attributes is always the label text.
All help greatly appreciated :)
You should definitely not change the accessibility label just to make VoiceOver pronounce things correctly (i.e. do not try "hack" the label pronounciation). The reason is that VoiceOver does not have speech output only; it has also braille output where blind users expect to read things exactly letter-by-letter as they are written (i.e. see exactly all the spaces, capital/small letters, etc.) If you did e.g. write "I D" instead of "ID", then while VoiceOver would pronounce it perhaps correctly (in the specific version of iOS), blind users, after also reading "I D" on a braille display might think that that is how it is actually written and appear let's say non-professionally when they would then use this wrong spelling in written exchanges with other people.
The correct way to deal with this, albeit without giving you an immediate solution, is:
File a bug with Apple about pronounciation of the specific word with the specific voice in the specific language (e.g. "Expected pronounciation: [aj'di:]" vs. "Actual pronounciation: [id]")
File a bug with Apple to request the ability to customize pronunciation only (i.e. where you would leave the accessibility label intact and correct, but specify to the voice how it should pronounce certain part of the text), and where this customization could be done for each language individually by the translator translating the strings (because wrong pronunciation is language-specific) - also see the next point.
If you can reword, try different word than the problematic one (which seems not applicable in case of "Touch ID" which is a set term). But this is a hack too, as that solves only the English original and does not care about translations where the rewording might on the contrary potentially complicate the pronunciation.
Sorry for the bad news.
Finally, here, both on iOS 8.4.1 and iOS 9.0.2, VoiceOver with default US English iOS voice, at least on this webpage, pronounces "ID" in "Touch ID" as [ajdi:], not [id].
You can try this for a quick work around: Just give space between I and D
NSString *label = #"Please authenticate your ID using the Touch ID";
label.accessibilityLabel=#"Please authenticate your I D using the Touch I D";
Also please note that you can only set accessibility to UIElements and you cannot set it to general variables. It doesn't make sense to set accessibility label for LAContext and to NSString.
YOu need to set the accessibility label to UILabel or the element which you give the NSString to.
Starting with iOS 11, you can set the element's accessibilityAttributedLabel and use the UIAccessibilitySpeechAttributeIPANotation key (Swift: NSAttributedString.Key.accessibilitySpeechIPANotation) to specify the pronunciation for a range of the attributed string.
See "Speech Attributes for Attributed Strings" for other tools you can use to tweak how VoiceOver reads your text.
Is it possible to add interactive notification categories without the notifications permissions dialog popping up? The problem is if they hit "Don't Allow" on the original notifications permissions dialog, but then later change the notification setting manually, your categories never get added and there doesn't seem to be anyway to add them back. Is there anyway to separate the two?
I've tried:
UIMutableUserNotificationAction* snoozeAction = [[UIMutableUserNotificationAction alloc] init];
[snoozeAction setIdentifier:#"snooze_action_id"];
[snoozeAction setTitle:#"Snooze"];
[snoozeAction setActivationMode:UIUserNotificationActivationModeBackground];
[snoozeAction setDestructive:NO];
[snoozeAction setAuthenticationRequired:NO];
UIMutableUserNotificationCategory* SnoozeCategory = [[UIMutableUserNotificationCategory alloc] init];
[SnoozeCategory setIdentifier:kNotifCategory];
[SnoozeCategory setActions:#[snoozeAction] forContext:UIUserNotificationActionContextDefault];
[SnoozeCategory setActions:#[snoozeAction] forContext:UIUserNotificationActionContextMinimal];
NSSet* categories = [NSSet setWithArray:#[SnoozeCategory]];
//NOT asking for permission to send any type of notifications here, just making sure our categories get saved
UIUserNotificationSettings* settings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeNone categories:categories];
[[UIApplication sharedApplication] registerUserNotificationSettings:settings];
As you can see im setting the notification settings to UIUserNOtificationTypeNone, but the permissions dialog still pops up.
From the docs on registerUserNotificationSettings:
The first time your app launches and calls this method, the system asks the user whether your app should be allowed to deliver notifications and stores the response. Thereafter, the system uses the stored response to determine the actual types of notifications you may use.
...
Calling this method with a new user settings object replaces the previous settings request.
So I think what you can do is wrap your code in a method that gets called on each app launch (maybe in application:didFinishLaunchingWithOptions: or even applicationDidBecomeActive:). The user will only be prompted once and if they reject and enable later your new method should add the correct settings.
I want to ask that how I can detect whether my AddressBook was first accessed by an app on ios6.0. I have learnt that no matter an app was reinstalled or not , the system only thinks that the first installation an first launch is the first time an app launched. the question is that I want to remind an user to allow the app access AddressBook with an UIAlertView,but this alertview will appear shortly after the system's alertview .How can I avoid this condition. Any help will be greatly appreciated.
You should basically ignore ABAddressBookRequestAccessWithCompletion. It is useless. If you want to know whether you have access to the database, call ABAddressBookGetAuthorizationStatus().
Further Discussion
ABAddressBookRequestAccessWithCompletion is said by the docs to request address book access from the user. But it doesn't. I will now demonstrate that ABAddressBookRequestAccessWithCompletion is useless. There are two situations:
(1) If this is a completely unknown new app, ABAddressBookRequestAccessWithCompletion is otiose: access will be requested from the user automatically when the app tries to access the address book, so there is no need for ABAddressBookRequestAccessWithCompletion.
(2) If the user has either denied or granted access, ABAddressBookRequestAccessWithCompletion is a no-op! Calling it does nothing; it does not put up the access request alert!
So ABAddressBookRequestAccessWithCompletion is just a bug and should be ignored.
A Major Correction
EDIT In iOS 6.1, this behavior appears to have changed. (I am assuming that my tests on iOS 6.0 were valid, but I have every reason to believe they were.) Now, however, in iOS 6.1, ABAddressBookCreateWithOptions never causes the authorization alert to appear. The only way to make it appear is with ABAddressBookRequestAccessWithCompletion! Thus this function is now essential; if ABAddressBookGetAuthorizationStatus that access is undetermined, you must call ABAddressBookRequestAccessWithCompletion or you won't get access.
I have solved it by this way.
__block BOOL accessGranted;
- (IBAction)accessAddressBook:(id)sender {
CFErrorRef error;
ABAddressBookRef addressBook = ABAddressBookCreateWithOptions(NULL,&error);
ABAddressBookRequestAccessWithCompletion(addressBook, ^(bool granted, CFErrorRef error) {
// accessGranted = granted;
if (!accessGranted && !granted) {
UIAlertView * alertView = [[UIAlertView alloc]initWithTitle:#"Deny Access" message:#"Deny" delegate:self cancelButtonTitle:nil otherButtonTitles:#"cancel", nil];
[alertView show];
[alertView release];
}
});
}
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
if ([alertView.message isEqualToString:#"use contact"] || alertView.message == #"use contact") {
accessGranted = YES;
}
}
The system already shows an alert when you call ABAddressBookRequestAccessWithCompletion()
just augment the system app with your own string.
You should have in your InfoPlist.strings:
"NSContactsUsageDescription" = "Tap 'OK' or this app is useless.";
I've got a button to share an image and every times I click it, I've got this message in the log, I dont understand :
2012-08-12 19:21:30.511 AvisOcean[2239:707] An instance 0xe6b8fe0 of class FBSessionManualTokenCachingStrategy was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info:
(
Context: 0xa5e90, Property: 0x245310>
Context: 0xa5e90, Property: 0x28c400>
)
Any ideas?
The Facebook SDK is leaking observers. I am using SDK v3.1.
This shouldn't be an issue if you are using the SDK without the deprecated headers (ie Facebook.h). But to use native dialogs you need to include the deprecated headers (source: https://developers.facebook.com/docs/howtos/feed-dialog-using-ios-sdk/) which leads to this error when closing/cleaning the active session.
Here is a pull request to fix it: https://github.com/facebook/facebook-ios-sdk/pull/474
You can then rebuild the SDK using Facebook SDK for iOS6/Xcode 4.5 not working
I was having the same problem. I think what had happend is I had initialized Facebook else where and it was giving me errors when I tried to re-initialize it and again invoke a dialog delegate from a different instance.
The instance where i was keeping actual app initialization and accesstoken were different from the one which was invoking the dialog. When I corrected that after going over the documentation, it was solved.
if (nil == self.facebook) {
self.facebook = [[Facebook alloc]
initWithAppId:FBSession.activeSession.appID
andDelegate:nil];
// Store the Facebook session information
self.facebook.accessToken = FBSession.activeSession.accessToken;
self.facebook.expirationDate = FBSession.activeSession.expirationDate;
}
[self.facebook dialog:#"feed" andParams:params andDelegate:self];
Do a quick logout prior to assigning accessToken and expirationDate, that will help clean up some nasty error that you had seen. I'm sure this is just a temporary solution for those using deprecated Facebook headers.
// Initiate a Facebook instance
if(!_facebook)
_facebook = [[Facebook alloc] initWithAppId:FBSession.activeSession.appID andDelegate:nil];
// Store the Facebook session information
[_facebook logout];
_facebook.accessToken = FBSession.activeSession.accessToken;
_facebook.expirationDate = FBSession.activeSession.expirationDate;
I see this message when my Facebook object is dealloc'ed. I'm using the 3.0.8 SDK. In my case I'm thinking that the Facebook object should remove itself as an observer of its tokenCaching before releasing it in its dealloc. Your case might be different since it doesn't sound like you'd be clearing the FB object. Perhaps the suggestions here would help.