UITextView calling previous number - ios

I have an iOS application that looks up employees and shows their work number/mobile number. The problem I am having is after looking up one person and then another, when I click on the number of the person I just looked up, it keeps calling the number of the previously searched person.
And before anyone says anything, I have looked at UITextView link detection in iOS 7
I have tried setting the textview.text = nil, disabling and enabling selectable, editable and scrollEnabled. Nothing has worked. If anyone could please shed some light on the problem I am having, that would be great. Thank you!
Lookup 1st employee, click on phone# and it calls correct number
Lookup another employee (2nd employee), shows correct phone#, click on phone# and it calls 1st employee's phone#
Lookup another employee (3rd employee), shows correct phone#, click on phone# and it still calls 1st employees phone#.
the UITextView has selectable = true, detection = phone numbers, editable = NO, have tried setting scroll enabled = YES and NO.
iOS Deployment target is 7.0
Code:
#property (weak,nonatomic) IBOutlet UITextView *Phone;
found = [happyArray valueForKey:#Extension"];
if ([found length]>0) _Phone.text = [NSString stringWithFormat:#"%#",[found stringByTrimmingCharactersInSet: [NSCharacterSet whitespaceCharacterSet]]];

This appears to be an iOS bug, like it mentions in this other answer of SO. Try setting the text view to editable and then unsetting it just after setting the new number.
If that doesnt work, use setText:nil before setting the number again.

Related

UITextContentTypeEmail has no effect on quick type suggestions on UITextField

I am currently trying to display quick type suggestions for the user's email address when the user is editing the email text field as well as the email confirmation text field. To do that, I set two things:
the text field's textContentType as well as its autocorrectionType to get the quick type bar to appear.
However, it seems that setting the textContentType has no effect on the contents of the quick type bar; it simply displays "words" as they would appear when editing any other text field. This is obviously not the result I want my users to see.
Here is the current code:
SEL selector = NSSelectorFromString(#"textContentType");
// Make sure that the text field is actually able to process the event,
// the iOS version is greater than 10.3
if([self.emailTextField respondsToSelector: selector]){
self.emailTextField.textContentType = UITextContentTypeEmailAddress;
self.emailConfirmationTextField.textContentType = UITextContentTypeEmailAddress;
self.emailTextField.autocorrectionType = UITextAutocorrectionTypeDefault;
self.emailConfirmationTextField.autocorrectionType = UITextAutocorrectionTypeDefault;
}
From what I've read, this works for 3rd party apps only starting from ios 11

UITextView with voiceover

Here is my very simple code for creating a UITextView.
UITextView *textView = [[UITextView alloc] initWithFrame:self.view.bounds];
textView.editable = NO;
textView.text = #"Using iOS 3.0 and later, VoiceOver is available to help users with visual impairments use their iOS-based devices. The UI Accessibility programming interface, introduced in iOS 3.0, helps developers make their applications accessible to VoiceOver users. Briefly, VoiceOver describes an application’s user interface and helps users navigate through the application’s views and controls, using speech and sound. Users familiar with VoiceOver in Mac OS X can leverage their experience to help them quickly come up to speed using VoiceOver on their devices.";
[self.view addSubview:textView];
Given that I could not possibly do anything wrong here I am just wondering if this is an expected behaviour or a bug perhaps somebody also faced:
With voiceover enabled I expect the entire text view to be “highlighted” on tap, then its accessibilityLabel to be read to a user and after they double tap, the entire text view’s text to be read.
But what is happening is that a small portion of the text view is highlighted (usually 2 lines), accessibilityLabel is not read, but the first “highlighted" line and the first letter (!) of the second line are read instead and only after a user double taps the entire text is read.
Especially reading the first letter in the second highlighted line confuses me. Plus shouldn’t accessibilityLabel be always read in the beginning?
This looks like a big to me but Apple has always paid so much attention to accessibility, so I’m having doubts if I should report it, may be the meant it to be this way.
Another question: is there a way to achieve the following behaviour (without subleasing UITextView) when voiceover is enabled: user taps UITextView -> accessibilityLabel and the entire text are read?
In case someone else has this problem here is the answer:
textView.accessibilityTraits = UIAccessibilityTraitStaticText;
Combining the other two answers from this post has the desired effect. i.e.
textView.isAccessibilityElement = true
textView.accessibilityTraits = .staticText
Also if you are setting the attributedText property on the UITextView make sure you DO NOT set the accessibilityLabel (on the UITextView). Doing so will cause VoiceOver (Xcode 12.5, iOS 14.4.2) to read the text twice.
textView.isAccessibilityElement = true
This Works

iOS 7: Best way to implement an textview that presents previous input but is easy to clear

I'm porting a Mac app to the iPhone and I've run into an unexpected problem.
On the Mac there's a text field that is automatically pre-selected (= first responder) when a dialog shows up. The text field shows the text you entered in the field the last time and the text is pre-selected so that if you just start typing it gets cleared away. If you want to edit the existing text instead you just hit the forwards or backwards arrow.
On the iPhone this behavior seems very hard to implement. The text view shows up with the old text and I can even get it to pre-select but whatever I do the result is not quite right.
When I use
[aTextView setMarkedText: myText
selectedRange: newRange];
the text does show up as marked and if I just start typing the old text goes away. However there's no equivalent to the cursor keys on iOS, so I cannot NOT erase the text.. which is hardly the point.
What kind of iOS idiom would be appropriate for giving the option to either edit or overwrite existing text?
Best regards,
Frank
Try this code in your UITextViewDelegate
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
dispatch_async(dispatch_get_main_queue(), ^{
[textView selectAll:self];
});
return YES;
}

UITextView Calls Previous Number

I have a UITextView which should auto detect phone numbers. The detection works fine, however if the text is changed the link will call the previous number, even though the actual text has changed. What is the problem? Is this another iOS 7 bug (I have experienced quite a few with UITextView?
This is a bug in iOS 7.
What you can try is resetting the text to nil, before setting the new string.
_textView.text = nil;
_textView.text = yourText;
This will reset the text view and correct phone number detection should work again.

UITextView: Link detection working within Simulator, not on device

I've got two UITextViews containing data that should be recongised by the data detection, however whilst one works fine on both device and simulator there's one that only works under Simulator. I've attempted trashing the build from my device, cleaning the product down, removing derived data and nothing seems to resolve the inconsistency.
Link detection was enabled within Interface Builder, the data is passed in with a NSString stringWithFormat: formatted string and set with UITextView setText:. Set the same way for both, so there's no difference there, but it just doesn't seem to work correctly for one of them.
EDIT: On the device if I tap on one of the items that should detect as a link, it'll then turn blue and do link detection. I'm not setting any custom fonts or colours that could have an impact.
It appears that the trick is to setScrollable:NO. Seems to fix the problem, although if you need scrolling, I'm not sure what the answer will be...
Apparently this issue is caused by how iOS is currently handling the UITextView links. It is creating an NSAttributedString that turns sections of the text blue ( when the view contains a link ). So I've figured out that this bug only occurs when a link is the first text in the AttributedString, i.e. the first text in the text view. So it's easily fixed by prepending an whitespace to your text before setting it. Or overriding setText to " " + text;
Hope this helps guys

Resources