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.
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!
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!
I’ve uploaded my proposal for Objective-C namespaces to GitHub:
That will make it easier to track revisions and collate suggestions. If I ever have the time to work on a proof of concept implementation, I’d like to also add it to that repository.
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.
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).