DTRichTextEditor / DTCoreText News

You might have noticed – if you follow the DTCoreText project on GitHub – that I made many changes on this Open Source project. The most recent change was that somebody donated a CocoaPods spec for the project and thus forced me to give it a version number. The reason being that pods are usually pointing to a specific tag in a GitHub repository. This way people using the project via CocoaPods can be certain that they are getting a stable version.

So I stumbled into this, but when trying to think of a good version number I could only come up with “1.0.0”. DTCoreText has matured sufficiently to call it that. Hey, earlier versions made it into quite a few popular apps, including Float. There are tons of performance improvements, additional features and most importantly the parser has been replaced with libxml2. This makes it both faster and able to deal with any kind of HTML you throw at it.

DTCoreText has two parts: first it creates NSAttributedString instances from HTML, second it displays these properly. CATextLayer would be able to take attributed strings, but it ignores paragraph attributes and cannot draw images. DTCoreText  has an ingenious mechanism where you can supply your own UIViews for each attachment.

Attachments can be generic <object>s, <video>s or even <img>. DTCoreText takes care of the drawing and leaving some space and then tells you precisely the size you need to provide for your image views. Of course, if you don’t need any special treatments then images can also be drawn together with the text.

What is the connection between DTCoreText and DTRichTextEditor?

To make up a rich text editor you need multiple parts which are all in separate projects.

• To render the display: DTCoreText
• To accept text input, provide selection and show a loupe: DTRichTextEditor (which includes DTLoupeView)
• To copy and paste HTML: DTWebArchive

DTRichTextEditor is being sold for €500 and includes DTLoupeView priced at €150. You can also purchase the Loupe separately if you don’t want to full text editing, but just the magnifier.

Several people have asked me about the exact terms of these Non-Attribution Licenses. I introduced these as a way for developers to sponsor the ongoing development in exchange for not having to mention Cocoanetics in the app. You get a clear conscience and the good feeling to have supported something that saved you hours and hours of work. You get an invoice for your accountant so you can even expense this payment.

But I have no way of checking if you do adhere to the terms, or if you use the components without attributing them properly. Hey, it is YOUR KARMA. If my Open Source projects save you a single hour of development time, then the investment in this license should be easily worth it.

Of course I would be over the moon if somebody told me that he wanted to purchase 12 such licenses for 12 of his clients. Hey, do what you feel that is fair, ok?

If you do the math you’ll find that this is indeed a bargain:

DTCoreText … €75
DTWebArchive … €75
DTLoupeView … €150
DTRichTextEditor … €200

Something that you cannot get elsewhere … €500

Actually that gets me thinking, I should maybe increase the prices. I just convinced myself that this is all way too cheap…

DTRichTextEditor Updated, Too

Now with DTCoreText gone gold I also updated DTRichTextEditor to include all these great advances. The project too comes with a Demo app that shows how to interact with the component as well as demonstrates how to integrate the editor. The above mentioned components are sub-projects of this with the two Open Source ones being a clone of the GitHub repo on my Subversion server.

Technically the demo (or your own app for that matter) only needs to link in the libDTRichTextEditor static library and copy the DTLoupe.bundle (containing the loupe images) into the app bundle. If you inspect the Demo settings you see how this is done.

It is generally wise to add the items you need to the dependencies so that Xcode will know to refresh these if they are modified. In the linked libraries you see a heap of Apple frameworks and that we link in libxml2 as well as the static libDTRichTextEditor which aggregates the objects from the other three projects into one convenient library.

HINT: There is one (non-obvious) maneuver you have to know to be able to get a resource bundle created in a sub-project in the list of bundle resources. You need to expand the sub-project so that you can see the products group (yellow folder). Then choose the project root to see the targets. Finally drag the bundle product from the sub-project into the “Copy Bundle Resources”. Xcode is smart enough to know where to copy the product from.

With the above setup Xcode will build all necessary parts for the one or two necessary architectures and merge it all together nicely. For further tips regarding what you need to know when using Sub-Projects refer to my earlier article on Sub-Projects and Header Magic.

Conclusion

I happen to like the concept of self-contained pieces very much and what I learned over the past few weeks of how to do it right enabled me to use them in a large scale component as DTRichTextEditor, bringing together multiple bits and pieces.

Of course development will go on, mostly on the Open Source elements. And there are several items still missing that I am guilty of procrastinating. I want  to provide a time-limited binary version of the framework for testing and evaluation. There are many items on the to do list for DTCoreText itself. I need a better quick start guide to do justice to the dozens of users who are funding the development efforts. And there really should be some AppleDoc-style documentation.

While I do like writing, I don’t like writing documentation as much. So I’ll do that when I get around to it… 😉

Categories: Parts