Ah yes, the famous 1.1.1 version of a new app… You know, version 1.0 is always the minimally viable product. Version 1.1 lets you add new stuff that didn’t make it 1.0. And version 1.1.1 then is another layer of polish and tweaks.
Urban Airship Commander is dear to our heart and so it also deserves the benefit of a 1.1.1 version.
I remember a long time ago when CPUs still had only a single core and the chip manufacturers where racing for getting the highest Gigahertz. Then some technical limit was reached they shifted their philosophy to increasing the number of CPU cores. The unfortunate side-effect of this approach is that we developers need to adapt our code to make use of these multiple cores or else our CPU-intensive code will find a bottle neck in being only able to max out one core.
In a previous article I described how optimizations in genstrings2 (our Open Source replacement for genstrings) led to the re-implementation being upwards of 30 times faster than the original.
The reason of this was mostly grounded in some smart using of multiple GCD queues. In this blog post I shall explore how we can get DTCoreText to also make use of all available CPU cores.
After several fellow developers reported that they where unable to compile their apps having followed the previous DTCoreText Readme I felt that I needed to create a new Setup Guide. So I did that for the better part of a day, painstakingly verifying each individual step and documenting how the recommended approaches would be.
I used a relatively new feature of appledoc to create Programming Guides which allows to add markdown files that get transformed the same way to HTML as the header comments are.
You can also add images and cross references, which unfortunately seem to have a mind of their own. But I finally found a way how to get it what I wanted it to do and you can see the results online.
Our partner has begun rolling out the latest generation of iCatalog+ apps which marks the third generation of our framework. The 3rd generation will also celebrate the 3rd birthday of our iCatalog.framework. Initial development had begun in Summer 2010 with the first public release occurring in October 2010.
In DTCoreText there is the DTCoreTextParagraphStyle class which represents an Objective-C wrapper around CTParagraphStyle. This has a method createCTParagraphStyle which creates the actual Core Text object to put in attributes of an NSAttributedString. It also knows how to create an NSParagraphStyle, but since this only exists from iOS 6 upwards and lacks a few features we’re still using the Core Text variant everywhere.
Due to the way how DTCoreText works I need to createCTParagraphStyle whenever I am constructing a sub string of the generated attributed string. This led to an unnecessarily large amount of CTParagraphStyle instances being created. So I had implemented a method long time ago to cache thusly created CoreText objects based on the ivars.
Though this was causing some problems in DTRichTextEditor and so I yanked the caching back out. Now the project has developed much further and so I felt I would want to give the caching another go. Here’s something interesting I learned.
In the past most of my components where first developed for a need that either we had for our own apps for for a client. With the new DTCertificateViewer I want to try something new: Request for Comments (RFC).
Historically those RFCs are the documents that describe how everything on the internet works. But I see no reason why we couldn’t use the term as well to use it what the name describes, namely soliciting comments about the usefulness of an idea.
The current c’t computer magazine has a short snippet mentioning the hybrid iPhone/iPad app we’ve been developing for ELO Digital Office GmbH.
If you come to CeBIT please pop by ELO’s booth at hall 3, F30 to give the app a whirl. Doing so you can do us a favor if you keep mentioning how much you like the slick UI.
This is a feature request for something that could have used just yesterday. Filed as rdar://13271368 and on Open Radar.
Update: I was made aware by an Apple engineer that Xcode is indeed already autosaving versions of your files as you make changes. Versions is an OS X feature. But there is no Revert menu option in Xcode to access these saves. As a workaround you can open the source file in TextEdit and do the reverting there! A hidden feature that is so well hidden, it’s even in a different app!
It’s been a while since I last blogged about the progress we are making on DTRichTextEditor, my rich text editor component for iOS. January saw many more licensees that ever before, people are just fed up with not being able to integrate rich text editing into their apps.
Selling many licenses also allows me to dedicate a great deal of time to improving and tuning the component. Now here is Version 1.2.
In my previous article dealing with Multi-Context Core Data I introduced a 3-context scheme that Marcus Zarra hat shown us in a back room at the 2012 NSConference.
Several people inquired about Locking, take for example Wim Fikkert:
Thanks for the great article. However, like Tom, I was wondering if the main context will not be blocked whenever you perform a save to disk with the persistent store. I am using the last design pattern, and I keep running into my app locking up. I have done some more searching and came across this article. Perhaps you can comment?
I don’t pretend to come anywhere close to being the Core Data expert that Zarra is, so I went straight to the horses mouth and asked him.
License:
