One of the takeaways from WWDC should always be a renewed promise to yourself and Apple engineers: “File better Radars”. With some time at my hands jettting back over the Atlantic Ocean, I prepared a demo project and the text for my latest filing.
By now it is public knowledge that there will be no in-house replacement for routing via public means of transport in iOS 6. Indeed if you hold an iOS 6 phone (that somebody maybe has left in a bar) and you try to plan a route from point A to point B you find that you can drive there quite nicely with turn-by-turn in 3D. You can walk there. Or you can get forwarded to a – currently empty – section that supposedly will show a list of transit apps to take on the routing.
I have some personal experience with that to share which might also underline why this move by Apple is actually the only reasonable one.
The last day at WWDC is almost only a half one since there is no structured program after the lunch-time talk. I attended a killer-design-talk that explained some of the design processes that Apple went through when designing the revolutionary interface for iPhoto for iOS. That was awe-inspiring because gave us many pointers on how to approach designing ups more like they do at Apple.
By the forth day I found a certain sorrow creep into my consciousness. Only one more day to go after this one I kept thinking. And even more I am beating up myself not having heeded my own advice: prepare better for the labs. There are a couple of things that I found are beneficial when going to the labs, so I want to write them up here so that I might keep them in mind.
By day 3 I think I can say that I’m getting into the flow of things at WWDC. That is mainly achieved by not queueing for overrun talks. Or by finding better uses for your time, as I keep preaching, by finding Apple engineers to talk to.
Though I am also mildly disappointed, but not in the program or people, but in myself. I did not heed my own advice of preparing some code to discuss with the Apple guys. Even my partner from Arizona did that, although programming is not his bread and butter. I admit to being proud of this.
I had to clone some source code from my repository to have something to base my questions on. So the rule “bring code” can be bent ever so slightly. It also counts as “bringing” if your code resides in an Open Source repo on GitHub or on your private SCM.
I saw a certain category of tweets appear since monday that all were following the same pattern. They were about what the user thought the greatest new feature in iOS 6 was for him. So I did a search and found that there are many different signs of whimsy and delight.
On the second day you have probably acclimated to the flow of things. Or rather, the traffic jamming of things. Because queue you will, queue you must. Wherever you go there will be a queue.
You’ve probably seen the Keynote, by now it is available as video for you to enjoy. One thing that I noticed quite a bit was that Apple apparently has expanded their assimilation process. Resistance is futile!
I am extremely confident that Apple will introduce the ability to set blocks as actions for UIActionSheet (and UIAlertView) in iOS 6. Still, for exercise and because I want to support iOS 5 until iOS 6 is actually released, I set out to implement that.
When I tweeted about it, several people pointed me to existing implementations:
- Gustavo Ambrozio’s BlockAlertsAnd-ActionSheets
- Zachary Waldowski’s BlocksKit
- Yuri Kotov’s ADVAlertView-Blocks
- Mugunth Kumar’s UIKitCategoryExtensions
So I could have used one of these. BUT I like to understand the code I’m using and also I’m still learning, so better to solve the problem myself and talk about it. Also there are some implementation choices that I don’t agree with on these projects.