Does anyone know what made Apple leave out NSAttributedString when turning AppKit into UIKit?
The reason I ask is that I would really like to use it in my iPhone app, and there appears to be no replacement or alternative than doing it myself...
It is possible to have mixed font attributes on a string - it's just a hell of a lot of work to to achieve something similar that was possible with a few lines of code with NSAttributedString.
Also, doing all this extra drawing code myself makes my table view cells really heavy, and really hurts performance.
Anyone got any ideas? Any genius's working on an opensource alternative to NSAttributedString?
NSAttributedString is now on the iPhone as of 4.0 Beta
The current from the documentation recommended way to do it is to use a UIWebView.
I don't know if this is still relevant for you, but Joe Hewitt has published his three20 library in the meantime, which contains TTStyledText and TTStyledTextLabel to fit your needs.
I'm afraid you're going to have to roll your own. If you're getting bogged down when doing table drawing, I'd probably switch to raw Quartz calls; try and dump all your drawing into a single view, and do all your complex string drawing within it. NSAttributedString is handy, but I don't think it's using all that much special AppKit-mojo to get much better performance than straight string drawing calls.
The answer above indicates that NSAttributedString is available on OS 4.0 and above, but per the documentation it's available on 3.2:
NSAttributedString Class Reference
Inherits from NSObject
Conforms to NSCoding, NSCopying, NSMutableCopying, NSObject (NSObject)
Framework /System/Library/Frameworks/Foundation.framework
Availability Available in iPhone OS 3.2 and later.
Companion guide Attributed String Programming Guide
Declared in NSAttributedString.h
Another approach would be to use a UIWebView with HTML. Or, if you are daring you can make use of the undocumented setHTML method on UITextView to set small snippets of formatted text...
To me this seems more like the future of where supporting formatted text will go, some way to leverage Webkit in outputting formatted strings.
Related
In iOS 7 some of the most important string drawing and metrics calculation methods were depracated with no obvious alternative given.
The page on NSString UIKit Additions Reference is red like blood. Almost everything deprecated. Xcode throws 300 warnings at me.
I try to find out what was running through Apples mind and what they changed in UIKit text system but where would I start? Did they mention somewhere why all of this is deprecated and how the text system works different now? And how to adapt? How to calculate text bounding box when label can scale the font to fit size? Is TextKit the solution?
I spent 3 hours on Google but I found no useful information on how to solve this problem.
We should document all alternatives here so all developers who run into this depressive deprecation mess find peace of mind quickly.
If you look at the deprecations, most of them deprecate the use of UIFont to use a dictionary of attributes instead.
drawInRect:withFont: (Deprecated in iOS 7.0. Use drawInRect:withAttributes: instead.)
drawInRect:withFont:lineBreakMode: (Deprecated in iOS 7.0. Use drawInRect:withAttributes: instead.)
sizeWithFont:(Deprecated in iOS 7.0. Use sizeWithAttributes: instead.)
etc…
So if you're looking for a place to start, learn how to use dictionaries of attributes to set up fonts. It looks like a lot of deprecations, but you don't actually need to learn that much new stuff.
If you want to update your code to use the new TextKit system, check out the WWDC videos and the TextKit Programming Guide.
If you want to know Apple's reason for deprecating so much, I'd guess that it has to do with how UILabel and UITextView used to be built on web views, now they're built on TextKit.
I want to make this feature, i did try many ways, but i couldn't find answer.
UITextView + NSAttritubtedString
I think this is best way, but cannot applied to iOS 5. Only over iOS 6.
TTTAttributedLabel (UITextView + Overlay UILabel + CoreText)
Work well in English/Korean characters, but problem occured in japanese/chinese.
JSTokenField (or other Token Libraries)
We need UITextView for supporting multiline, but these are UITextField.
I spent more than 4 days for this problem.. Thanks for reading.
I you really have to support iOS versions prior to iOS 6, then maybe you should take a look at the UITextInput protocol (and related stuff): https://developer.apple.com/library/ios/documentation/uikit/reference/UITextInput_Protocol/Reference/Reference.html
Using this, I've managed to implement a custom component for bankcard-number input, and I think it's certainly possible what you're trying to achieve (although it would take a few days of experimenting to get a good grasp of this stuff).
I've read in the documentation that the NSString category method drawInRect is good for small amounts of text, but is too much overhead for large amounts. The alternative in my case would be to use Core Text CTFrameDraw.
My question is, what is the "cut-off" point between using drawInRect vs Core Text? Is Core Text always faster than drawInRect? If the extra programming is not the issue, should I always just use Core Text instead of drawInRect, even for small strings?
Mostly I'll be drawing paragraphs, but sometimes they can be short lines too.
For me it comes to use core text when I have some specific requirements from the graphic designer. For instance label that need to mix colors, type, font size etc. drawRect is method that draws something in a view layer, is just a wrapper around CG functions, core text is full framework to deal on how to draw text: change fonts, spaces, interlines.
I mean is not fair as a comparison, a better question could be when it comes to use core text instead of common UI text porpoise obejects and the answer is based on your app design-UI related requirements. Hope this helps.
I would write some test code to benchmark the two methods under consideration using your expected statistical distribution of string content. Maybe a timing a few tens of millions of string renders using each. Run the benchmarks on an actual iOS device, as relative performance may be different using the ARM targeted frameworks.
I wonder if using a UIWebView would get all the performance that's possible. The iOS (and every OS) has a constantly loaded webkit ready to go. Its pretty well optimized too. It would also get work offloaded.
Interesting to compare.
I'm using CGContextShowGlyphsAtPoint in my application to render characters that follow a path. I'd had no problems with this at all until I started on i18n of the application and found that Japanese characters appear fine everywhere apart from when I try to render them using this function.
Is there a way to have these characters appear properly, as opposed to being rendered as empty boxes? Stupidly, I didn't see this coming (newbie iPhone developer) and I really need to support these characters :(
I've been searching stackoverflow and google all day but seem to be getting nowhere with this.
Thanks for any help you can offer,
Bryn
This is a very similar question to your own. Basically, it is very difficult to get the appropriate glyphs for doing pure Quartz drawing of text, so I recommend using the NSString UIKit category method -drawAtPoint:withFont:. This will get you all the support that NSString has for languages, while letting you draw directly to a Core Graphics context. It's what we use in the Core Plot framework for text rendering within a CALayer.
However, drawing this way is much slower than pure Quartz text rendering, so if you're doing a lot of text drawing it could slow things down in your application. Also, the UIKit extensions to NSString take into account the flipped graphics context of UIViews and their CALayers, which has caused others problems.
I did not know this, but I did some digging and I'll tell you what I found:
The Quartz2D Programming Guide refers to the "ATSUI Programming Guide" but has no active link.
Google turned up a cached copy of the legacy ATSUI Carbon API here
Apple states here that you should not use ATSUI, but instead use CoreText
There is an open radar to port CoreText to iPhone since 31-Jul-2009 12:54 PM
Sorry mate :(
Is it possible to use the CFAttributedString type to draw formatted text on the iPhone? I see it in the documentation, but I can't figure out how to actually draw it to a context.
Three20 has a formatted text field. Basically Joe Hewitt implemented a light HTML interpreter to render the text, so it is much faster than a webview. fast enough to be used in a tableview.
The workaround is to use a WebKitView. Format your text as HTML and display in a mini web view at whatever size you need.
Actually, it turns out this is answered in the iPhone documentation, I just didn't read it carefully enough:
iPhone OS Note: While Core Foundation on iPhone OS contains CFAttributedString, there are no additions to the APIs in UIKit to add specific attributes such as font, style, or color, and there are no APIs to draw attributed strings.
There you go, no free formatted text. Bummer.
Kyle
There's an undocumented method on TextView to pass in HTML formatted text (it's really a kind of web view underneath). A number of apps in the store make use of it, just make sure your app works without it there.