The sample apps I am making to accompany bug reports to Apple I generally create with a GIT repo behind them. I’ve gotten used to Xcode already creating a new repo when I start a new project, so why not make use of the GIT Goodness.
But when it then comes to attaching this project to a Radar I want the ZIP to be a small as possible. GIT provides several methods to achieve that.
An editor has to deal with the user hitting the tab key on an external keyboard and then be able to persist these tabs. Thus the question arose how I would best represent tab characters (\t) in HTML. At first I tried to encode them as 	 entities, but that is causing lots of trouble since on the parsing end it is difficult to know whether a tab came from this entity or if it came from the literal \t.
I could have done that with a very ugly hack of libxml2 (which powers my DTHTMLParser), but after having wasted half a day on this I relented. I previously reported my findings about Apple-converted-space which is the method NSHTMLWriter uses to preserve multiple spaces.
In this article I am documenting my findings related to how Apple conserves tabs for HTML output.
There will most likely not be an iWatch this year, the Pebble is what comes closest to it. It does have an internal ARM-based CPU and it can communicate with iOS devices over bluetooth. There are two kinds of of things you can build for it: watch faces (which don’t have any interaction) and apps.
For today’s project I want to try to put together a watch face that shows the WWDC 2013 Logo and a countdown to the keynote on Monday, June 10th.
Update June 2nd: I made the UTC offset changeable and released a build of the app via mypebblefaces.com
I have two vendor IDs, one from my time as Individual and the newer one since I changed to a Company developer account. There might be other other reasons for having multiple vendor IDs, if you know of any, please let me know. I’m curious.
Now for this week’s update to AutoIngest for Mac I wanted to turn the plain text Vendor ID field into a token field like the Mac mail app has. Fortunately NSTokenField exists on Mac since 10.4 and today we shall explore its use.
The Reachability sample is arguable the one piece of Apple sample code that is seen in most wide use. But it is just that: a sample.
It was lacking in some regards and so a plethora of variants popped up, all with varying version numbers. But all these version numbers do is to mask the fact that these are not “official” versions of sanctioned Apple code.
Yet another problem is that people needed to start prefixing their versions of Reachability as to avoid conflicts with other people’s Reachability contained in other components.
Today I learned that besides of using CocoaPods pod specs via the official repo, you can also use local clones of the source code as pods.
A client wanted to have a method for producing text that has a “cut out” effect, aka Text with “Inner Shadow”. Sort of like if you take a sheet of paper and then cut out the letters, then have light coming from up and slightly to the left so that it throws a shadow into the cut out letters.
For such a scenario you have to get a CGPath that is comprised of the glyphs that make up the text. Those are called glyphs because in some languages they are letters, but in some others they are not. Glyphs are the atomic element that any written language consists of.
Because it reasonably fits with the other work I have already done in DTCoreText I added such a method to both the classes for glyph runs as well as lines. These new methods will be released in the upcoming DTCoreText 1.5 release.
When we started with Source Code Management (SCM) – at the time – we still had a virtual Windows server running with QualityHosting.de. So a friend set up VisualSVN for us on this box. This got us started with Subversion.
A few years later I got started with git. Then I got into it a bit more with git submodules. Those were the beginnings of a beautiful friendship.
Two years later we decided that was enough of procrastrinating. Finally the time had come to switch to git for good. Read more
It happens to the best: you add new features to an app localized in several languages. You are not the lazy type that names the NSLocalizedString key’s the same as the English-language strings. Instead you name the keys semantically, like DOWNLOAD_ALERT_MSG.
Then when it comes to shipping you send the client a note that there are some new strings and assume that he will be able to find out which are new and need to be translated. Which he would if he was using a tool like Linguan. Which he is not, because you might have forgotten to recommend it to him, or if he’s extremely unlucky then he’s a Windows user.
For the DTCertificateViewer component that I am presently working on I needed to have a list of all known OIDs. Those are the tags (Object Identifiers) that identify the meaning of information encoded in CER/DER/ASN.1 files.
For example OID 2.5.4.6 means “Country Name”. I was able to glean a few dozen such identifiers from looking at a variety of certificates, but I couldn’t find a complete – and localized – list of those names anywhere online. Also Apple has registered a boatload of their own OIDs like “1.2.840.113635.100.6.1.2” = “Apple Developer Certificate (Development)”.
Since I’m building this component for use on iOS and Mac it became clear that I needed to go straight to the horse’s mouth to get my strings. In this article I am going to explain how I got my list of OIDs, in all 30 languages that OS X is localized in.
License:
