Comments for Vincent Gable's Blog

Comment on NSXMLParser and HTML/XHTML by Anonymous

Anonymous — Wed, 17 Mar 2010 19:41:03 +0000

I too saw this behavior. I was converting my string using
string = [string stringByReplacingOccurrencesOfString:@"" withString:@">"];

But when the xml attribute value consisted of html tags such as adsfasd the NSXMLParser failed.

Comment on Ignoring Just One Deprecated Warning by Des Courtney

Des Courtney — Fri, 26 Feb 2010 11:03:51 +0000

Thanks for allowing me to keep -Werror turned on!

(I’d have used Twitter, but my account’s private and you wouldn’t have seen the message…)

Comment on Prefer copy Over retain by Bo

Bo — Sat, 13 Feb 2010 03:27:51 +0000

About the “A Sneaky Bug Too”, I tried this:

[immutableString isMemberOfClass:[NSMutableString class]]

and it is NO.

So I guess we can use “isMemberOfClass” to make sure that the Object is not a subclass, in case we know which subclass we will be worry about.

Comment on Detecting if Headphones are Plugged In by Joerg Lange

Joerg Lange — Sun, 07 Feb 2010 19:36:20 +0000

AudioHardwareGetProperty and AudioDeviceGetProperty works not in snow leopard, since I have some probs understanding coreaudio framework; are there any workarounds ?

Comment on Point Of View is 80 IQ Points by Vincent Gable

Vincent Gable — Thu, 04 Feb 2010 04:12:59 +0000

I really can't do a good job, any job, of explaining magnetic force in terms of something else you're more familiar with, because I don't understand it in terms of anything else you're more familiar with.

Comment on Mutable @property and Copy Gotcha by Bob Donovan

Bob Donovan — Fri, 29 Jan 2010 16:31:42 +0000

Thanks for the tips you saved me hours of frustration.

Comment on memcopy, memmove, and Speed over Safety by Santiago

Santiago — Thu, 21 Jan 2010 04:10:10 +0000

If memory areas don’t overlap memmove should be just a call to memcpy, so both calls would have the same performance. Otherwise the compiler / standard libraries aren’t optimized. But if both memory areas overlap, memmove would have to copy the memory backwards, which is always muuuch slower (memory caches and other parts of the hardware aren’t optimized for that, and there is nothing we can do about that). However, as you said, memcpy could destroy the data, and that’s not a viable option.

In summary, memmove and memcpy should be equally faster (otherwise, use another implementation), the overhead of testing if memory overlaps is negligible (but memmove can’t never be faster in real scenarios). So I agree, memmove should always be used preferably over memcpy.

Comment on Splash Screens Are Evil by Vincent Gable

Vincent Gable — Tue, 19 Jan 2010 17:41:39 +0000

spinyanteater,

I’d rather stare at an attractively designed splashscreen for those few moments than an unresponsive menu screen.

I totally agree there! But I see it as a "lesser of two evils" kind of fix -- a hopefully temporary solution. Ideally it's possible to come back later and optimize loading time to the point that it isn't unresponsive. But of course this isn't an ideal world. it's not possible to solve every problem. Some apps need 3-5 seconds to start up on a phone — in that case, some kind of splashscreen is a necessary evil. For what it's worth, I've read that a "loading" screen (showing a static UI + a spinner) can work better than a static splash screen.

So I did some user testing. Everybody I tested it on said that the 3.5 second launch time with the loading screen was faster than the 3 second launch time with just the plain splashscreen, so it was clear that was the way to go.

--James Thomson, How To Make Your iPhone App Launch Faster But if a pretty-logo splash screen tests better for your users, then clearly it's the way to go! Maybe it's breaking the HIG, or "best practices", but it's justified with real evidence.

Comment on Splash Screens Are Evil by spinyanteater

spinyanteater — Tue, 19 Jan 2010 10:02:44 +0000

Our first app followed the HIG guidelines and dutifully used a screenshot of the main menu screen as the splashscreen. The app loaded quickly and in testing it seemed to work fine. But customers didn’t like it. As you say, we want to use an iPhone app as soon as we open it and that means we are tapping away at the screen as soon as we have finished tapping the icon to open it. The result is that nothing happens and we have to tap again. Our customers found this irritating. We changed the splashscreen to a logo which disappears as soon as the first xib file has loaded and our customers are happy.

My point is that, used properly, splashscreens are a good thing. You can’t use the app before it loads whether the splashscreen is there or not, and the splashscreen gives visual feedback that the app is still loading. I’d rather stare at an attractively designed splashscreen for those few moments than an unresponsive menu screen.

Comment on Automatically Freeing Every @property by Pierre Bernard

Pierre Bernard — Tue, 12 Jan 2010 23:11:08 +0000

I offer a variation on the above technique. Rather than calling the setters, I release and nil the variable used for storage.
http://bernard-web.com/pierre/blog/index.php?id=2624434753771423706