Vincent Gable’s Blog

October 22, 2009

iPhone Shows the Irrelevance of the Programmer User

Filed under: iPhone,Usability | , , , ,
― Vincent Gable on October 22, 2009

There’s a lot of discord over Apple’s draconian “closed” handling of the iPhone and App store. And rightly so. But there are a few interesting lessons in the current situation. The one I want to discuss now is that,

Being able to program your own computer isn’t enough to make it open

As things stand today, Apple can’t stop you from installing any damn iPhone app if you build yourself.

To do that you have to join the iPhone developer program of course. And there’s a $99/year fee. That’s inconvenient, but it’s just using a subscription-based way of selling iPhone OS: Developer Edition.

That’s the kind of dirty money-grabbing scheme I’d expect from Microsoft. It’s a bit shady, because it’s not how most OSes are sold. But it’s not without precedent. And unless you are against ever charging money for software, I don’t think there’s an argument that it’s actually depriving people of freedom.

Yes, it’s an unaffordably high price for many. But the iPhone is a premium good that costs real money to build — it’s inherently beyond many people’s means, even when subsidized.

Observation: Only Binaries Matter

If you have a great iPhone app that Apple won’t allow into the store, you can still give it to me in source code form, and since I have iPhone OS: Developer Edition, I can run it on my iPhone.

But clearly that’s not good enough.

In fact, I’m not aware of any substantive iPhone App that’s distributed as source. By “substantive” I mean an app with a lot of users — say as many as the 100th most downloaded App Store app — or an app that does something that makes people jealous, like tethering (See update!), which we know is possible using the SDK. I realize this is a wishy-washy definition — what I’m trying to say is that distributed-as-source iPhone Apps seem to be totally irrelevant.

“It’s not open until I can put Linux on it”

I believe it’s technically possible to run Linux on an iPhone without jail-breaking it. (Although it’s not terribly practical.) Just build Linux (or an emulator that runs Linux) as an iPhone app, and leave it running all the time to get around the limitations on background processes.

Apple won’t allow such a thing into the App Store of course —but how does that stop you from distributing the source for it? As best I can tell, it doesn’t.

So as things stand today, yes you can distribute source code that lets any iPhone OS: Developer Edition user run Linux. It’s technically challenging, but it’s doable.

Conclusion

It’s possible to build open systems on top of closed systems. We’ve done it before when we built the internet on Ma Bell’s back.

But the iPhone remains a closed device. User-compiled applications have 0 momentum. And I think that clearly shows the irrelevance of the rare “programmer user”, who is comfortable dealing with the source code for the programs he uses.

UPDATE 2010-01-21: iProxy is an open-source project to enable tethering! Maybe the programmer-user will have their day after-all.

October 12, 2009

Don’t Check malloc()

Filed under: C++,Cocoa,iPhone,MacOSX,Objective-C,Programming,Quotes,Tips | , , ,
― Vincent Gable on October 12, 2009

There’s no point in trying to recover from a malloc failure on OS X, because by the time you detect the failure and try to recover, your process is likely to already be doomed. There’s no need to do your own logging, because malloc itself does a good job of that. And finally there’s no real need to even explicitly abort, because any malloc failure is virtually guaranteed to result in an instantaneous crash with a good stack trace.

—Mike Ash

This is excellent advice. Peppering your code with if statements harms readability and simplicity.

It’s still a good idea to check large (many MB) mallocs, but I can’t imagine recovering gracefully from a situation where 32 byte memory allocations are failing on a modern desktop.

October 6, 2009

‘Yum!’

Filed under: Design,iPhone,MacOSX,Programming | , , , , ,
― Vincent Gable on October 6, 2009

I give Microsoft’s current Mac software some shit, but I think it’s deserved. So it’s only fair I mention their glory days.

From “Classic” Mac OS 8.1 in 1998 through Mac OS X 10.2 Microsoft’s Internet Explorer (for Mac) was the default web browser Apple chose for Mac OS. The very fist iMac? It came with IE:mac, just like the first version of Mac OS X.

And IE:mac wasn’t so bad, for it’s era. (It was the first browser to have color correcting PNGs, by the way!) There was one really neat feature that I think is worth calling out: it would match your iMac’s color, automagically.

