UIKit sets first responder to nil, making it impossible to send -undo: (and other actions) to appropriate targets

In our applications, we have an Undo button in our main view controller’s navigation bar. This button is supposed to do two things:

  • If there is a text field being edited, it should undo in the text field’s undo stack.

  • Otherwise, it should undo in the document’s undo stack.

Unfortunately, dismissing the keyboard clears out the window’s first responder, which means the -undo: message never makes it to the view controller.

[Read more…]

How I’d improve the UIScrollView.contentInset API

UIScrollView.contentInset is conceptually a very simple API: it extends the scrollable range beyond that implied by the contentSize property. (The objc.io magazine has a great article on UIScrollView that explains contentInset in terms of simple arithmetic.) Its two main use cases are avoiding the keyboard and correctly underlapping iOS 7+’s translucent bars. But if you want to get more complicated than a navbar and a keyboard, the simple nature of contentInset makes things difficult.

[Read more…]

WWDC Suggestions

If you’re going to WWDC, and prefer to avoid chain restaurants, Irish pubs, and Starbucks coffee, I’ve assembled a Foursquare list of personal recommendations. I might add to this list over time, so saving the list to your own Foursquare account will keep it up to date.

And if I personally know you, please friend me on Foursquare and share your suggestions with me. I’ll add your recommendations to my list of suggestions from others!

Seattle on a Sheet

It seems like @burritojustice‘s Islands of San Francisco map is flying around the ‘net. I just saw a retweet from Mike Jurewitz (aka @jury) that referenced it unsourced.

While his map is far more beautiful and informative, he credits me with inspiring him by producing a map I titled “Seattle on a Sheet.” I made this map in 2010, shortly after moving to Seattle, to help orient myself and flex my OmniGraffle skills. Unfortunately, all links to that file are now dead, as I’ve changed my online handle and web host since 2010.

Seeing that tweet spurred me to go looking for the original Seattle on a Sheet map, and after a brief trawling through Time Machine backups of a computer I’ve long since wiped and given to my mom, I found the map I thought was lost!

Here it is: Seattle on a Sheet.

edit: And now available in poster form from Zazzle!

My Email to Developer Programs regarding mandatory Apple ID password change

Every three months I’m forced to change my Apple ID password. This means remembering to update every single iCloud-capable device I own (currently six and growing); if I don’t, my shared info like calendars gets out of sync and I, being the forgetful person I am, miss events and information.

On top of that, the Dev Programs login forms all have a ridiculous onpaste attribute set so you can’t paste the passwords into the form. This means that on iOS I have to swap between 1Password and Safari to enter my password to log in.

I’m fed up with this stupidity. I just sent Dev Programs this nice little email:

When attempting to log in to the Developer Forums this morning, I was greeted with the all-to-common demand that I change my Apple ID password yet again. I find this demand infuriating, because I use a piece of software called 1Password to generate truly pseudorandom passwords. Every time I am forced to update my password, I have to then go around to every Apple device I own and update that password in all my iCloud account settings. If I forget a device, my calendars silently fail to synchronize and I miss important events. This is unacceptable.

But one of the other things 1Password does is allow me to copy and paste my cryptographically-secure passwords from the 1Password app into form fields. This makes generating and applying new passwords less painful. Alas, someone has made the decision that Apple’s developer login pages should prohibit pasting into the password field. This decision is not only the antithesis of Apple’s product ethos of setting up something correctly once and not having to modify it again, but actually decreases the security of the system. It discourages me from generating truly random passwords–instead, I must generate shorter, pronounceable passwords so I can remember them as I retype them. On the desktop, the 1Password Safari extension can modify the contents of the password field directly, but on iOS I have no recourse except to memorize and retype the password into the form.

This scheme is beyond user-hostile. It betrays extreme incompetence in that it actively encourages users to decrease the security of the system by encouraging the use of less cryptographically-secure passwords.

Again, so my message is crystal clear: forcing users to change passwords DECREASES the security of the system. Prohibiting users from pasting passwords into the login form DECREASES the security of the system.

Somehow, nobody else at my company is required to change their password on a regular basis. I am only aware of a few other developers that suffer the same counterproductive requirement to actively participate in harming the security of the ADC program. Not only do I want this ludicrous restriction lifted from my Apple ID, I want it lifted for EVERY other member of the Developer program.

UPDATE: Apple replied pretty darned quickly:

Thank you for contacting Apple Developer Support regarding Password requirements and restrictions. I am unable to change the password requirements and restrictions for your Developer Account.

We appreciate that you have taken the time to send us your feedback. Please be assured that all of your comments have been forwarded to the appropriate Apple team.

Race Condition when Moving NSDocuments to iCloud

Update: I just re-read a cocoa-dev post from last month in which Kevin Perry from Apple states the following:

I don’t see the nested uses of performSynchronousFileAccessUsingBlock: you mentioned in that code, but that’s not a problem anyway, since file access is recursive, as long as it happens synchronously within the outer-most file access block (a fact that admittedly may not be documented well anywhere).

That would certainly change things. Perhaps the reason that -relinquishPresentedItemToWriter: was deadlocking on me is because it calls -performActivityWithSynchronousWaiting:, not just -performSynchronousFileAccess? I’ll have to experiment.

Now that iCloud is out, I can finally talk about this in a public forum. Unfortunately, the cocoa-dev mailing list is down. But I really need to get this question out there, or at least written down, because it involves one of the most confusing new APIs in Lion: -[NSDocument performSynchronousFileAccess:] (or -performAsynchronousFileAccess: if you really hate your sanity).

[Read more…]