I’ll start, as a lonely developer with no real following, by saying that I agree with Steve Jobs about Flash. I wouldn’t package it on the iPhone either and I haven’t installed it on my Nexus One, nor do I plan to. But having said that, there’s still a certain elitism and entitlement that Jobs needs to be called out on, and I hope I’m not alone in thinking this. Jobs starts by mentioning that Flash is proprietary, and while Apple releases proprietary things too (you think?), they, according to Jobs, prefer open standards:

Apple even creates open standards for the web. For example, Apple began with a small open source project and created WebKit, a complete open-source HTML5 rendering engine that is the heart of the Safari web browser used in all our products. WebKit has been widely adopted. Google uses it for Android’s browser, Palm uses it, Nokia uses it, and RIM (Blackberry) has announced they will use it too. Almost every smartphone web browser other than Microsoft’s uses WebKit. By making its WebKit technology open, Apple has set the standard for mobile web browsers.

Except, here’s the thing. Apple did not create WebKit. They based it on KHTML which is LGPL. They were required by law to keep it Open Source. More importantly, Jobs praises the HTML5 standard as the future for bringing video to the web. I look forward to that day myself, but I’m troubled that the biggest threat to HTML5 isn’t Adobe, but Apple. Steve writes,

To achieve long battery life when playing video, mobile devices must decode the video in hardware; decoding it in software uses too much power. Many of the chips used in modern mobile devices contain a decoder called H.264 – an industry standard that is used in every Blu-ray DVD player and has been adopted by Apple, Google (YouTube), Vimeo, Netflix and many other companies.

That’s great and all but H.264 is a closed codec and Apple’s the only browser house that has committed to only implement H.264, not the standardsy alternative, Ogg Theora. That is to say, not only is Apple supporting the closed codec, but they’ve refused to support an open one, even though doing so would cost them almost nothing in terms of development time. Apple is a member of the MPEG group, which collects royalties on H.264, so that might explain their motivation. Google, by contrast, acquired VP8 to help bridge the divide.

Regarding developers, Steve continues,

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

It’s certainly true that natively developed apps are usually better. Most cross-platform technologies are themselves meta-platforms that are, at best, inconsistent with the rest of the environment (Java’s GUI toolkit comes to mind). But barring third party developers from using cross-platform tools because those tools might not implement all of Apple’s new features is nonsensical. Even using Apple’s own SDK, developers might take their time in updating their applications, or they may not use Apple’s new APIs at all. Will Apple ban all apps that aren’t using enough new API calls?

Apple isn’t defending its right to innovate, but rather, it’s quashing everyone else’s right to innovate on the iPhone platform. There will be fewer non-native apps on the Apple Store, but that just means there will be fewer apps period. Hardly a win for users.

Finally, Steve writes,

Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on “rollovers”, which pop up menus or other elements when the mouse arrow hovers over a specific spot. Apple’s revolutionary multi-touch interface doesn’t use a mouse, and there is no concept of a rollover. Most Flash websites will need to be rewritten to support touch-based devices. If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript?

So are web sites that use onmouseover not allowed on the iPhone?

Flash is a bad piece of software. It’s proprietary, slow, buggy, and just plain bad. But users have a right to install it if they want. I’m most troubled by sentences like this:

We don’t want to reduce the reliability and security of our iPhones, iPods and iPads by adding Flash.

But they aren’t your iPhones, iPods, and iPads. They’re bought, not leased, and they belong to the users who paid for them. And if you own a device, you should have the right to decide what software it runs without having to “jailbreak” it.

That’s why I bought a Nexus One. If I want to install apps that aren’t available on the Android Market, I can do that with one touch. If I want to install a third party ROM, I’m simply warned that doing so will void my warranty (Google made no attempts to prevent you from doing this). I feel like I own the device. And I do. iPhone users should enjoy the same privilege of controlling their computing own destinies.

Most of the ROMs on xda-developers are one-off builds from hackers who are experimenting. I don’t want to experiment — I’m looking for less Slackware, more Ubuntu on my phone. Over a year ago, I installed CyanogenMod, as it seemed like the most consumer-friendly ROM out there. For one, instead of a poorly formatted posting on xda-developers, it has an actual website. It also boasts an automatic updater, lots of nice features like tethering and a caller blacklist, and even a stable-v-unstable build schedule.

Unfortunately, CyanogenMod has become increasingly unstable for me. That’s probably due to a combination of things, including Cyanogen’s unfortunate proclivity to bloat-up the stock firmware with features and experimental kernel improvements. Another cause for the problem is likely attributable to Google’s position of only half open sourcing Android.

What I’m looking for is something like the stock ROM, with root, tethering, auto-update, and not much else. I don’t think it’s out there. Maybe I should figure out how hard it is to do it myself.

OF COURSE when I saw that someone on the Interwebz managed to get the new Google Maps with navigation running on a G1, I almost wet myself with excitement. Normally this app only runs on the new Android 2.0 phones (namely, Droid from Verizon) and even rooted G1 are still only running Android 1.6. The instructions call for basically replacing the entire build properties on your phone with the Droid ones.

I’m not going to write any explicit instructions, since those are already on the forums and easily accessible with a Google search. But here’s basically what I did, which temporarily enabled navigation. To build.prop, I made the following changes:

kkinder@kkinder-laptop ~/Desktop> diff -u bp2 build.prop
--- build.prop.org	2009-11-16 11:40:34.000000000 -0700
+++ build.prop	2009-11-10 19:13:18.000000000 -0700
@@ -1,6 +1,6 @@
 # begin build properties
-ro.build.version.sdk=4
-ro.build.version.release=1.6
+ro.build.version.sdk=<strong>5</strong>
+ro.build.version.release=<strong>2.0</strong>
 ro.build.version.codename=REL
 ro.build.type=user
 ro.build.user=shade
@@ -15,7 +15,7 @@
 ro.com.android.wifi-watchlist=GoogleGuest
 ro.com.android.dateformat=MM-dd-yyyy
 ro.com.android.dataroaming=true
-ro.com.google.clientidbase=android-tmobile
+ro.com.google.clientidbase=<strong>android-verizon</strong>
 ro.setupwizard.mode=OPTIONAL
 ro.url.legal=http://www.google.com/intl/%s/mobile/android/android-dev-phone-legal.html
 ro.url.legal.android_privacy=http://www.google.com/intl/%s/mobile/android/android-dev-phone-privacy.html

At this point, after using the unix find command in my phone’s terminal emulator to delete old maps data files and application files, I was able to reboot and install the maps app with all its new features — all its new features, except for navigation. So, I continued with the *real* instructions and applied changes to build.trout.prop

--- build.trout.prop.orig	2009-11-16 11:40:56.000000000 -0700
+++ build.trout.prop	2009-11-10 19:13:18.000000000 -0700
@@ -1,25 +1,25 @@
 # begin build properties
 # autogenerated by buildinfo.sh
-ro.build.id=DRC83
-ro.build.display.id=DRC83
-ro.build.version.incremental=14721
+ro.build.id=ESD20
+ro.build.display.id=ESD20
+ro.build.version.incremental=17572
 ro.build.date=Mon Sep 21 16:16:12 PDT 2009
 ro.build.date.utc=1253574972
-ro.product.model=T-Mobile G1
-ro.product.brand=tmobile
+ro.product.model=Droid
+ro.product.brand=verizon
 ro.product.name=kila
-ro.product.device=dream
-ro.product.board=trout
+ro.product.device=sholes
+ro.product.board=sholes
 ro.product.cpu.abi=armeabi
-ro.product.manufacturer=HTC
+ro.product.manufacturer=Motorola
 ro.product.locale.language=en
 ro.product.locale.region=US
 ro.board.platform=msm7k
 # ro.build.product is obsolete; use ro.product.device
 ro.build.product=dream
 # Do not try to parse ro.build.description or .fingerprint
-ro.build.description=kila-user 1.6 DRC83 14721 ota-rel-keys,release-keys
-ro.build.fingerprint=tmobile/kila/dream/trout:1.6/DRC83/14721:user/ota-rel-keys,release-keys
+ro.build.description=voles-user 2.0 ESD20 17572 ota-rel-keys,release-keys
+ro.build.fingerprint=verizon/voles/sholes/sholes:2.0/ESD20/17572:user/ota-rel-keys,release-keys
 # end build properties
 #
 # system.prop for dream

I don’t really like the idea of editing these files, because when the system lies about its version numbers, it could break other apps. But I made backups and did it anyway, with no dice on having a working navigation system. Some reading on a thread that grew to 50 posts within hours and I noticed some users reported that uninstalling and reinstalling Google Voice got navigation working on the (presumably unrelated) maps app, which it did.

But here’s the frustrating part: After driving around and enjoying your new navigation system, you go to restore your build*props files. If you revert version numbers, the app continues to work. However once you change your phone’s model information back (ie, you switch Verizon back to T-Mobile), your navigation disappears in the GUI. In other words, the map app is checking to make sure you’re running on Verizon’s network, and only allows you navigation then. That’s kind of slimey, but update: the updated Android 1.6 app includes navigation, so I guess my initial conspiracy theories are irrelevant.