Technical Details That I Only Half Remember

If you have a better understanding of how this worked, please let me know! I couldn’t find any details online. Mostly, I’m writing down what I remember before I forget.

The poorly named Gestalt function lets you check information about the Mac OS runtime, like “what version of Mac OS is this?“. You pass it a FourCharCode, and replies with a 32-bit value or an error code — old stuff from the “Classic” Mac OS days.

There was an undocumented code, 'yum!' 1, that returned the color of an the iMac or iBook case. IE:mac would check this when it first started, and choose a color scheme to match the operator’s Mac. It was a seamless personal touch that really impressed me.

It’s the sort of thing I’d like to see more of on today’s multi-colored iPods and iPhones.

1It might have been 'Yum!', I don’t remember exactly, and Gestalt() returns gestaltUndefSelectorErr, -5551, for all of variations on my MacBook Pro under Snow Leopard.

August 27, 2009

Prometheus 1.0 Released!

Filed under: Announcement,iPhone | , ,
― Vincent Gable on August 27, 2009

My first iPhone app is in the iTunes App Store!

PrometheusLogoChrome.png

Prometheus

App_Store_Badge_EN.png

There are many apps for reading Wikipedia. Prometheus is different. It’s an editor for the Simple English Wikipedia

Simple English Wikipedia is like regular English Wikipedia, but it’s written with simple words and grammar, so kids and non-native speakers can easily grasp it.

Features

  • Shake for a random page
  • Or search and browse with purpose.
  • All articles are formatted for iPhone.
  • Tap the words you want to change to start editing.
  • Landscape keyboard support for easy typing.
  • Unfinished edits are automatically saved for later.

Simple Wikipedia makes a complex world comprehensible. Use it to teach what you know to someone who wants to know it.

Download from the iTunes App Store

August 19, 2009

iPhone Password Correction

Filed under: Accessibility,iPhone,Security,Usability | , , , ,
― Vincent Gable on August 19, 2009

Idea: your iPhone knows your passwords, so when you make a small typo, it corrects it for you.

There are obviously major security concerns here. But I believe they can be acceptably mitigated by the phone itself. Someone would have to physically use the iPhone to get password correction, and correctly could only happen on the first or second password attempt. Also, correction could be limited to the kinds of typos a person would make.

Passwords are broken by machines, not people. I believe password correction can help people, without substantially helping machines, and compromising security.

It’s hard to type precisely on an iPhone’s virtual keyboard. That prevents people from using secure passwords, and that hurts security. Because password correction helps people actually use strong passwords, it should be to be a net security benefit.

July 19, 2009

For iPhone and or iPod Touch and or Other Things As Well

Filed under: Announcement,iPhone,MacOSX | , , , , , ,
― Vincent Gable on July 19, 2009

It’s very clear that a program “for Mac OS X” works with any personal computer Apple sells, because they all have “Mac” in their name. Unfortunately, the flavor of OS X that runs on the iPhone and iPod Touch is officially called “iPhone OS” by Apple, which it implies an incompatibility with the iPod Touch, and any future device that doesn’t have “phone” in the name.

I don’t know a good way to unambiguously say that a program is for any iPhone OS device, without tedious enumeration.

“For iPhone OS” sounds like it excludes the iPod Touch.

“For all models of iPhone and iPod Touch” sounds terrible. It will sound even worse when Apple comes out with other iPhone OS devices (“…for iPhone or iPod Touch or iTablet or iFPGA…”).

Apple could help by renaming “iPhone OS” to “Mobile OS X”, but I don’t see this happening.

I personally lean towards using “for iPhone” in general writing, and clarifying, if necessary, in “systems requirements” fine print. This feels closest to how the press covers iPhone OS applications, and of course it’s how Apple named the OS.

I’d love to hear what you call iPhone OS applications, and why.

June 15, 2009

Ignoring Just One Deprecated Warning

Filed under: Bug Bite,C++,iPhone,Objective-C,Programming,Tips | , , , , ,
― Vincent Gable on June 15, 2009

