Rss

Archives for : November2010

Droidies’ Home Journal

Outrage du jour is the tale of a Danish app maker whose Android magazine app was rejected by Apple.

App rejection stories are fun because they get everyone’s hair up in a dander. There’s something for everyone to hate in Apple’s App Approval Guidelines, and the restrictions on content are especially pernicious and ridiculous. One that bugs me, for example: you can buy the heartbreaking anime series Rumbling Hearts on iTunes, complete with its handful of sex scenes, but the original visual novel it was based on would not be permitted on the App Store, because of those same scenes.

The thing is, though, we’ve sort of already had this argument about the App Store policies, and we got to do so in detail when Apple put up an official set of policies a few months ago. One that got a lot of abuse was guideline 3.1, which says that apps that mention other mobile platforms in their metadata will get rejected. That’s petty, childish, and of dubious self-interest to Apple (are they really that threatened that, say, a game description might mention that it’s also available on WebOS and Android?).

But you know what? When the rule is that clear, and you violate it that obviously, what do you think is going to happen?

Sure, one could appeal to a sense of fairness and ask for Apple to bend the rules on this one… a single app isn’t going to make that big of a difference, right? But of course, this leads to the snowball argument: if these guys get a pass, then the next app to brazenly break the rules is going to expect a waiver too.

It’s a stupid rule, and these guys broke it in a very presumptuous and obvious way. They can be disappointed, but they can’t be surprised.

Still, I can’t help but wonder what the point of all this really is? Are there really a lot of iPad owners who want to read about Android development? Oh, I can only imagine the kinds of articles that would go in an Android magazine.

  • Stealing Angry Birds IP For Fun And Profit
  • Our 10 Favorite Screen Dimensions
  • How Railing Against Apple Proves You Are An Independent Thinker And In No Way A Corporate Tool (a special advertising section provided by Google)
  • Five Games You Can Write Without Resorting To Native Code (Six If You Count Hangman)
  • Healthy Snacks You Can Make While Your App Starts Up
  • How To Write Your First Unremovable Carrier Crapware App
  • Eye Scream, You Scream, We All Scream For Ads That Involve Getting Metal In Your Eye

Totally looking forward to the inevitable Flash version of this. Totally.

This Thing I Do!

It’s been an interesting couple months with all these versions of iOS. Until last week, most of us had to juggle one legacy version (3.x), a production version (4.0 or 4.1), and the important 4.2 beta, which ushered iPad into the modern age. If you’re working on code for production, you likely needed to focus on at least two of these, possibly all three.

The Xcode tools have a reasonable means of letting you do this, by installing to locations other than the default /Developer with a few caveats, such as that a single set of the System Tools and the UNIX stuff can be present on a volume, and must be in specific locations.

My standard is to put the legacy SDK (currently 3.2) at /Developer_Old, the current production release at /Developer, and the latest beta at /Developer_New. So far so good. But what happens when you double-click an .xcodeproj or .xib… which version do you get? Do you notice or care? Probably not until you find out that the target SDK in the project file is unsupported by the version you launched. And what if you run multiple copies at once… what version of IB or the Simulator is that on your dock?

After fooling myself one time too many, I adopted a system of changing the icons of the core tools to give myself a visual indication of which SDK I’m working with. This way, I can start a specific version of Xcode right from my dock:
Aliases to different versions of Xcode

Here’s a quick look at how you can set this up for yourself.

Basically, what you need to do is to create alternate versions of the .icns files of the apps you’re interested in. For me, that’s Xcode, Interface Builder, and the iOS Simulator. I’ve created two folders, in /Developer/Xcode and simulator icons to store these .icns files permanently.:

Futuristic versions of icons
Old-timey versions of icons

As you can see, I’ve got one folder called Futuristic for the icons for betas, and another called Old Timey for the legacy SDKs.

To make these icons, start by visiting an application’s installed location in the Finder:

  • Xcode – /Developer/Applications/Xcode.app
  • Interface Builder – /Developer/Applications/Interface Builder.app
  • iOS Simulator – /Developer/Platforms/iPhoneSimulator.platform/Developer/iOS Simulator.app

Now, peek into the application by right-clicking/ctrl-clicking the app and choosing “Show package contents”, then open the “Resources” folder. You need to find the appropriate .icns file:

  • Xcode – appicon.icns
  • Interface Builder – InterfaceBuilder_App.icns
  • iOS Simulator – simulator.icns

Don’t double-click the .icns; that will probably just open Preview. Instead, make a copy and use “Open With…” (via File menu or right-click/ctrl-click contextual menu) to open up Icon Composer.
Interface Builder icon in Icon Composer

This shows the icon at the various canned sizes: 512×512, 256×256, etc. Select one of these and copy with cmd-c.

Now open an image editor… I’ve used both Pixelmator and Acorn for this kind of stuff. You don’t have to buy Photoshop. For this blog, let’s assume you’re using Acorn. Over there, do “New from cilpboard” to create a new document of the image you’ve copied from the icon. Now choose an image effect that will colorize the icon in some meaningful way, without changing its size or shape. In my case, for the old-timey look of legacy SDKs, I applied the “Sepia Tone” effect:
Applying Sepia Tone effect to Interface Builder icon

And for the futuristic look to distinguish beta SDKs, I used the Quartz Composer “thermal camera” effect:
Interface Builder icon with thermal camera effect

Copy this image, close it, go back to Icon Composer, and paste it in. Repeat for all the other sizes. When finished, use “Save As…” to save the .icns file to some safe place (I use /Developer/Xcode and simulator icons).

Now, re-visit the legacy or beta applications whose icons you want to change, and option-drag your hacked .icns file into the Resources folder, replacing the default icon (you might want to do this on a copy of the application the first few times, just to make sure you’re doing it right).

Now, when you launch these apps, you’ll be able to tell immediately which is which in the Dock.
Three different versions of Xcode running side-by-side
You can also collect aliases to each version in a single folder, then put that in the Dock (as I did with Xcode in the first screenshot) for a one-stop shop to launch the version you need.

It’s like “Glee” with coding instead of singing

Like a lot of old programmers — “when I was your age, we used teletypes, and line numbers, and couldn’t rely on the backspace key” and so on — I sometimes wonder how different it is growing up as a young computer programmer today. Back in the 80’s we had BBSs, but no public internet… a smattering of computer books, but no O’Reilly… and computer science as an academic discipline, but further removed from what you’d actually do with what you’d learned.

Developers my age grew up on some kind of included programming environment. Prior to the Mac, every computer came with some kind of BASIC, none of which had much to do with each other beyond PRINT, GOTO, and maybe GOSUB. After about the mid-80’s, programming became more specialized, and “real” developers would get software development kits to write “real” applications, usually in some variant of C or another curly-brace language (C++, C#, Java, etc.).

But it’s not like most people start with the formal tools and the hard stuff, right? In the 80’s and 90’s, there were clearly a lot of young people who picked up programming by way of HyperCard and other scripting environments. But those have largely disappeared too.

So what do young people use? When I was editing for O’Reilly’s ONJava website, our annual poll of readers revealed that our under-18 readership was effectively zero, which meant that young people either weren’t reading our site, or weren’t programming in Java. There has to be some Java programming going on at that age — it is the language for the Advanced Placement curriculum in American high schools, after all — but there’s not a lot of other evidence of widespread Java coding by the pre-collegiate set.

I’ve long assumed that where young people really get their start today is in the most interesting and most complete programming environment provided on every desktop computer: the web browser. I don’t want to come off like a JavaScript fanboy — my feelings about it are deeply mixed — but the fact remains that it is freely and widely available, and delivers interesting results quickly. Whereas 80’s kids would write little graphics programs in Applesoft BASIC or the obligatory 10 PRINT "CHRIS IS GREAT" 20 GOTO 10, these same kinds of early programming experiences are probably now being performed with the <canvas> tag and Document.write(), respectively. In fact, the formal division of DOM, CSS, and JavaScript may lead the young programmer to a model-view-controller mindset a lot sooner than was practical in your local flavor of BASIC.

The other difference today is that developers are much better connected, thanks to the internet. We didn’t used to have that, so the programmers you knew were generally the ones you went to school with. I was lucky in this respect in that the guys in the class above me were a) super smart, and b) very willing to share. So, 25 years later, this will have to do as a belated thank you to Jeff Dauber, Dean Drako, Drew Shell, Ed Anderson, Jeff Sorenson, and the rest of the team.

Did I say “team”? Yeah, this is the other thing we used to do. We had a formal computer club as an activity, and we participated in two forms of programming contests. The first is the American Computer Science League — which I’m releived to see still exists — which coordinated a nation-wide high school computer science discovery and competition program, based on written exams and proctored programming contests. The cirriculum has surely changed, but at least in the 80’s, it was heavily math-based, and required us to learn non-obvious topics like LISP programming and hexadecimal arithmetic, both of which served me well later on.

Our school also participated in a monthly series of programming contests with other schools in the suburban Detroit area. Basically it worked like this: each team would bring one Apple II and four team members and be assigned to a classroom. At the start of the competition, each team would be given 2-4 programming assignments, with some sample data and correct output. We’d then be on the clock to figure out the problems and write up programs, which would then be submitted on floppy to the teachers running the contest. Each finished program scored 100 points, minus 10 points for every submission that failed with the secret test data, and minus 1 point for every 10 minutes that elapsed.

I have no idea if young people still do this kind of thing, but it was awesome. It was social, it was practical, it was competitive… and it ended with pizza from Hungry Howie’s, so that’s always a win.

Maybe we don’t need these kinds of experiences for young programmers today. Maybe a contrived contest is irrelevant when a young person can compete with the rest of the world by writing an app and putting it on the App Store, or by putting up a web page with all manner of JavaScript trickery and bling. Still, it’s a danger to get too tied to the concretes of today, the specifics of CSS animations and App Store code-signing misery. Early academic exercises like earning to count in hex, even if it’s to score points on a quiz, will likely pay off later.

The Other iOS Programming Language

My latest contract project has me doing a bunch of custom work with a UIWebView: we have XHTML content that we want to render in our app, but with some fairly extensive changes to its presentation, such as paginating the content like a book, and intercepting taps on links. Given the option of using and customizing the built-in WebKit rendering, versus parsing the XHTML myself, laying it out, etc., the choice was a no-brainer.

The trick, then, is in how to extend and customize the functionality. As a long-time curly-brace application developer, my natural instinct is to impose control from the Cocoa side, perhaps by subclassing UIWebView to achieve custom behavior (although this is specifically discouraged by the documentation), tying in delegates where possible, perhaps even employing some render hackery (like using an offscreen UIWebView and then blitting its pixels into some visible view). But this really isn’t the right way to do it: for starters, it still gives you no access to the DOM, which is where nearly all the value of your HTML content is.

I suspect younger readers already know what the right answer is: insert your own JavaScript, and work inside the UIWebView. This is pretty straightforward to do — you can load the HTML source into a string and then munge it as necessary, such as by strategically adding references to your own CSS stylesheets or JavaScript (.js) files, and then load that modified source into the UIWebView, along with an appropriate base URL to help resolve relative paths. I say this would be a natural conclusion for younger developers because I suspect that most young developers start with either Flash or JavaScript, as these environments deliver immediate visual results and aren’t hard to get into (plus, JavaScript is free). Developers my age sometimes wish that computers still came with an introductory programming environment like a flavor of BASIC or HyperCard, overlooking the fact that today’s dominant starter language is included with every browser.

What makes JavaScript programming practical in an iOS app is the method -[UIWebView stringByEvaluatingJavaScriptFromString:], which does exactly what the wordy method name says: it tells a UIWebView to execute arbitrary JavaScript contained in an NSString parameter, and return the result as an NSString. You can easily try it out on a UIWebView in your own application like so:


	[myWebView stringByEvaluatingJavaScriptFromString:
		@"alert ("hello JavaScript");"];

With this door opened between the JavaScript and Cocoa worlds, you have two-way access to the DOM and how it is rendered. For example, you can pull out the web view’s selected text by writing a simple JavaScript function, and calling it from Cocoa. Or slurp it all in by walking the DOM, appending all the textContent, and returning one big NSString. Or collect all the links with document.elementsByTagName('a') and index them in Cocoa.

But don’t stop there. With the richness of JavaScript, you can employ all the tricks you see in rich web applications, such as rewriting the DOM on the fly, scrolling around programmatically and finding element coordinates, etc. Plus, since you’re only running against one pseudo-browser (iOS’ built-in WebKit framework), you don’t have to work around the incompatibilities and quirks of multiple browsers like regular web developers do.

As I’ve worked on this project, I’ve settled into a “Render unto Caesar…” strategy. Meaning that anytime I need to access contents of the DOM, or change how it is rendered, I know I’m writing a JavaScript function, because that’s what owns the web content and its rendering. For the rest of the app, it’s still Cocoa.

There are hard parts, not the least of which is that fact that I’m still pretty green when it comes to JavaScript and messing around with the DOM. Mozilla Dev Center is a very useful resource for this, despite some search and link breakage, far more so than Apple’s Safari Dev Center.

The other problem is that debugging JavaScript in a UIWebView is notoriously difficult. Unlike desktop browsers, there is no “developer mode” you can drop into in order to inspect elements, see the results of your actions, or even log messages efficiently. Worse, the smallest syntax error will break execution of your function (and major syntax errors can break your whole .js file), so there is often little recourse but to jam alert() calls into your code just to see how far the interpreter gets before quietly dying. That said, iOS Safari behaves very much like its desktop equivalent, so it is possible to do some amount of development and debugging in desktop Safari’s developer mode, or the WebKit nightly build, before switching back to the UIWebView. That said, I only do this for extreme cases of debugging — I wouldn’t want to develop a bunch of new code against WebKit nightly only to find it doesn’t work the same way on the production version of iOS.

Anyone with a browser knows how rich web applications can be, and so you implicitly know that anything you can do in Safari can also be done inside a UIWebView. Sometimes it makes sense to do exactly that.