Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>UPDATE:</strong> Since iOS 7 and <em>TextKit</em>, syntax highlighting has become easy as pie. <a href="http://www.objc.io/issue-5/getting-to-know-textkit.html" rel="noreferrer">Look no further than here</a> for an introduction (by me).</p> <hr> <p>Assuming that you want an editable component, there is not too much hope. Giving a quick overview, just to make sure I cover everything:</p> <ul> <li><code>UITextView</code>: <em>plain text</em> only, no (public) way around. But <em>editable</em>. No chance to alter anything, no chance to get geometry etc. Uses a web view internally. Each paragraph is a <code>&lt;div&gt;</code>, which is altered by the editing engine. You could change the DOm in there but that's all private API. All private, hence no option.</li> <li><code>UIWebView</code>: <em>html</em>, so it can be styled, have embedded images, etc. I guess (without looking into it) that this is what the previously mentioned Three 20 UI uses. The problem: <em>cannot be edited</em>. There's no (public) way around that. You canot get selections, acces the DOM, etc without private API and a lot of headaches. Editing would work like in UITextView but require a whole new level of headache. Still: private.</li> <li><code>CoreText</code> Framework: Since iOS 3.2 a very very good <em>rendering</em> engine. But that's it. Can directly layout and render <code>NSAttributesString</code>s. However, there is no user interaction. No text selection, no text input, no spell checking, no replacements, no highlights, no no no no no. Just rendering. And quite a bit of work to make it fast on old devices with long texts.</li> <li><code>UITextInput</code> Protocol: Allows interaction with the keyboard and to grab <em>text input</em>. Also features basic text replacements. Problem: text input only, badly documented. No text selection etc (see above).</li> </ul> <p>So here we are. Two fully functional components that lack a central function and two partial solutions that lack the missing link. Here are all viable approaches I can come up with:</p> <ul> <li>Have the user edit a <code>UITextView</code> unstyled and display the content styled in a <code>UIWebView</code>. For the latter you can use the Three20 thing.</li> <li>Build the missing link between <code>CoreText</code> and <code>UITextInput</code>. This includes, but is not limited to, text selection, highlight, background colors, text storage &amp; management, efficiency, spell checking etc. Some of these are provided by system frameworks but still need a lot of integration.</li> <li>File a bug and wait for a nice public API to come (my personal approach).</li> <li>Convince Apple to allow private API again and mess with <code>UItextView</code>s DOM.</li> </ul> <p>The Omni Group has taken the second approach and created an editable text view. You can find it in the <a href="http://github.com/omnigroup/OmniGroup/tree/master/Frameworks/OmniUI/iPad/" rel="noreferrer">OmniUI</a> framework. However, this implementation is far from perfect. (at least it was when I last checked a few months ago). They tried hard but still didn't manage to get to Apples perfection in user interaction. Apple must have invested at least a few man-years into doing only the UI-interaction with text selection and editing. Nothing to be done at home, and as it seems even for companies as the omni group.</p> <p>There is a interesting aspect to all of this: iWork. Apple claims to not use any private API in them. But the text selection is the very same as in the OS. So they must have copied framework source into the apps. Very honest approach ;)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload