When figuring out how to work with self-signed certificates and helping somebody debug an SSL problem I did a bit of research regarding the certificates being used on iOS and what functions are available to inspect these.
There are two functions provided to get more information from a SCCertificateRef , one to get a meager description, the other to get the entire certificate, encoded in ASN.1. But there you’re stuck, unless you want to mess with compiling and installing OpenSSL.
This is a hot fix release addressing several issues that users found. You now have a new option to decode unicode sequences with two backslashes on loading strings files or scanning source code. Decoding and Encoding of slash escapes now uses the functions provided by genstrings2.
Apple releases Xcode 4.3 and previews OS X 10.8 “Mountain Lion”. And how an Open Source initiative got “sherlocked” by Apple.
Podcast: Download (44.1MB)
While doing some performance tuning on the iCatalog.framework I stumbled upon a method of about 7 statements where a single line was responsible for more than a third of all CPU time.
This basically was only getting the path to the app’s Library/Caches folder. By itself this statement looks very innocent and I had it in about a dozen places all around the app. But it turns out that if you calling it hundreds or thousands of times then the time it takes to search for the Caches (and Documents) path sums up enormously.
Interestingly it does not seem like Apple implemented any caching for them so they seem to use around the same time all the time. But these values are prime candidates for caching because they won’t change while your app is running. Also the objc function call to get a cached version of the paths is several orders of magnitude faster than determining it in the first place.
ObjectiveSee is a web site dedicated to interviewing iOS developers. They use the format of a Q&A and they have several intriguing people’s up already: Justin Williams, Nathan Spindel, Keith Blount, Whitney Young, … oh and ME!
As a hobby project I am working on uncovering hidden treasures that exist on all your iOS devices. Hidden, because there is no Objective-C API for them, Existing, because Apple includes a great deal of open source libraries in iOS, compiled as a dynamic library.
What items exist you can see if you check out what dylibs are there to be seen in “Link Binary with Libraries”. Most entries beginning with lib and ending with dylib can be used. Some people have reported getting rejected for adding the static variants of libraries like libxslt or libarchive, but that’s probably because Apple sees these symbols as duplicate to the ones contained in the dynamic libraries.
We previously looked at libxml2 for parsing HTML (and part 2), today we’ll familiarize ourselves with zlib for decompressing .gz and .zip files.
I got a strange bug report last week for iCatalog. Deleting of outdated catalogs takes too long, if we couldn’t show a HUD with a spinner while the deletion occurs. That was definitely one of these HUUUUU?! moments. I always thought that file deletion is instant on Unix since only an entry in a file table needs to be removed.
I grabbed an iPad 1 and deleted a 160 MB catalog. Only to find that the whole deletion – a simple NSFileManager removeItemAtPath – took 50 seconds. Uhm, no that is far from ideal to be blocking the main thread and interface for that long.
I played around a bit and over the course of the day, with some great help from several GCD experts on twitter, I pieced together a solution that might interest you if you ever have to delete large amounts of files in an instant. Before Cocoa, on Carbon, OSX offered a method called FSPathMoveObjectToTrashAsync, this is sort of the equivalent for iOS.
Here’s another maintenance release fixing a crashing bug in the About section.
This update, like the one before it, goes out for the paid version of GeoCorder first. If the issues are resolved once this comes into the store then we’ll update the ad-sponsored version, too.
Update Feb 11th: The update has been approved.
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.
License:
