Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

automaticallyAddLinksForType should default to None #50

Open
stigi opened this issue Nov 18, 2011 · 4 comments
Open

automaticallyAddLinksForType should default to None #50

stigi opened this issue Nov 18, 2011 · 4 comments
Labels

Comments

@stigi
Copy link
Contributor

stigi commented Nov 18, 2011

Hello,

I think OHAttributedLabel should by default behave like UILabel. Therefore it should not automatically add links. Additional behavior should rather be opt-in than opt-out.

Looking forward to the discussion :)

Best,
Ullrich

@AliSoftware
Copy link
Owner

My answer might seem awkward, but I will only agree with you when... I will have some documentation on OHAttributelLabel !

The problem is that if I set it to none, I have a lot of questions by mail/issues on github regarding stuff like "I don't understand why links are not detected" and so on...

That's quite the same problem with "userInteractionEnabled" which is NO by default, but if I keep this UILabel's default value for OHAttributedLabel, a lot of people mail me because they managed to make the links detected (underlined and blue) but not understanding why these links are not clickable...

So typically I would agree and keep it to None, but in practice it keeps me away from doing the support for a lot of redondant emails ;)

@MihaiDamian
Copy link

+1 to not adding links by default

In particular adding links for telephone numbers does an extra call to canOpenURL:. that adds a little overhead to the initialization of labels. This can be a minor annoyance when creating lots of labels. The only option available in this case is code removal.

@Horse888
Copy link

Yes, should remove the default adding links behavior. I find that if the label's text is a phone number, and I assign a custom url to it, it will do the right thing on iPod and iPad, but not work on iPhone.

@AliSoftware
Copy link
Owner

As explained by my previous answer, I understand your requests here but I bet than as soon as I modify the default values, I will have complaints the other way around, about it being removed ;)

That's quite the same problem as with the default value of userInteractionEnabled property I was asked to set to YES because too many people told me that tapping on links didn't work… just because they forgot to turn it on.

The problem with default values is that you can never satisfy everyone needs all at once. Some people will use OHAttributedLabel especially for its ability to display links in their labels, and won't be happy if they have to set the automaticallyAddLinksForType for all their labels. Others won't be happy this setting is computed as it is today, as you guys… Whatever I use for the default values, their will always be people asking to use other default values.

In the next version anyway, I will probably isolate the code that sets the default values in a dedicated method (quite like the commonInit method that exists already but only dedicated to default values), so that everybody will be able to easily create a subclass of OHAttributedLabel and override this future setDefaultValues method to put their own default values there to suit everyone needs, even in iOS4.
For those using OHAttributedLabel in iOS5+, they will still be able to use UIAppearance to customize the default values of all their instances at once instead of needing to create a subclass for that.

stegiorgi pushed a commit to wedoit-io/OHAttributedLabel that referenced this issue Jan 21, 2014
Retina resolution Checkmark graphics
stegiorgi pushed a commit to wedoit-io/OHAttributedLabel that referenced this issue Jan 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants