Terry Blanchard

Accessibility is one of those areas that most software engineers and product teams seem to have little or no knowledge of. When it is brought to the attention of the decision makers, I’ve heard all too often, “We’ll do that if we have time at the end of the project” or, “What is that? Why do I care about it?” What’s worse, is that in the eyes of many companies and project leads, they can easily rationalize to themselves why accessibility shouldn’t be included in the development cycle:

“Why would a blind person own a touch screen device?”

“I think you’re solving a problem that doesn’t exist.”

“That’s not our target demographic.”

“I can’t see how this would improve our App Store ratings.”

“QA doesn’t know how to test it.”

It’s really sad. Especially when Apple has made it so incredibly simple for us to implement. They’ve done all they heavy lifting for us and simply said, “Carry the baton across the finish line. Please.” And most of us drop the baton.

Honestly, it takes minutes to make your application accessible to a population that all too often gets the shaft. I am a fan of Matt Gemmell. Everything from his tweets to his blog. Even if you’re not a fan, I implore you to read just one article. It’ll make you a better software engineer, and you’ll make your software usable to an audience that seems to lack a voice.

See Matt Legend Gemmell’s article:
http://mattgemmell.com/2010/12/19/accessibility-for-iphone-and-ipad-apps

John Gruber of Daring Fireball quoted this article as:

Must-read for developers. Both a good high-level overview of what accessibility really means and who it helps, and a technical overview of how iOS developers can take advantage of it. iOS is simply leaps and bounds ahead of the competition in accessibility.

Written by Terry Blanchard \\ tags: Accessibility, Development, Interface Builder, iOS, Usability, Xcode

Everyone has their own vision of how things should work. As you gain more experience in your craft, you become more grizzled. Well learned. After some time, you earn the privledge of passing this experinece on. Oscar Wilde said it best:

Experience is simply the name we give our mistakes.

Multi-threading in software engineering has been around for a long time. Many mistakes have been made, thankfully. From those mistakes, experience was born. Most of the engineering books talk about the essentials, and the dangers that must be respected and adhered to. But while they talk about the pitfalls of what could happen, none of them really give you great guidelines. I’ve been doing this a long time and I’ve worked with people who should not have made some of the mistakes I’ve witnessed.

Are they bad engineers?
No.

Was there a fundamental misunderstanding about multi-threading?
No.

But there are some fantastic guidelines that aren’t well-established. It seems like Brent Simmons and I agree on a lot of the same principles. He’s written a great blog post about Cocoa Threading that every Cocoa developer should read and understand. He refers to his post as his, “barely-organized thoughts on threading and Cocoa applications” but it covers the points in a concise manner.

Thread Communication Exclusively on the Main Thread

First up is his philosophy on all communication between threads taking place on the main thread. He extends this to notifications as well. I’ll add one more to that list which is KVO notifications. This is essential because UIKit and Core Data don’t like operating on secondary threads. I don’t know how many times I’ve seen

 go off because I received a notification or call from a secondary thread.

Communication between systems always happens on the main thread. (A system is one or more objects that work together.) In most cases, communication between objects in the same system happens on the main thread too.

If an object does something in the background, that is that object’s business and nobody else’s.

This extends to notifications: from background threads, I always make sure notifications get posted on the main thread. This way every notification observer can always assume that it’s getting called on the main thread.

Regarding KVO, Brent has this to say:

KVO is a trickier thing. Here’s how I handle that: anything happening in a background thread is not observable (by convention). Whatever is going on is private. When it’s time to set public stuff, stuff that could be observed, those things are set on the main thread.

Threading Methods

There’s almost as many different ways to spin off a thread as there are people in the United States. Brent and I also agree on which methods we use:

I’m very deliberate about my threading. I like Grand Central Dispatch, but for my purposes NSOperationQueue works best. The formal, easily-monitored approach of NSOperationQueue works best here. I definitely recommend against anything but GCD and NSOperationQueue — anything else (NSThread’s detach method, etc.) is too random. (Yes, we used it for years, but we have better stuff now.) (In fact, I almost never even use NSInvocationOperation — I much prefer the structure and defined stop/start of NSOperation.)

I use an NSOperation subclass that takes a target and selector in its init method. When it’s finished, it calls the target and selector on the main thread. This way the caller only ever sees the main thread — it creates the operation on the main thread, then gets called back on the main thread. The fact that the operation happens in the background is unknown to the caller: the caller just knows that it’s async, and doesn’t know anything else.

I almost exclusively use NSOperation subclasses with NSOperationQueue in my applications for the same reasons that Brent outlines. You can create multiple NSOperationQueue’s if you need different operating parameters (for example, one queue that is sequential, another queue that can operate concurrently). Making dependencies between various NSOperation’s is as simple as making an addDependency call. Plus, they can have dependencies across different NSOperationQueue’s.