Switching projects over to iPhone OS 3.0 means discovering that functions I’m using are deprecated. Occasionally there isn’t a totally straightforward replacement, and the best thing to do is to file a bug/TODO/note for myself, and ignore the warning until a later version, when major refactoring will be possible. But bitter experience has taught me to have Xcode treat warnings as errors1, so it’s necessary to trick the compiler into ignoring the warning for things to build.

-Wno-deprecated

The -Wno-deprecated flag tells GCC to suppress warnings about deprecated code. But adding it to an Xcode project means you won’t get useful warnings about other depreciated code.

You could file a bug telling yourself to turn that warning back on after the deprecated functionality has been updated. That should work just fine. But it feels like bad project hygiene to me.

Casting and Protocols

Type casting is a dangerous old-C technique that’s earned its infamy. But it’s undeniably fitting to use a deprecated language feature to get deprecated code to build. The basic idea is to declare a protocol that includes the method you want to suppress warnings for,

@protocol DeprecatedHack
- (void) myDeprecatedMethod;
@end

then just cast your objects so the compiler thinks they implement the protocol,

[foo myDeprecatedMethod]; //warnings
[(id<DeprecatedHack>>)foo myDeprecatedMethod]; //no warnings

Although having to declare a protocol is somewhat heavyweight, it leaves a nice artifact in the code reminding you to replace deprecated functionality.

Protocols Not Required

Sometimes just casting to id is enough. This happens if another object has a non-deprecated method with the same name.

1For experimental or prototyping projects I let warnings slide. But in the main project I always treat warnings as errors. Ignoring them in production code has never worked — warnings fester and grow on each other.

Because Objective-C is so dynamic, there are many errors that the compiler can warn you about, but can’t be totally sure are errors. For example, methods can be added to a class at runtime, so if you call -someMethodThatDoesNotExistAnywhere, the compiler will warn you that something is up, but won’t stop the build, because the necessary code could magically appear at runtime. Of course, 99% of the time, it’s me accidentally using count when I meant length, etc. What I’m really trying to say here is that treating warnings as errors is an even better idea in Objective-C.

June 11, 2009

Early Adopters Wanted!

Filed under: Announcement,iPhone | , , ,
― Vincent Gable on June 11, 2009

I am wrapping up work on Prometheus, an iPhone app that edits the Simple English Wikipedia.

Unfortunately, I am having trouble finding people to take the pre-release version for a spin, and tell me what they think. I want to be sure I’ve fixed any glaring issues before I push my work out to the App Store.

If you are interested in helping, please visit the Prometheus webpage.

Thank you!

June 4, 2009

links for 2009-06-04

Filed under: Announcement,iPhone,Programming,Quotes,Research,Usability
― Vincent Gable on June 4, 2009

This was an experiment, in doing more with my delicious bookmarks. I was hoping that I could get more feedback and discussion on things I found interesting enough to bookmark by automatically posting links to them here. Many sites that I enjoy reading do something similar. But it hasn’t felt like a good fit for me.

May 29, 2009

Don’t Waste Memory to Save Time

Filed under: iPhone,MacOSX,Programming,Usability | , , ,
― Vincent Gable on May 29, 2009

In the provocatively titled, Space is Time: How Your CS Theory Class Lied to You, Greg Parker explains why hogging memory to speed up your program is a bad idea on consumer-level devices.

Space is time. An optimization that makes your program faster may make the user’s system slower overall. Play well with others.

I think it’s excellent advice. There’s only one point I want to make (and it must be made now, before silent SSD hard disks become more popular).

Every time your whole computer is nonresponsive, it makes that grrnrrnrnrr sound, right? That’s because it ran out of RAM, and the virtual memory system is thrashing to the disk. In the real word, on computers like the one you are on now, low memory plays a part in every system-wide slowdown.

Hogging the CPU can make your application slow. (Although if you pay attention to threading, and the run loop, using 100% of every core shouldn’t kill responsiveness and usability.) But hogging memory makes the whole damn world slow, including your application. And the worst case scenario of bad memory management kills the system deader then a kernel panic.

This isn’t to say that caching never makes sense. But a healthy respect for memory usage generally trumps worrying about the CPU.

« Newer Posts — Older Posts »

Powered by WordPress