Archive for December 2013
Tuesday, December 31, 2013
To see when AppKit is running different code because your app linked against an older SDK (via Ken Ferry):
defaults write bundle-id NSLogUnusualAppConfig -bool YES
To slow down table view animations (via Uli Kusterer, documented in the 10.9 release notes):
defaults write bundle-id NSTableViewSlowMotion -bool YES
To show the Debug menu in Notes (via Nicolas Seriot):
defaults write com.apple.Notes showDebugMenu 1
To show the Debug menu in Calendar (via Nicolas Seriot):
defaults write com.apple.iCal CDB 1
Calendar Cocoa Debugging Esoteric Preferences Mac Mac App Mac OS X 10.9 Mavericks Notes Programming
Sunday, December 22, 2013
Frank Chimero’s
Kickstarter-funded book
The Shape of Design is back in print (via
Matthew Guay):
The Shape of Design isn’t going to be a text book. The project will be focused on Why instead of How. We have enough How; it’s time for a thoughtful analysis of our practice and its characteristics so we can better practice our craft. After reading the book, I want you to look at what you do in a whole new light. Design is more than working for clients.
But really, this book aims to look at the mindset and worldview that designing develops in order to answer one big, important question: How can we make things that help all of us live better?
It’s also available for free in various e-book formats.
Book Design
Eastgate:
These are programs with attitude, with fresh ideas and exciting new approaches. Small teams work every day to polish and improve them. If you have a question or need something unusual, you can talk directly to the people who handcraft the software.
They’re offering a 25% discount on some great Mac apps. I think we’re in a renaissance for writing and information apps, but where is the Nisus Writer of spreadsheets?
Bargain Mac Mac App
Saturday, December 14, 2013
For the first six weeks or so, my experience was that Touch ID worked pretty well for a day or two, and then the accuracy rapidly declined. After a few days, it would more often than not fail on the first attempt. Several times per day, it would fail five times in a row, so that I would have to type my passcode.
I tried cleaning the Touch ID sensor. I tried retraining it many times, using different fingers, different parts of the fingers, multiple copies of the same finger, etc. Nothing seemed to help.
Because you can’t have a passcode delay when using Touch ID, this made Touch ID much more trouble than it was worth, so I turned it off for several weeks. The iPhone was immediately more pleasant to use.
A couple weeks after updating to iOS 7.0.4, I decided to give Touch ID another try. I trained it with four versions of my right thumb. I had tried this before, but this time it worked. Over the last nine days, I have unlocked my phone probably at least 200 times, and Touch ID only failed twice. The two times were consecutive. I had just entered a building after being outside without gloves, and so my fingers were cold; I’m not sure whether that has anything to do with it.
I’m not sure whether the improvement is due iOS 7.0.4 or happening on a more effective training. In any case, 99% accuracy makes a world of difference. Before, I had dreaded unlocking my phone because I expected it to fail, and fail, and fail. Now I just assume that it will work. And it’s worked through dry skin, sweaty hands, slightly dirty hands, lotioned hands, etc. It even worked, sideways, when my phone was in a car mount, and swiping and typing the passcode would have been awkward.
iOS iPhone iPhone 5s Touch ID
Monday, December 9, 2013
Peter Steinberger has a good survey of the Cocoa collection classes, with some interesting performance information:
Notice that NSPointerArray
requires more than 250x (!) more time than NSMutableArray
. This is really surprising and unexpected. Tracking memory is harder and it’s likely that NSPointerArray
is more efficient here, but since we use one shared instance for NSNull
to mark empty objects, there shouldn’t be much overhead except pointers.
[…]
The eviction method of NSCache
is non-deterministic and not documented. It’s not a good idea to put in super-large objects like images that might fill up your cache faster than it can evict itself. (This was the case of many memory-related crashes in PSPDFKit, where we initially used NSCache
for storing pre-rendered images of pages, before switching to custom caching code based on a LRU linked list.)
Not in the article, but related, is Charles Parnot’s recent observation that the Mountain Lion release notes warn against using +[NSMapTable weakToStrongObjectsMapTable]
:
However, weak-to-strong NSMapTables are not currently recommended, as the strong values for weak keys which get zero’d out do not get cleared away (and released) until/unless the map table resizes itself.
Update (2013-12-09): NSMapTable
is an important building block, so it’s a mystery to me why Apple hasn’t gotten it right yet. It seems like it would be straightforward to implement clearing of the values using associated objects. Perhaps Apple is waiting until true weak-deallocation notifications are added to the runtime?
Cocoa iOS Mac Memory Management Objective-C Programming