Locking

NSCache seems to have suffered from poor marketing. It’s a little gem that very few people seem to know about. I’ll bet most of you have written your own class that performs much of the same functionality. I’ll take the very-well tested and used NSCache, which is also thread-safe, any day.

Locking sucks. If you have to do it, you have to do it. It doesn’t mean you’ve failed — failure would be not-locking when you really do need a lock.

There are a couple other things you can do which make sense.

1. Use performSelectorOnMainThread to set some data that would otherwise require locking. (This is not a trick to use willy-nilly, though — typically it comes at the very end of an operation, not sprinkled throughout.)
2. Use NSCache — it’s thread-safe.

I highly recommend you read Brent’s full article, “Some Notes on Threading” over at his site.

Written by Terry Blanchard \\ tags: Cocoa, CocoaTouch, Development, iOS, Locking, Mac, NSCache, NSOperation, NSOperationQueue, Threading, Xcode

I’ve been seeing a lot of iPad usage around me. I know what you’re thinking, “Duhhh, Captain Obvious! You live in Silicon Valley and this is where Apple is headquartered. Yeah, I think you might see a few.”

Silicon Valley is loaded with top-tech talent. Devices and gadgets that only the top-talent stereotypes understand and thrive on is abundant around me. I don’t even blink an eye when I see Segway zooming by with a laptop strapped to the handle bars, touring it’s driver around the city while their Bluetooth stereo headset is connected to their smartphone, providing the audio portion of the tour, while also feeding directions to the Segway via it’s GPS.

Just another day in Silicon Valley.

There’s something different about these iPad sightings. One that pleasantly captivated my eye and brought a huge smile to my soul. These sightings didn’t involve your typical Silicon Valley geek. In fact, the stars of these sightings are usually the last people you would expect to see or ever associate with the word, “technology.”

And I love it.

I was having lunch with a colleague and noticed an elderly gentleman, well into his eighties, sitting at the bar with a Martini in one hand while streaming some NetFlix videos to his iPad laying down on the bar.

Is streaming new?
No.

How about the ability to watch videos on a computer, is that new?
No.

The type of person performing this task was.

Apple has done something magical here with the iPad. They bridged what many would say was an impossible chasm. All joking aside, we do everything we can to minimize the technology in the lives of the senior citizens closest to us. The remote control for the television can instill the fear of God into them when they’re looking for the volume or channel button amongst the 40 or 50 buttons on the remote control. DVR? Don’t waste your money, they’ll never use it because it’s a foreign and complicated mental model for them.

Another sighting. At my gym I saw an elderly lady on the treadmill reading a book. Not just any book. Her iPad was sitting in front of her with the Kindle application running and the font size was probably set at 96 points as I read along with her from the other side of the gym.

Watching these people use their iPad I didn’t see the awkwardness and hesitation you normally see from them when using a laptop or desktop computer. They were, dare I say it, “at ease” with it.

Why is that?

All of the typical items that frighten senior citizens who are new to using computers are not present with an iPad. Let’s start with the mouse. My mother won’t even try to use a computer because of the mouse. She couldn’t comprehend or understand what to do when the mouse reached the end of the mouse pad, but her cursor was only halfway across the screen to her destination. She didn’t make that mental connection between what was happening onscreen versus what the device she was directly manipulating had on one another. When I told her to pickup the mouse and move it back to the other side of the mousepad, she just stared at me blankly.

“Well, if I move the mouse it will move the doo-hickey thing on the television screen and I’ll be back in the same position.”

“No, Mom. That will only happen if the mouse is touching the mouse pad. You can pickup the mouse and if it’s not touching the mouse pad, the sensor on the bottom of the mouse won’t detect the movement and therefore won’t move the mouse on the screen so you can move the mouse without moving the cursor … never mind, just trust me.”

What we take for granted is pure magic to them. It’s a mouse for us, but it’s a 747 flight deck to them.

Removing that middle-man translation and adopting the touch screen is much easier for them to understand. Want to launch email, just tap on it with your finger. Done. They get that. That makes complete sense to them.

Another reason is software installation. The App Store on an iPad compared to shopping and installing software for a typical computer is night and day. Easy access to the App Store, seamless purchasing and installation without introducing more confusing questions and concepts such as, “Where on your hard drive do you want to install this new fancy software?” or “Make sure you have enough hard drive space on the destination drive before proceeding?” mean nothing to them.

App Store, tap to buy, screen automatically moves to the new application icon that is installing. Tap to open. They can do that. They get that. That makes sense to them.

And to get them started, you should pick up a copy of iPad For Seniors For Dummies for them.

Written by Terry Blanchard \\ tags: Apple, iPad, Senior