iOS Multitasking

By now you’ve seen the ads. Anyone who works in mobile totally saw it coming. It’s the supposed revolutionary way to do multitasking in iOS, the new name for the iPhone OS. It’s complete bullshit, and here’s why.

It’s Not Revolutionary
Personally, I don’t really care about this point. However, it must be noted that the multitasking on the iPhone is strictly speaking a proper subset of the multitasking architecture used by Android and Palm’s webOS. Does it really matter? No, not really, but it is certainly annoying to hear Apple talk about how they didn’t do multitasking in the past because they hadn’t figured it out yet. The notion that what they ‘came up with’ is some brilliant solution that it took four years to figure out is insulting to the intelligence of developers. Not that that matters...

It’s Not Multitasking
Even Apple is pretty honest about this ... to developers. For us they say “it’s actually something We call Fast App Switching, and it’s all most of you people need.” This is the feature that was done by Android and webOS for the last couple of years. On iOS, when a user switches apps or hits the home button, your app has a brief time when it “runs in the background.” Then it becomes suspended. In its suspended state, it is still in memory, but gets no CPU cycles. If the user re-opens it or switches back to it, then it picks up right where it was before. Assuming that it is like Android (and everything else about Fast App Switching is very similar), then as a developer you might need to save some transient data, like if there is a form that is half-filled by the user. However, often you will not need to do anything to take advantage of this, just recompile with iOS 4.0 as your target.
But wait, there’s more. You should not count on your app staying suspended indefinitely. In fact, there’s a very good chance it will be terminated (that’s the official word.) This is exactly what happens when you go to the home screen on previous versions of iPhone OS, your app no longer takes up any memory. Now the user can still ‘switch’ back to your app (or re-open of course), but now it will be a re-launch of the app. In other words, it is just like closing your app, then re-opening it on iPhone OS 3.x.
This can obviously lead to inconsistent app behavior. Sometimes the user might switch away from your app, then switch back and be back at the same screen in your app that they were at before. Other times, they could do the same thing, but instead they are back to the opening sequence of your app. Apple wants you to change your app to remove this potential inconsistency. They’ve kind of given you a way to do this. First, when your app goes from being active to suspended, a new event is fired to your application’s delegate. All you have to do is add this new method (applicationDidEnterBackground:) to your delegate. In that method, you can save the state of your application. However, you might not have enough time. You can wrap your code with a start/end task completion calls, and then get up to ten minutes to finish saving your state. Alternatively, you can incrementally save state. Now truth be told, many apps (especially games) already do this, so that when you restart your app, it always picks up right where the user left off. Apple has essentially taken this pattern that other apps have adopted, promoted it to a best practice, and give you some extra tools to make it a little easier to implement.
There is one other thing that you might want to do right before your app gets suspended. You can decrease the probability of your app getting terminated by freeing up as much memory as you can. The iOS Terminator is going to kill apps that use more memory first. So free up as much memory as possible, and maybe it won’t kill your app. There’s no guarantees though. If the user launches an app that needs a lot of memory (and don’t they all?) then it doesn’t matter how little memory your app takes up. Everything is getting terminated. Hence Apple’s desire for you to always save state and never rely on being suspended when the user switches back to your app. However, if you do that, then is there any point to freeing up memory? Well theoretically it should be quicker to switch to a suspended app than a terminated one, so by freeing up memory you will be increasing the probability that your users will get a slightly better experience.

What is Real Multitasking?
Well strictly speaking, true multitasking would be to allow any given application to continue running as  normal when it is no longer in the foreground. This is what happens on desktop computers, and that sort of sets the expectation for smartphones. I think this is actually how Blackberry works (or it used, it has been many years since I bought a new Blackberry.) It’s not how Android works, and it’s obviously not how iOS 4 works. The major problem with this on more limited devices is that it causes those devices to run out of memory and use virtual memory. This makes everything on the device run sluggishly, as everything becomes gated by the swapping between real and virtual memory. Those non-foreground apps can also consume CPU and network. The CPU consumption might be an issue if you tried to run multiple games simultaneously -- just like it would on your desktop computer. Apple claims the CPU/network access real kill your battery. We’ll examine that later. Regardless, once you decide that a background app can lose its right to memory, it can’t function anyways. CPU/network becomes a moot point. Both Android and iOS terminate background apps to free up memory, something no desktop OS will do.
So iOS and Android both use similar pseudo-multitasking to make it seem like multitasking to the user. To prevent memory from running out and hosing the system, they terminate background apps at will. Both operating systems give you a way around this, a way for you to continue to execute a program in the background. That is where the similarities end.
On Android, you can create your own background service. That service can be in its own process, i.e. it gets its own block of memory allocated to it. That way if your application gets terminated, the service lives on. However, a service can be terminated just like an app. So you cannot rely on the service always running, instead the service should be there to enhance your application. Further, Android gives you ways to get your service restarted/pinged on a regular basis to do work.
On iOS, there are just a couple of types of applications that are allowed to run as a background service. Even then, they do not get their own memory. Instead they stay suspended and the OS sends them events periodically that allows them to run in the background again while they do something. Apple says they do not want to provide the Android style background services, because they (Apple) decided that the great majority of apps would not benefit from this anyways. Further, they think that such an architecture would lead to many background services running, killing the device’s battery. So instead they picked the types of apps that they say will benefit from background processing: music players, navigation, and voice-over-IP. The most ironic part of this is that the enabled a class of app, navigation, that has the most harmful effects to your battery (well maybe games are worse.)
I’ll talk about battery life in a second. First I want to address this notion that Apple has determined which apps would benefit from background processing, and which would not. As both a developer and a user, this is offensive. Apple has little knowledge of how my app works, or of how my users interact with the app. Further, they are obviously wrong. I can give you three examples of apps that use background services on Android to greatly enhance user experience: eBay, Facebook, and Twitter. You’re probably not surprised that I cited my company’s app, but maybe the other two did surprise you. All three use a background service to periodically download time sensitive data (current price of items, friend requests, status updates, tweets, etc.) So when you launch the apps or switch to them, you do not wait for all of this data to be downloaded -- like you do on all three companies’ apps on the iPhone. Instead you are presented with some fresh data (maybe a few minutes old), while the absolute freshest data is being downloaded in the background. You get to immediately interact with the apps. On iOS it might be possible to allow immediate interaction, but the data can only be as fresh as the last time you ran the app. This will usually be hours old, which makes it virtually useless for these apps.
There is no question in my mind that user experience can be better on Android than on iOS for these apps, and I don’t think they are unique. I mean c’mon, we’re talking about eBay, Facebook, and Twitter. Perhaps you’ve heard of these companies? It seems obvious that any kind of real-time/interactive/social based website is going to benefit from background processing for their apps. That’s a pretty broad class of apps, but I doubt it’s exhaustive. I’m not smart enough to figure out all of the apps that would benefit from background processing -- and neither is Apple.

Battery Life FUD
Ok, but what about the last plank in Apple’s argument: battery life. Well, as I pointed out earlier, they enabled a class of application that is devastating on battery life: navigation. These apps require constant high precision GPS information, which is very expensive. So their argument is not consistent with their behavior, still that doesn’t make their argument wrong.
The apps that I mentioned earlier all are guilty of something that is supposedly deadly to battery life: they periodically use the network to download data. How bad is this? Well obviously it depends on how often, and how many network calls are made, along with how much data is being sent back and forth. I’ve done some experimenting on this -- hey I work on one of the apps on that list of naughty apps. In my experiment I had an app that downloaded 100K+ data every two minutes. The effect on battery life was less than 3%. That’s right. You could let such an app run in the background for days and days, and your phone would still have plenty of battery.
Now wait a minute, I know what you’re thinking. You can’t even go one day without recharging your phone, and you’ve got an iPhone that doesn’t have anything running in the background (by the way this is not true, Apple’s apps have been able to run in the background since the very first iPhone.) Further, you don’t even use it to make phone calls, yet it’s got maybe 12 hours of battery life. What gives? The answer is surprisingly simple, the screen. The screen on your beautiful phone is what drains your battery the most. So anything that involves the screen being on -- which is every kind of app on the iPhone currently -- will significantly drain your battery. Everything else they do has little noticeable effect on battery life, with two exceptions. Anything that rapidly changes that pretty screen will consume your battery even faster. That’s why many games will hammer your battery. I’ve had times where I played Civ on my iPhone for maybe twenty minutes, and it lopped off a third of my battery. That game doesn’t even have that much eye candy. The other battery blaster is the aforementioned GPS, for obvious reasons. All of those Android users with eBay, Facebook, and Twitter installed are doing just fine.

But You're Gonna Love It!
So with all of that being said... users will really appreciate Fast App Switching in iOS 4. Why am I sure of this? Because Android users have always loved it. It’s one of those things where iPhone users don’t know what they are missing. Thus it will be delightful for them, and they will think Apple is full of geniuses. Actually I think it will put some serious pressure on Apple to update the iPad to iOS 4 (or maybe 4.1? Will we ever run the exact same OS on the iPhone and iPad?) People will get used to having Fast App Switching on their iPhone, and they will be so annoyed that they don’t have it on their iPad. I hope we’ll eventually see the same thing with regards to general purpose background processing. Maybe one day this will be part of iOS, and then it will be annoying to use older versions on the OS that don’t have this feature.

Update: You can add Instapaper to the list of apps whose developer would like it to be able to run in the background, so that it can improve user experience. Marco has an interesting proposal to tweak iOS to suit the needs of his app, and no doubt many others. It's better than the current situation, but I still think it's foolish to try to figure out all of the types of apps that need background processing, and add special APIs for each such app. While at WWDC, I talked to developers who work on some very popular sports and weather apps, and they too were incredibly disappointed by iOS. One of them proposed a new type of remote push notification that would not be displayed and only processed in the background.

WWDC Wish List

Tomorrow is WWDC. Much like how I had an Android wish list for Google I/O (and I got my top two wishes!) a few weeks ago, I have one for the iPhone and WWDC. Given that OS 4.0 has been in beta for quite awhile, there is a little less suspense. So my wish list is a little more product based instead of development based.

1.) iPhone for Verizon. AT&T has nixed the generous data plans for the iPad (as well as for the iPhone,) so really why is there any reason for Apple to stay exclusive with them? In fact one could imagine that AT&T busted out the new pricing last week because they knew their exclusivity was coming to an end. I certainly hope this is the case. Personally I would not switch to Verizon, but I hope that many folks do. Plus I think that if folks had a choice of iPhone on AT&T or iPhone on Verizon, then both companies would compete much harder, improving networks and dropping prices. This is a key but subtle component of the Android strategy that fanboys/apologists often seem to miss.
2.) Non-AppStore apps. No way, right? Don't be so sure. How easy would it be for Apple to give folks a deeply buried user preference for allowing non-AppStore apps on their iPhone? An insignificant number of users would ever enable this "dangerous" option, but it would do so much. From a PR perspective, it would take the heat off Apple. Actually this might not just be PR, it might be legal as well. Want to use Flash to develop for the iPhone? Ok, just distribute it through your own channels to users who want to go outside of the AppStore. Obviously this would really make life easier on developers. The current provisioning process is ridiculous.
3.) Mobile Safari improvements. I expect that we'll hear about how Safari and/or Mobile Safari is fifty-billion percent faster than ... something else. Apple is fond of blowing up micro-benchmarks. I'd like to also see some new features. I'd really like to see Web Workers, especially since Safari already supports them. I'd be thrilled to see the Device API, so that we can get access to the camera (and how about that front-facing camera, too?) and how about access to a user's contacts? It feels like Android'd browser is really pulling ahead of Mobile Safari, so it would be great to see Apple take back their lead.
4.) Real multitasking. I'm probably going to hurl tomorrow when I have to hear Steve Jobs brag about multitasking in iPhone OS 4.0. It's bullshit. As I've said before, OS 4.0 does not implement multitasking, it implements a handful of multitasking use cases. There is a big difference. Of course there is no chance of this. The multitasking in OS 4.0 is obviously technology designed by marketing and business people, not by engineers. They want to put an end to those obnoxious Motorola Droid commercials that make fun of a "a phone that can't walk and chew gum at the same time." So instead of figuring out how to do multitasking right, so that it enables developers without sacrificing performance, we get a useless feature (unless you happen to be one of the three use cases) that will be hailed as revolutionary.

Phone Number Fixer for Android

One of the curses of working with computers is that you often become The IT person for friends and family. In fact, I should get a commission from Apple for all of the business I've sent their way by getting family members to switch to Mac computers. Ditto for the Firefox browser. I can't make people switch to Mac, after all that's often an expensive proposition, but it's long been a condition of my help that you never even think about using IE. For some of my less computer savvy relatives, I've learned to make IE disappear. This just made my life a lot easier (less things to fix) especially back in the heady days of weekly IE6/ActiveX exploits. Anyways... These days most folks, including friends and family, mostly use web applications and since I've had them on Firefox for a long time now, there aren't too many problems. However, recently I got an unusual request for help from a high school friend Maria.

She had just switched to a Nexus One -- a phone that she seemed to be extremely happy with. She had imported several contacts from her SIM card that had been in her old phone. The only problem was that for these contacts, their phone number was classified as "Other." That would not be a big deal, but when she would try to send a text to a number, Android's auto-complete would not include these "Other" phone numbers as part of its search domain. So she would have to completely type out the number to send the text to -- which kind of defeats the purpose of having an address book on your phone. She could manually change each of these phone numbers to be of type "Mobile", and this would solve the problem for that number. However as you might guess, she had a lot of numbers and changing each manually would be painful to say the least. And that's where I come in...

This sounded like an easy enough problem to solve. Find all of the numbers that were of type "Other" and change them to "Mobile." That might not work for everyone -- there might be some people who really want to classify some phone numbers as "Other" -- but it certainly worked for Maria (and I would guess most people, too.) So I cooked up a quick little app. First, I wanted to display all of the numbers that this was going to affect:

ContentResolver resolver = getContentResolver();
String[] fields = new String[]{People._ID, People.NAME};
Cursor cursor = resolver.query(People.CONTENT_URI, fields, null, null, People.NAME);
LinkedHashMap<Integer, String> people = new LinkedHashMap<Integer,String>();
int id = cursor.getColumnIndex(People._ID);
int nameCol = cursor.getColumnIndex(People.NAME);
if (cursor.moveToFirst()){
 do{
  people.put(cursor.getInt(id), cursor.getString(nameCol));
 }while (cursor.moveToNext());
}
cursor.close();

This gives you a LinkedHashMap whose keys are the IDs of each contact, and whose values are the names of the contacts. Why did I bother with these two bits of info? Well, we need the contacts to query the phones, and I wanted something friendly to display to Maria so she knew which numbers were about to get "fixed". Anyways, now it was easy to query the phones:

ArrayList<String> data = new ArrayList&kt;String>();
StringBuilder sb = new StringBuilder();
String[] projection = new String[]{Phones.DISPLAY_NAME, Phones.NUMBER, Phones._ID};
Uri personUri = null;
Uri phonesUri = null;
int displayName = 0;
int number = 1;
int phoneIdCol = 2;
int phoneId = -1;
int cnt = 0;
for (int personId : people.keySet()){
 personUri = ContentUris.withAppendedId(People.CONTENT_URI, personId);
 phonesUri = Uri.withAppendedPath(personUri, 
            People.Phones.CONTENT_DIRECTORY);
 cursor = resolver.query(phonesUri, projection, 
            Phones.TYPE + "=" + Phones.TYPE_OTHER, null, null);
 displayName = cursor.getColumnIndex(Phones.DISPLAY_NAME);
 number = cursor.getColumnIndex(Phones.NUMBER);
 phoneIdCol = cursor.getColumnIndex(Phones._ID);
 if (cursor.moveToFirst()){
  do {
   sb.setLength(0);
   sb.append(people.get(personId));
   sb.append(": ");
   sb.append(cursor.getString(displayName));
   sb.append('|');
   sb.append(cursor.getString(number));
   data.add(sb.toString());
   phoneId = cursor.getInt(phoneIdCol);
   cnt += updateContact(phoneId);
  } while (cursor.moveToNext());
 }
 cursor.close();
}
ArrayAdapter<String> adapter = new ArrayAdapter<String>(this, R.layout.phone, data);
setListAdapter(adapter);
Toast.makeText(this, cnt + " phone numbers updated", Toast.LENGTH_LONG).show();

This code just loops over the contacts we got from the first query. For each of those contacts it queries to see if the contact has any phones that are of type "Other" (Phones.TYPE_OTHER). If it does, it creates a string that shows the contact's name, the phone's display name, and the phone number. This string is added to an ArrayList. Once all of the queries complete, an ArrayAdapter is created using the ArrayList of contact name/phone strings and used to populate a ListView.
You might have also noticed that a there is a counter variable being incremented, and an updateContact method. This is actually the method that fixes the phone number. I probably should have just kept track of the phoneIds and then gave the user a button to initiate the fixes, but I was lazy. Here is the code for updateContact.

private int updateContact(int phoneId){
 ContentValues values = new ContentValues();
 values.put(Phones.TYPE, Phones.TYPE_MOBILE);
 ContentResolver resolver = getContentResolver();
 Uri phoneUri = ContentUris.withAppendedId(Phones.CONTENT_URI, phoneId);
 return resolver.update(phoneUri, values, null, null);
}

Too easy. Contacts are an example of a Content Provider in Android. Many people (including my Android in Practice co-author and author of Unlocking Android, Charlie Collins) have criticized Android for exposing too much of the database backing of Content Providers. As you can see from the examples above, you have to deal with cursors (moving, closing), queries, updates, and very thinly abstracted select and where-clauses. Maybe it would have been better to drop down directly to the SQL, or provide a more object oriented API. Now you can create your own Content Provider, and you don't have to use SQL database to back it -- but then implementing the Content Provider contract can be quite awkward.
Anyways, I found that the easiest way to get this little app to Maria was to simply put it on the Market. It's still on there if you happen to have a similar problem (maybe many people switching to Android might experience this?) If you are on your Android phone you can just select this link. If you are on your computer you can scan this QR code.

Mobile Zealotry

"You're either with me or against me!"
Does this feel like the rhetoric coming out of Google and Apple lately? Sometimes I wonder if Russell from Survivor is working for these guys. I was at Google I/O last week, and I have to admit that Vic Gundotra delivered a great keynote. It really got the troops excited.

"One man, one company, one device, one carrier would be our only choice ... Not the Future We Want"
Indeed. But before you go out and get an Android tattoo, and toss your iPhone off of the Golden Gate Bridge, take a deep breath and remember: You don't work for Google (unless you do, in which case I assume you've already got said tattoo.) You should not care who wins this jihad -- but make sure that you aren't collateral damage.

If you are a mobile developer, what you should most care about is delivering the best and most useful experience to your users. So first and foremost, you need to care about what kind of devices your users are using. If they are all iPhone users and you really want to build Android apps, well sorry. Further, if they are all Blackberry users, then you can just ignore the drama going on here in the Valley.

Of course the device of choice for your users today is quite possibly not what they will be using tomorrow. Former Android engineer Cedric Beust makes the point that the iPhone may well have peaked. Things look great when you're at your peak, especially if you don't realize that the descent has begun. So you might build a killer iPhone app this year, only to find that your users have moved on next year. Nobody ever said that this was an easy game.

Hedging your bets and investing in multiple platforms seems like the safe thing to do, if it's practical. But don't forget the other factor: delivering a great app. If you can't deliver a great app on Android, then don't bother. If you can't deliver on the iPhone, then don't bother. Both Apple and Google have gone out of their way to provide developers with fantastic tools and platforms for creating great apps, so this may be a moot point. There are definitely types of apps that are better suited for one platform than the other. For example, the iPhone seems to be superior for games. If you look at the success of consoles, you can see why that kind of environment where hardware and software are highly standardized, translates well to the iPhone. Similarly, the lack of background processing on the iPhone (and don't believe any hype about iPhone OS 4 changing this, it does not except in a few special cases) cripples the capabilities of many iPhone apps.

The most important thing to keep in mind in all of this is that it is in Apple and Google's best interests to be as divisive as possible. If they can convince you that they are "right" and that you should only develop for their platform, this is a huge win for them. So expect the rhetoric to only get worse. How many days until WWDC?

Android Wish List

This Wednesday is the first day of Google I/O. Google has a lot of very interesting technologies and many of those will have some new features announced this week. However, it doesn't seem too presumptuous to say that I/O is going to be Android-centric this year -- maybe every year for awhile. Google has pitted itself firmly against Apple and its iPhone/iPad platform. So I/O is Google's WWDC, and in case you missed it WWDC 2010 is all about mobile. And so it is with I/O.

There is a lot of chatter about Froyo, or Android 2.2. It's browser will have an integrated Flash plugin. It's supposed to be insanely fast (courtesy of a JIT and lower RAM usage by the kernel). It will support USB tethering and it can turn any Android phone into a mobile hotspot. That's all great, but none of that really does much for us Android developers, except for the speed increase of course -- especially important for game developers. Speaking of game artistes, Froyo is supposed to bring a lot more OpenGL ES goodness into their hands. So maybe we'll start seeing killer games on Android. Anyways, back to developers. What's Froyo got for us? More importantly, what do you want out of the platform? Here's my list.

1. Push Notifications. The iPhone has it. Blackberry has had it for what, a decade? The Windows Phone thing that's coming out at the end of the year is supposed to have them too. But what about Android? Background services and polling? Stop F'ing with me.
2. Apps on SD Card. Yeah we've been asking for this for a long time, and Google has always shot it down. Why is it important? It removes the pressure to keep apps super small, a pressure that has some chilling side effects. On the iPhone, I wouldn't hesitate to use a 3rd party library in an app, even if it added an extra 500KB to the app size. Not so on Android. For me this is particularly acute when it comes to using other languages like Scala on Android. The runtime library size is prohibitive -- because the app can't be saved on to the SD card.
3. More JDK. Wouldn't it be nice to have JAXB on Android? What about JAI? Yeah I know that sometimes they just wouldn't work because of performance reasons, but sometimes they would. Shouldn't be up to the developer to figure out when to use it or not?
4. Android for pads/slates/tablets. Yeah I want the Android equivalent of iPhone OS 3.2. I want to see Android on these form factors. As a corollary, I want an end to ChromeOS and that potential distraction. Let's just have one tablet OS from Google, ok? Android: Tablet Edition will have the Mobile Chrome browser in Android, anyways right? Bonus points: A sexy device with the new OS running out given to all of the developers at I/O (I know they gave us Droids already, but I'm greedy.)

So there's my list. What's yours?

Update: I remembered one more thing for my wish list, though this is not directly part of Android. I want Android 2.1 (or 2.2) to be available on all Android devices. I want it running on the G1, for example. There are definitely some SDK features I'd like to take more advantage of, and that's hard to do with 1.5 and 1.6 still on the majority of devices. The Mobile Chrome browser in 2.0+ is infinitely better than what's in 1.6 and lower because it uses HTML5 standards for storage, offline, geolocation, etc. instead of the now defunct Google Gears. So I really want those 1.5 and 1.6 browsers to go away, it's like having to support an ActiveX control for Ajax...

Awesome Android Presentation

... by my "Android in Practice" co-author, Charlie Collins:

Unlocking Android Development on Prezi

Apple, Flash, and The Truth

I'm sure by now you've read "Steve Jobs"'s Thoughts on Flash. Did it convince you? Do you think it was truthful? Not me. Sure it has some valid points, especially about Flash being buggy on OSX. As someone who has developed Flash applications using a Mac, I am especially aware of this bugginess, and part of me can't help but get a perverse sense of satisfaction that this bugginess is now coming back to haunt Adobe. However, this doesn't change the fact that Jobs's epistle is far from the truth. It is corporate slander, designed to make Adobe look as bad as possible. Why? So that when devices from competitor's ship with full support for Flash, this technological advantage can be discredited in the eyes of consumers. In other words, this well thought out post by Apple is not some intellectual/technical analysis, it is just marketing designed to boost Apple's profits.

The most dishonest thing about the post is what Apple says is "the most important reason" to ban Flash from their devices: that it will result in sub-standard apps and hurt their iPhone/iPad OS platform. This is complete bullshit. It's not like developers would suddenly only be able to create iPhone apps using Flash. It's not like they could no longer use all of the tools they use today. The difference is that they would have a choice. They could choose to use Flash. Or they could choose to use Objective-C/Cocoa/XCode.

But don't forget, that not only would developers have a choice, but so would consumers. If for some strange reason, some developers started choosing to use Flash,  it's not like consumers would be forced to buy those Flash-authored apps. No, they could still choose other, traditional apps. In fact, if, as Apple claims, Flash-authored apps would be of such low quality, then one would expect that few consumers would choose to purchase those apps.

So if Apple allowed developers to use whatever tools and technology they wanted to use, to create apps for the iPhone and iPad, what might happen? Well if Apple's claims are right, then there would be bad apps that nobody would buy (aren't there already a lot of such apps on the App Store?). Consumers aren't idiots, and they won't buy crappy apps when there will be better alternatives. So those Flash-authored apps will lose money. Developers aren't idiots, and they won't keep using technology that produces software that nobody wants. So they would abandon Flash and go back to Cocoa. So Apple's "concerns" would be unwarranted.

Or perhaps what would happen is that some developers would produce good apps using Flash that consumers bought for their iPhones. Certainly developers would continue to use Flash. However, in this scenario, Apple's "concerns" are proven to be false -- Flash produces some good apps. But wait, what about Flash holding back innovation on the platform? Apple would still be free to add new features to their OS, and make them available to developers through new APIs in the iPhone SDK. Who knows how long it would take Adobe to expose those features through the Flash authoring tools, but who cares? If those features greatly improve apps, and they aren't available in Flash authoring, then what happens? The power of choice wins again. Developers can still choose to use Cocoa, tap into these innovations, and user's can choose to purchase the apps that take advantage of these innovations. If these features are so great, one might expect that Adobe would try to bring them to Flash authoring as quickly as possible. Either way, the notion that the Flash platform would be held back makes no sense.

So Apple's self-described most important point is so false that it is laughable. Some of their other parts are equally false. For example, the notion of touch and Flash. Yes, many things in Flash are designed for users interacting with a mouse, not a finger. Such things don't work well on touch devices. However, this is not just true for Flash. It is equally true for HTML and JavaScript. If you've done a lot of surfing on your iPhone or iPad, you have surely experienced the "rollover" issues described in Apple's post. Want more examples? Check out this clever little video on HTML 5 and the iPad:


So why all the bullshit? As I said earlier, the reason for the post is to discredit any competitor that provides Flash support on their devices. First and foremost on that list is Android, which will support Flash in Android OS 2.2. That doesn't explain why Apple doesn't want to allow developers to use Flash to develop for the iPhone? The answer to that is simple. They want complete control of their platform. If you want to make money off of the iPhone, you have to be in bed with Apple. They saw how the web has hurt Microsoft, and they will not let this happen on the iPhone or iPad.

Now wait a minute, isn't Apple investing heavily in the web, namely HTML 5? Doesn't that demonstrate that they are willing to give up control of their platform? Yes, and no. Yes, Apple has invested into WebKit, a technology that in various forms implements a decent chunk of the HTML 5 standard. But you see, the key word here is "standard." This is how Apple fools you into thinking that they are providing an "open" alternative to their proprietary system.

It's easy to get fooled into thinking that any company that implements and open standard is innovative, but just the opposite is true. We think standards=innovation for browsers because of Microsoft IE 6. That browser dominated the world for a long while being completely stagnant. It was both non-standard and non-innovative, but this is an exceptional. It is rare that such technology can flourish. It took the unique nature of Windows, IE, and Microsoft's legal troubles to produce this situation.

Adopting a standard just means that you either change an existing feature of your technology to comply with the standard, or you copy a feature from others in the space. It is anti-innovation. When it comes to web standards, they are introduced post-hoc. XMLHttpRequest, the key technology behind Ajax, was proprietary Microsoft technology for many years before it became a standard. Many of the features of HTML 5 were introduced by various plugin technologies like Flash or Google Gears before they became part of the HTML 5 spec. You cannot innovate while waiting for some super slow moving corporate committee to vote on a new standard.

Going back to the iPhone/iPad, Apple is saying: pick either Cocoa and go through the App Store, or stick to the web, but only the "open standards" part of the web. They have given you a choice, but only the weakest, most impotent choice possible. You see this is where the other part of their Flash ban comes into affect. Not only have they recently banned compiling a Flash authored application into a native iPhone application, they have always banned Flash running in the browser. Why? Because with browser plugin technologies like Flash, Silverlight, and yes even Java, you can create user experience's on par with desktop applications. If they allowed Flash in the browser on the iPhone, then developers could create web applications that might rival the native iPhone applications. And we wouldn't want that, now would we? So Apple give you a single alternative to using Cocoa/XCode/AppStore, and then they horribly cripple it, by removing the most innovative parts and tying a design-by-committee-technology weight around its neck. Apple's endorsement of HTML 5 is one of the greatest marketing ruses ever. They stifle innovation, limit choice, and line their own pockets while getting everyone to believe they are being developer friendly and innovative.

After all of the above, you might think that I am very anti-Apple, anti-iPhone, anti-iPad. I'm not at all. I am anti-bullshit though. I don't like being lied to and treated like a lemming. Apple has every right to keep Flash off of their devices. It's their OS after all. They have very right to ban apps that were authored with Flash from their AppStore. It's their AppStore after all. Just don't lie to me about this stuff. Don't say it's better for developers or better for consumers, when it's actually worse for both. Just tell the truth: it's just better for Apple.

Thoughts on iPhone OS 4.0 and Section 3.3.1

I'm on vacation right now. Earlier in the week, I took my kids to the Kennedy Space Center:

Now I am in my hometown of Panama City, Florida visiting family and friends. However, yesterday Apple released the beta of iPhone OS 4.0. I read about it briefly on my iPhone while riding around town yesterday. Saw that it supported multi-tasking -- yay! Saw some nice features, like unified inbox, multiple Exchange accounts, geo-tagged pictures, etc. I was psyched, and planned on reading more about it later.

Later came, and I started reading more details on my laptop. Of course what everyone was talking about was Section 3.3.1. Soon I went from being psyched about OS 4.0, to being very annoyed about it. Now I know that some people do not think Apple is singling out Adobe, but it damn sure seems like a reaction to Flash CS5. Let's not forget that Apple also made several barely-disguised jabs at Google-owned AdMob while unveiling Apple's own iAd platform. OS 4.0 is all about Apple going after other big software companies that are making money or trying to make money off of the iPhone. However, in the process, Apple is going to take out other companies like Appcelerator. Not that Apple cares...

So yeah, Apple is screwing lots of other people who are trying to make a dime while at the same time enabling more developers to support the iPhone/iPad platform. Nothing to see here, move along. A number of people have pointed out that Microsoft in all of its monopolistic, evil ways never tried to pull anything like this. In fact, this is polar opposite of Microsoft. For all of their faults, Microsoft always supported developers. Sure they wanted to sell you Visual Studio, but if you wanted to use Java Swing or GTK or C++ using make, they did not care. Heck, they even weighed down Windows for years and years to maintain backwards compatibility APIs used by 3rd party developers.

Enough negativity... there are many good things about OS 4.0. The most obvious thing is its multi-tasking. To be honest though, it is fundamentally flawed. It is an "OS" feature that is purely designed around use cases. It's like Apple saw ads by Google/Verizon and Palm, that showed users listening to Pandora in the background, or using GPS, or receiving VOIP calls, and told their engineers "Can we do this without really enabling background processing?" Background apps are limited to these use cases: Pandora (music), Garmin/Magellan (GPS), and Skype (VOIP). That is lame. Background apps are also prohibited from networking (wait does this screw Pandora after all?) Better than nothing? Yes, but lame.

As part of this background processing stack, Objective-C blocks have finally come to the iPhone. Yep, that means closures. Of course, it's grafted on top of Cocoa, so that means you can't just take a button and set its event handler to a block of code. But again, better than nothing. Maybe we'll see some Cocoa evolution that will allow developers to take advantage of this.

Back to the meat of the background processing... One of the use cases mentioned above is geolocation. One of the new features added in OS 4.0 is advertising via iAd. As mentioned earlier, this is a clear attack on Google's AdMob platform. The impending explosion of advertising and constantly location-aware applications suggests that location based advertising could also see an explosion. Of course a background app that is location aware cannot make network calls, a prerequisite for fetching relevant ads. Ah, but they have iAd! Apple has positioned itself quite well to take advantage of mobile advertising.

Finally, I've probed the new version of Safari. It's version 532 of WebKit, up from build 528 in iPhone 3.1.3 and 531 in Safari 4.0.4. However, it still doesn't support Web Workers... Shortly after OS 4.0 was announced, Apple also announced WebKit2. This appears to be WebKit built on multi-processing, a la Chrome. No word on when it will come to the iPhone and iPad, but perhaps that is where Apple's efforts are these days.

iPad Web Applications

So you might have heard about this... This Saturday, April 3, there's a new computer coming out from Apple. You might have heard about it. Anyways, lots of iPhone developers have been scrambling to port their iPhone apps or write new iPad apps. A lot of folks have been predicting that developers would start to shun Apple after all of the controversies surrounding iPhone app submissions and the "walled garden" approach that Apple has taken. On the other hand, Microsoft has decided that a controversial walled gardens are once again the way to go, and is diligently copying Apple. Well if the iPad is any indicator, developers continue to agree with Apple and Microsoft. There is a lot of interest in developing native applications for the iPad.

Still, if you're like me and a big part of your job is to figure out how to build web applications for all kinds of devices, you have probably been spending a lot of time trying to figure out what to do about the iPad. On one hand, it's a big enough device that most websites will look just fine on it.

I think you must agree that the above looks a heck of a lot better than a "mobile optimized" site like this:

This seems great at first -- no work! Just make sure that if you are using any browser sniffing/redirecting code that it does not redirect for the iPad. However, there are some disadvantages to this. First, there are some issues with 'normal' sites that will not translate well to the iPad. There is the obvious thing with Flash... There are more subtle things like, "hovers", i.e. mouse-overs. That is when you toss up a UI layer when a user hovers their mouse over a link, or an image, or whatever. These are pretty popular, and they are not going to work on the iPad. Apple has quite figured out how to detect a finger hover... There are other events that are different on the iPad as well. There is also the question of how to best use the real-estate on the device, and the related question of dealing with landscape mode.

I think a lot of sites will look great in landscape mode, but that doesn't mean that they couldn't look better. It might be more optimal to go to a multi-column layout. That could let a site place useful content "above the fold", i.e. visible so the user does not have to scroll to get to it.

There's also the possibility of "embracing the native" on the web. There are a lot of iPhone-optimized websites that do a good job of making their website look and feel like a native iPhone application. Joe Hewitt's excellent iUi JS/CSS framework is an easy way to do this. The iPad has some of its own metaphors not found in the iPhone. Take a look at this native iPad app:


Notice all of those columns? We've kind of touched on that already. Did you notice the pop-over menus? These are likely to be ubiquitous on the iPad. Here is a picture of them from one of Apple's iPad apps, Numbers:

Obviously there is nothing in HTML-land that is quite like that. However, it is certainly possible to craft something similar. In a way, it's kind of like the mouse-over menus that are popular on the web, only the interaction model is slightly different and the UI is definitely more rich than the average mouse-over menu.

So what to do? Just stick with your "normal" site? Develop an iPad optimized site? Tweak your iPhone-optimized site to suck less on the iPad? Tweak your normal site to suck less on the iPad?

Programming and fallacies

Today I read a blog post by @joestump where he attempted to refute claims that Digg had been "doing it wrong" when they could not scale their database and went with a NoSQL attack instead. I'm not going to get into that flame war. I will say that folks at Digg should have expected exactly this kind of scrutiny when they decided to start bragging about their technology decisions. If a company has a technology blog, that is all they are trying to do -- brag. Anyways, back to the blog post... I was immediately disappointed to see that it was riddled with logical fallacies. I see logical fallacies all the time, and sometimes I forget that many folks are actually not very familiar with them. In particular, I would say that programmers are not very familiar with the "formal" concept, despite the fact that programmers tend to have very strong logical reasoning. Here is my attempt to do something about that.

First off, I am not going to answer what is a logical fallacy. You can follow that link, or find many other descriptions and enumerations of fallacies. Instead I want to talk about why programmers may not be aware of fallacies, and why it is important for them to learn about them. I think the reason that programmers may not know much about fallacies is that they are generally taught in classes on writing, public speaking, or debating. In other words, even though these are concepts tied to logical reasoning, including induction and deduction, they are not included in classes on mathematical logic. You cannot generally express a fallacy using symbols and computational expressions. This might lead some to believe that the fallacies are subjective, but this is not really true.

So why are fallacies important if they are not easily expressed mathematically, and thus difficult to represent programmatically? I suppose that if all you do is program on your own, then perhaps they are not relevant to you. If instead you work on a team with other programmers (or non-programmers for that matter,) then you will have ideas that are argued/debated. In this case, you need to understand fallacies -- so that you can express your arguments without committing a fallacy and so that you can recognize when people arguing against you are committing fallacies.

If you have an argument, and you find yourself committing a fallacy, then of course you will want to "fix" your argument to remove the error. This will inevitably draw out the assumptions in your argument, and strip out that which is not essential and true. Sometimes this will leave you with nothing, and you will be forced to question your own argument. Perhaps it was false or more likely mostly based on subjective statements, not fact. That can be a bummer, but wouldn't you rather realize that you are wrong than have somebody else point it out? Or worse, have nobody point it out...

You need to recognize when others are committing fallacies. At the very least you need to strike this from your own mental record of their argument. Does their argument make sense without the fallacy, or is it essential? Of course if you start noticing these kind of fallacies, then you may be tempted to point them out and use that to assert that their argument is false and thus your argument must be right. Oops, you just poisoned the well and committed a false dilemma.

Once you start noticing fallacies, you might notice that people commit them a lot. Sometimes this may seem to be true irrespective of the perceived intelligence of the committers. It is easy to make these mistakes when you are unaware of them. They are also much more common when people are "thinking on their feet." In fact, I had a professor who once joked that those who were good at thinking on their feet, were simply good at synthesizing fallacies. I'm not sure if that is a fair generalization, but you get the point. I think people are also much more likely to make these kind of errors when emotion has entered into the argument. I think that was the most likely case in the blog post that inspired this post.

MIXation Sensation

This past week was Microsoft's MIX conference. I almost went to it, and I would have gone if it was not the same week as my oldest son's birthday. You gotta have priorities. Anyways, the reason I almost went was not because I have suddenly embraced ASP.NET development (even though I must admit my admiration for Scott Gu). No, my interest is all browser related and MIX was browser heavy this year.

On the browser front, the big news was the early preview of IE9. For web enthusiasts, it's fun to wax poetic about the mind blowing speed of V8 or the brilliance of TraceMonkey, but these technologies will always be secondary at best. If you are a web developer the most important browsers are the ones from Microsoft, because they dominate the market. They form the baseline that you develop against. If you want to do something that these browser do not support, you have got to get creative or be willing to live with your work simply being a toy. Simply put, IE9 news is more important than all of the Firefox, Safari, Chrome, and Opera news combined.

Luckily, Microsoft did not disappoint with IE9. It is obviously a far from finished product, and Microsoft was a little too dodgy on sharing its roadmap for my taste, but I can empathize with their position. Still they showed a browser with significant speed improvements and with support for a lot of standards based, visual eye candy. I'm talking about a lot of CSS3 features and most surprisingly, an amazing SVG implementation. They whipped out some classic Microsoft tricks, i.e. using their intimate relationship with their operating system to tap into GPU acceleration. You might think it's not a fair trick for them to do, but who cares? The boys at Mozilla, Apple, and Google have to accept this challenge, even if it will be super painful to pull of across platforms -- and Linux will surely suffer here once again.

I was a little disappointed in some of the other JavaScript features. In particular, I was really hoping that Web Workers would be included with IE9, and I was cautiously optimistic that geolocation would also be included. Neither is included in the IE9 preview that Microsoft made available to developers.

Of course that definitely does not mean that these features are out of IE9. I think there is a lot more to come. Microsoft has done some amazing work to give IE9 a lot of graphics features, but they have left out Canvas. Further intense graphics programming would benefit from the multi-threaded programming model supplied by Web Workers. So it would make a lot of sense for both of these to be added. I'm even optimistic that Microsoft will implement these standards directly, and not offer some proprietary alternative.

All of this makes you wonder about IE9 as a compelling graphics/gaming platform. I think that some serious tooling will be needed to make this viable. That's an area that Microsoft excels at. However, would this not put Microsoft in conflict with their own efforts around Silverlight? It's like the HTML 5 vs. Flash war could be played out in miniature within Microsoft's walls, only it would be IE9 vs. Silveright. Speaking of Silverlight...

The other big news, from my perspective at least, that came out of MIX was a lot more information about the Windows Phone platform. As a mobile developer, I have very mixed feelings about Windows Phone. On one hand, I really like the idea of using Silverlight as the application platform. This is a mature application platform, with fantastic tooling. You get to use a beautiful programming language -- C# (oh an maybe other .NET langs, like F#?) that has a decent runtime that includes garbage collection. However, Microsoft looks like they are copying Apple's approach. A lot of the restrictions being placed on non-Microsoft applications are very similar to the restrictions placed on iPhone applications.

Back to the browsers... Microsoft shipped a preview of tools for building Windows Phone applications. Again, major props to Microsoft for getting this software ready out at MIX, even if it is a little rough in places. I don't like companies using end users as a substitute for QA, but this is different. Getting tools into the hands of developers is critical. In this case, the tools include a Windows Phone emulator, which includes *drumroll please* the Windows Phone browser! As a mobile developer, this is the most important thing that can be included. I'll have to support your browser before I have to support your application platform.

However, the Windows Phone browser is not very promising. It seems to be based on IE7. It does not seem to support many HTML 5 features at all. No geolocation. No local storage. No application cache. No web workers.

Maybe some of these things will be added by this fall, but I'm not as optimistic about this. Even the documentation that is included emphasizes building web applications that are designed to work on legacy browsers. They seem to be saying, don't go looking for coolness in the browser!

Testing Geolocation for Mobile Web Apps

Using geolocation in a web application is really cool. The JavaScript API is quite simple. Testing it, can be a different story. Here are some useful tips:

If you only need to get the user's location once, testing is not too bad at all. First, you can actually use Firefox 3.5+. However, make sure that you are using wi-fi, or otherwise you will never get a location. Your app will just seem to hang. Anyways, being able to use Firefox for testing is great because it is a full desktop browser with awesome developers tools like Firebug. Often you will have some pretty complex JavaScript in a web application that uses geolocation, so being able to debug with Firefox/Firebug is invaluable.

Of course you will also want to test on mobile browsers. You can definitely use the iPhone simulator that is part of the iPhone SDK. Geolocation works great on this, but it gives you a bogus location -- the location of Apple's HQ in Cupertino, CA. If you actually live near Cupertino, this can be really misleading. Anyways, it will only give you this location, never anything else. So it is somewhat limited.

Testing on an Android emulator is another possibility. However, in my experience, it is currently broken. On an Android device, when a web page wants your location, the browser brings up a window to prompt you for permission. On the emulator's browser, I never see this permission window and the app just hangs and never returns a location. That's a bummer, since the Android SDK makes it possible to send mock GPS coordinates to an Android emulator. It would be great if web developers could take advantage of this.

Testing on an actual devices is of course a possibility. Your web application needs to be reachable by the device. This could mean using wi-fi on your device, so you are in the same intranet as your development sever, or it could mean deploying your app somewhere public. I like using the Google App Engine for the latter, and then test on the assortment of devices that I have laying around.

If you need to test location updates, i.e. when the user moves you want your web application to know about it and respond in some way, then things get trickier. The iPhone simulator is out of the question. An Android emulator still suffers from the same problems. So now you are down to devices. There is no way to send mock GPS to an iPhone, so to test on an iPhone, you need to actually change your physical location. Coding and driving FTW!

However, it should be possible to test on an Android device. The Android SDK theoretically allows you to send mock GPS to a real device. The command that should work is "adb -s XXX shell geo fix AAA BBB" where XXX is the serial number of your device (get it by doing "adb devices"), and AAA/BBB are the fake latitude/longitude. Sounds good, right? I tried this on my Nexus One, and got a big fat permission denied. Turns out you need to be root to do this on a real device. Ok, so I rooted my Nexus One. Then I tried it. Result? "gps: not found." Suddenly the gps command was not recognized. So ... coding and driving FTW!

The 0-Guard

Last week I was reading an excellent article by Bill Simmons on the "true" trade value of NBA players. While talking about likely rookie-of-the-year Tyreke Evans, Simmons dubbed him 0-guard. I thought that this was quite clever, and several other players immediately came to mind. Simmons went on to list three other players as 0-guards: Gilbert Arenas, Dwayne Wade, and Brandon Roy. I thought of some others. Here are what I would call the defining characteristics of the 0-guard:

1.) They must have the ball in their hands. These are players who generally useless on offense without the ball. They are not good spot-up shooters. They aren't going to move well without the ball to get open or get teammates open. They generally look lost in a half-court offense if the ball is not in their hands at all times.

2.) They are not good passers. Now many 0-guards rack up a lot of assists. However that is just because the ball is always in their hands. The only way they pass the ball is if the defense is all over them and teammates are wide open, hence the assists. However, they don't always do this very effectively. For example, in his best years Arenas averaged 6 assists/game, but also 3.5 turnovers/game while averaging 21 shots/game and 10 free throw attempts/game. Last year, Dwayne Wade averaged 7.5 assists/game, but that came with 5 turnovers/game, while taking 22 shots and 10 free throws per game.

3.) They can get their shot -- easily. This kind of goes without saying. All of these guys are effective at creating for themselves/getting open off the dribble, around screens, etc. If they couldn't do this, they would not be playing at all. Often they are spectacularly good at this -- Dwayne Wade for example.

These are the three obvious 0-guard characteristics. However, there are some other more subtle shared characteristics.

4.) They are poor rebounders. These guys want to get out in transition, so they do not hit the defensive glass and they make no attempts to box out anyone.

5.) They are defensive liabilities. Sort of a continuation from #4. All of their energy goes into scoring, not much is left for defense. Now some guys may average a lot of steals, but that is a notoriously misleading statistic when it comes to defense.

6.) Point guard size. Maybe this helps to explain #5 and #4, but these guys generally don't have the size to match up against shooting guards. This does not necessarily imply being short -- Wade is 6-4 and Evans is 6-6.

Given the above, I don't think Brandon Roy belongs on the list. For his career he has averaged 5 assists but only 2 turnovers per game, while taking 16 shots and 6 free throw attempts per game. That does not sound like a guy who has to have the ball in hand -- or maybe I'm wrong and he's just not a very good 0-guard. I think Simmons put him on the list because Roy demands the ball in his hands at the end of games.

There are some other obvious guys who belong on this list. Starting locally, Monta Ellis is definitely a 0-guard. This year he has averaged 5 assists / 4 turnovers per game, while taking 22 shots and 6 free throw attempts per game. This is definitely Arenas/Wade country. Brandon Jennings is borderline. So is Derrick Rose, but in both cases these guys are young enough to "grow out of it." Rodney Stuckey is a 0-guard, but not a very good one. Jason Terry also qualifies, but he doesn't realize it. He thinks he can spot-up and shoot, but he can't. 

Finally, I think Bill Simmons got it wrong when he said that Gilbert Arenas invented the 0-guard position. To me, the quintessential and original 0-guard was Allen Iverson. He had a season (01-02) where he averaged 5.5 assists / 4.0 turnovers to go with 28 shots and 10 free throw attempts per game! Now late in his career, he did become a better passer, but was still more of a 0-guard than a point guard.

eBay Mobile for Android

I have been working on mobile at eBay since the fall of 2008. Almost immediately upon joining the team, I started running my mouth about how we needed to create an Android application. At the time, the G1 had just come out, and let's be honest. It was definitely a cut below the iPhone -- the standard that all phones are measured against whether they like it or not. The development environment was attractive, but we had to be pragmatic about things. eBay Mobile for iPhone was a big hit, and we had tons of ides for improving it. So Android had to wait. Yesterday, the wait was over and eBay Mobile for Android became available for download from the Android Market. It requires Android 1.6, and we have not rolled it out in all of the countries that our iPhone app is available in, so depending on your device and your location, it may not yet show up in the Market. If you're on 1.6, just be patient, hopefully we'll be in your country soon. If you're on 1.0/1.1/1.5... well your carrier needs to upgrade you to 1.6 :-)

The app was the result of a lot of hard work by some very talented engineers. If you have an Android phone, then of course I am hoping you will go try it out. One of the cool features of the Android platform that we took advantage of is integration with the system level QuickSearch. This makes it possible for popular search terms on eBay to be automatically suggested to you as type in the QuickSearch box on the home screen of your phone. However, this is one of those kind of curious features in Android. It is relatively easy to do (though making it fast, for something dynamic like popular search terms on eBay, can be tricky -- our engineers did an awesome job on this), but it is not something that you can "enable" by default. What I mean is that any application can become a provider for the QuickSearch box, but the applications cannot get their suggestions to automatically appear. Instead the user must manually enable add the provider, and this is not the most obvious thing to do. To give you an idea, I did a short video that shows you how to do this:

See what I mean? It's hard to expect that most users will figure this out on their own. Maybe we could put some kind of message in the app instructing them how to do this, but it is not something you can really describe succinctly. Anyways, as you see in the video, one you add eBay to your list of search providers, the results from eBay will only appear at the bottom of the list of suggestions. Once again, it would be very easy for a user to not even know that they are there. If they scroll down and find them, and do this a few times, then supposedly Android is smart and starts putting the eBay results closer to the top of the list...

I think this is something that Android could definitely improve on, since I think it is a great idea to allow other apps to hook into the "global" search if you will. I can definitely imagine the Facebook app and various Twitter apps doing this too. However, one could understand if apps did not do this, given how difficult it is for an apps' contributions to surface in the search suggestions.

Nexus One vs. iPhone

I recently purchased a Nexus One, primarily for Android development. I needed a device for developing Android 2.0+ on. The 2.0 SDK has been out for almost three months now, and yet it is still not available for my old developer phone, the Android Dev Phone One. I had gotten pessimistic about HTC making Android 2.1 (since apparently 2.0 is being skipped) for the ADP1, which is essentially the G1, so it was time to buy a new phone for development. I decided to spend some quality time with the phone, i.e. as a user, not a developer, and share my thoughts.

First, a caveat... I plopped in my AT&T SIM card into the N1 before turning it on. That worked just fine -- with some known limitations. By working just fine, I mean that the N1 recognized the SIM card and configured itself for AT&T's APN without me doing anything. This was not the case with the ADP1, which was actually a pain to get working initially. You see, every Android phone that I have used wants you to sign in to Google before doing anything else. This can be a real problem if it cannot use the SIM card to access a data network. Anyways, it was no problem at all for the N1. However, as Google has pointed out, the N1 is not able to access AT&T's 3G network. It does not have the right radio for this. I have no idea why this is the case, but I will say this. Let's just imagine that I loved the N1 so much, that I decided that I wanted it to be my everyday phone instead of my iPhone. Even if that was the case, there is no way I would do this, since I would have to switch service to T-Mobile in order to access a 3G network on the G1, and for me (as well as most iPhone users) that would meaning breaking my contract with AT&T. On the other hand, if Google/HTC had only put the right radio in the N1, so that it could access AT&T's 3G network, then that would not be an issue. I bring all of this up now, because it does make it more difficult to compare the two phones. If you have one phone that is on 3G and another on Edge, you will prefer the 3G one unless the Edge phone is just way better in every other way.

Ok, so the good news is that the N1 is definitely a phone that I could live with. It is fast, I mean really fast. Navigating between applications, applications execution, startup, etc. are all very fast on this phone. I would say it is noticeably faster than my iPhone 3GS. In fact, I did some mini-benchmarking between the eBay Mobile app for the iPhone and our new eBay Mobile app for Android, running on the 3GS and N1 respectively. I put both phones on the same Wi-Fi network for this test. The N1 app was definitely faster than the 3GS app. Now the code is different, as our Android app takes advantage of some the Android features to speed up some common things in the app. Still, the Android app is running in an interpreted environment, the Dalvik VM, not as native code like the iPhone app. So even though it was definitely an apples to oranges comparison, I still found it relevant. Our app on the ADP1 (Android 1.6) was much slower.

The phone is also aesthetically pleasing. It is a pleasure to use. It looks nice. It is incredibly thin. In fact, the iPhone feels very chunky in my hand, after using the N1. Using the phone was very intuitive, but of course I have been using Android phones for over a year now, so I am certainly used to the OS. As a phone, it is on par with the 3GS, which is to say it is ok, nothing to brag about. The soft keyboard is easy to use for me, probably because I am used to using an iPhone. The word suggestions on Android are really nice, and it took me no time to start using them aggressively, thus saving myself a lot of typing.

My favorite part about the phone is the email. We use MS Exchange at work, and I am a long time GMail user for my personal email. With the N1, I could setup both to be in a push mode. On my iPhone, I can only setup one or the other to be in push. So on my iPhone, I have to check my mail to know if I have new GMail, but I immediately know about it on the N1. Also, I think email for both of my accounts looks better on the N1.

However, this brings me to a negative for the N1. It will connect to our MS Exchange server with no problems and can sync both email and contacts from Exchange, but not calendar. I have been told that this should be possible, but all solutions I have seen involved either 3rd party software, or using a workaround like syncing my Exchange calendar to a Google calendar first, and then syncing the Google calendar to the N1. I don't want workarounds, I just want something that works easily, so this is a huge negative for me. When I am at work, I often go from one meeting to another, and it is invaluable for me to be able to look at my phone to know when/where my next meeting is.

Speaking of apps, the Android Market is growing rapidly. The Facebook app for Android is very nice, and its use of the OS to allow you to integrate your friends list with your address book on the N1 is excellent. There are a lot of Twitter apps for the N1, I personally liked Swift. There are a lot of other quality apps out there as well. Here is a handy equivalency table of apps between iPhone/Android from Alex Payne. Still, this is definitely an area where the iPhone has a huge advantage. For me, the advantage is most pronounced for games. There are so many more games on the iPhone, with more well known titles (often backed by big companies like EA.) Also, the games seem to be much higher quality. The number/quality of titles will likely improve over time. Hopefully the quality of the games will too. Perhaps this is an area where the Dalvik VM gets in the way, though you can certainly go native for games, potentially reusing code developed for the iPhone.

A couple of more things, both good and bad... The browser on the N1 is excellent, definitely on par with the iPhone's. That is both from a user perspective and a developer perspective. Having multi-touch in the browser makes a huge difference for users. Adopting HTML 5 standards makes a big difference for developers. I never saw any pages that rendered noticeably differently on the N1 than they did on my 3GS. Usually it was the same only faster. Overall the browser, like most other things, tend to look better on the N1 than the 3GS simply because the screen is so much better... On the downside, the camera was a little more inconsistent for me on the N1. There have been times where I took pictures on it that came out completely out of focus. They certainly did not look out of focus when I took the picture. Maybe this is bad luck. The N1 has a 5MP camera, but I would not say that rates it above the 3GS. Don't get fooled the megapixel myth. I think pictures on both cameras were of similar quality -- except when the N1 would get things out of focus. The flash on the N1 seems useful however.

So there it is. If I lost both of my phones and AT&T cancelled my contract, it would actually be a tough decision between the 3GS and the N1. I would go with the 3GS because of the calendar issue and its big advantage in number of apps/games available for it. The calendar issue seems like an easy issue to address, and the apps/games discrepancy is become less pronounced. It's not like the Android Market needs to have parity with the App Store, at least not in terms of quantity. Also my issues are far from universal. So I could definitely see a lot of people picking the N1 over the 3GS.

The Anti-Netbook

For Christmas this year, I bought my kids (ages 4 and 5) their first computer: an Acer Revo. I call this the anti-netbook, but it actually shares a lot of things with a netbook. First is its processor, an Intel Atom clock in at 1.6 GHz. This helps to make for an incredibly small form factor, especially for a desktop computer. It has a 160 GB hard drive, but no optical drive.

When I bought the computer, I had exactly one reason for it. I wanted my kids to play educational games on it. That was all. The Revo came with Windows XP installed on it, and this was perfect. I needed Windows on there to get the largest number of potential games for it. Windows 7 seems to be much less of a resource hog than Vista, but I am still wagering that XP comes with less overhead.

I had another somewhat unusual plan for the Revo. It is completely isolated. No network access, not even local intranet. This is why I call it the anti-netbook. I want no Internet on it, I only want software that I personally installed to ever run on it. It is like a miniature Battlestar Galactica. Now I know there are a lot of websites with great games for kids, but I don't need them. I can find plenty of shrink-wrapped software to buy at incredibly cheap prices. However, this did lead me to some problems with the computer.

The first problem was how to install all of this software, since I had no optical drive. I was prepared for this. I simply copied the software to a flash drive and plugged that into one of the four USB ports on the Revo. This is where I encountered my first problem. Many of these titles require the original CD to be inserted into an optical drive in order to run the game. I suppose this is an anti-piracy tactic, but it really caused me problems. For a couple of the games, I could leave the flash drive plugged in and they were happy. This did not work for most of the games.

So I bought an external optical drive that could be connected via USB. This worked perfectly well, but it does mean that to change the games, one has to generally change discs in the external drive. This is not something that I trust my kids to do yet... I had one more nasty surprise in store for me. Many, actually most games published these days require the game to connect to the Internet, either to install or to play or both. There was a PBS Kids game we bought that was like this, and it was complete fail when we tried to install on the anti-netbook. So I had to make sure to only buy games that did not explicitly list an Internet connection as a hardware requirement, which generally meant buying a lot of older games. Still I found plenty of such games to choose from.

At some point I will want my kids to be able to do more with a computer. They will need a word processor. Of course I would like to teach them both to program. I would like to get them something like Mathematic/MatLab. And of course by then, they will need a computer that is connected to the Internet. When that day arrives, I will get them a Mac -- but probably not an iPad. I will teach them the old school ways!

The Truth About Europe

Earlier this week I read yet another fascinating post by Peter-Paul Koch. In this post, @ppk takes on developers who think that developing for mobile just means developing for the iPhone. He points out that the iPhone has a small market share, in terms of number of devices being bought or in use. He tackles the obvious counter-argument that the iPhone dominates in terms of mobile Internet usage in the US. In particular he points out that the US does not matter, since Asia and Europe account for a much higher percentage of mobile users worldwide. He is completely right, but if you are a mobile web developer, these facts are completely irrelevant.

It does not matter how many mobile web users there are in North America, Asia, or Europe. This has no bearing on how you design your site or what kind of technologies you choose to adopt. All that matters are the users of your site and what kind of devices they use. There can be 100x more smartphones in Japan than in Spain, but if all of your users are in Spain, then you should not care about Symbian's market share in Japan.

For a lot of sites, it is very easy to figure out where their users are because they are not localized. If your site is focussed on Brazil, then it's a good bet that most of your users are in Brazil. For sites that are international, things get trickier. This is a problem that I have had to deal with at eBay. Fortunately my job was easier because we already had a mobile site that was setup almost ten years ago. It is designed to support all devices, from old school WAP devices all the way up to iPhones and Droids. It has a presence in all of the countries where eBay has a presence. So there I had a lot of data to use where I could say "this % of our users are using iPhones, this % are using Blackberries" etc.

Most people do not have this luxury. If you do not have a specialized site for mobile, you can still look at your server logs and figure out what mobile devices are being used to access your site. However, you should be cautious with this data. If you do not have a specialized site, chances are your main site does not work properly on a lot of devices (especially true if you use a lot of JavaScript.) So chances are your users that use those devices will not use your site from their devices. However, chances are that your site does work properly on an iPhone, even if it is far from optimized for it. So iPhone users may be over-represented in your data.  You might want to fall back to using X% of users are from A, Y% from B, and the devices breakdowns in A and B are... Now if your site relies on Flash...

Let's get back to the @ppk's post and the iPhone for a moment. He makes a nice analogy to IE6 back in the day. When doing analysis on mobile eBay traffic and our strategy for the future, I actually made a similar analogy. There is one huge difference. The iPhone's browser, Mobile Safari, has been a front-runner in adopting HTML 5 standards. If you are optimizing for the iPhone, there is a good chance that you are in fact using HTML 5 standards. In other words, optimizing for the iPhone does not mean adopting a plethora of technologies that are proprietary to Mobile Safari. It's just the opposite in fact. This is the fundamental difference between Mobile Safari today and IE6 circa 2002. That is not to say that there aren't some technologies that are unique to Mobile Safari. There are. However, those are the exception, not the norm. Most of the code that you could write for Mobile Safari that would not work on other mobile browsers is actually standardized APIs that other browsers simply have not yet implemented. So yes, you could be excluding users -- this is where you need to figure out what devices your users are using -- but you are not putting up an iPhone-only wall. You are putting up a wall, but it is a "modern device that supports web standards" wall.

On Open Floor Plans

Way back in 2006, I was working for a startup, originally called Sharefare and later renamed to Ludi Labs. When I first joined Sharefare, we had an old office space in Los Altos. It was a "traditional" office space, divided up into offices, with only two large open areas. One was the front reception, and other was a break room area. While there, we had around ten engineers. We would put 2-3 engineers per office. It worked pretty well.

After I had been at Sharefare a few months, we received another round of funding, but it came with a catch. Our board wanted us to hire a "real" CEO, since our CEO/founder was a very technical guy, not an MBA type at all. Our CEO came from Under Armour, you know the sports apparel maker. He was an east coast guy, who I'm sure we paid a ton to relocate to the Bay Area. When he arrived, we were running out of space in our little old office in Los Altos. So he decided that one of his first priorities would be getting us a new office. He had a vision for the new office -- the floor of the Wall Street stock exchange. He wanted an open floor plan that would encourage collaboration and keep everyone energized. So we moved into a brand new office (we were the first tenants) with a completely wide open space.

Now I always attributed this hubris to our CEO being an east coast guy who had never really been around engineers. You see, engineers do not work well in hectic, loud environments like the floor of the Wall Street stock exchange. A very large part of their job is thinking, and people running around making noise does not help an engineer think. Lots of other folks have written about what kind of environment does work well for engineers, so I won't go too much into it. I'm just here to tell you what does not work.

The open floor plan is complete fail. The most obvious problem is the noise. First, most companies have some non-engineers who work for them. Some of these non-engineers really need to do a lot of talking to do their job. They need to be on the phone ordering office supplies, or talking to potential business partners, or screening new hires. These people constantly generate noise. Put that in an open floor plan, and there is always noise. This is a constant drain on other folks, like engineers and designers, whose work requires them to think a lot.

The next problem is that engineers and designers, do indeed need to talk sometime as well. Sometimes this is talking about work stuff, but there is also a lot of non-work stuff that engineers talk about. Maybe they are debating closures in Java or the merits of Python vs. Ruby. You want engineers who bullshit about stuff like that. Or maybe they are just talking about the Super Bowl or Lost. There is value in this too (y'know that whole "team building" thing.) Anyways, when you are in an open environment where noise is already problem, then it really discourages this kind of engineering conversations. If you are lucky enough to need to talk to your fellow engineer when it is relatively quiet in the office, you may be reluctant to engage him/her because you want to relish the peace. If instead it is during a typically noisy time, you will ask yourself if whatever topic is really worth talking about if it means shouting over the din. Instead of encouraging collaboration, the open floor plan does the opposite.

Back to Sharefare... It did not take long for everyone to realize that the open office was not working. First, we tried to put the engineers and non-engineers at opposite ends of the office. We had a handful of real offices that were intended for execs. Instead they were kept open, so that people could use them for longer phone conversations. I personally spent a lot of time in those rooms, doing phone interviews with potential new hires. Finally, the CEO came clean and admitted that the whole thing had been a bad decision on his part. He bought everyone Bose noise canceling headphones, supposedly out of his own pocket. This was his high point of popularity with engineering. Now when you walked into the office, everyone constantly had the Bose headphones on. I think this also hurt collaboration. I know I am personally less likely to try to start a conversation with somebody with headphones on.

Anyways, that was our failed experiment. It seems like the idea has been picked up more and more in the Valley. A lot of companies are opting for this configuration. I think some do it as a cost cutting measure. You can spend a lot less on furniture with an open floor plan, and you can pack in a lot more people in a given space. Others claim that it is all about encouraging collaboration. Again, my experience is that it will do the opposite. Still others do it because they want to break away from the traditional cubicle environment. To those folks I would say: "function over form." An ugly office full of productive engineers is better than a stylish office full of miserable engineers.

It's 2010, where's my HTML5?

This morning, one of my co-workers related to me that there had been mention of HTML 5 on an NPR broadcast that he heard. He joked that this morning there were probably lots of advertisers asking their designers about using HTML 5 for their next whiz-bang ad campaign. So obviously we are still in the early part of a hype cycle on HTML 5. So what's the state of the technology and where is it heading?

In terms of pure technology, there is a lot of notable progress. Google did the right thing recently and axed Gears. They had some nice innovations in Gears that have since been rolled up into the HTML 5 standard. Now it makes perfect sense to abandon their proprietary implementation, and embrace the standard. Gears is important because it is (or was) part of Chrome. Thus there are essentially five browsers that now implement a significant subset of HTML 5: IE8, Firefox 3.5, Safari 4, Chrome 4, Opera 10. According to the latest browser share numbers, that means that 53% of users out there are using a browser that supports a lot of cool features, like local storage and selectors. That's more than half! It's tempting to extrapolate from that, but don't get too carried away.

The #1 browser of the HTML 5 browsers, is IE8 -- which does not support a lot of the features that the other browsers support like canvas, video tag, and web workers. For those would be HTML 5 advertisers out there, you better scale back your expectations. For desktop browsers, a lot of the most compelling HTML 5 capabilities are far from being widely supported. How long until IE9 comes out? How much more of HTML 5 will it support? How long until there is high adoption of it? That's too many questions to be comfortable with. Ask me again this time next year.

However, it's fun to pretend sometimes. Let's pretend that IE 9 did come out soon and that it supported everything supported by Firefox and Chrome. Let's even pretend that Microsoft was able to awaken some of their old monopolist mojo and somehow force people to upgrade. So we have a world full of canvas. Will the next great annoying ad use this? If you read my last post on Flash hate, you probably realize the answer is no. As Terry pointed out in the comments there, the Flash authoring tools really empower designers over developers. So before we see an explosion of canvas magic, there will have to be huge strides made in tooling. Now what about video? Even in our dream world, there are issues known as codecs. There is no common video format that will run on both Firefox and Chrome right now, and who knows what Microsoft will do here (WMA FTW!) So we are going to need some technical consolidation here. Let's summarize all of the things that we need to see happen to open up the golden age of HTML 5.

1.) New version of Internet Explorer that supports much more of the HTML 5 specification.
2.) This new version of IE needs to become the dominant flavor of IE.
3.) Outstanding tooling developed to enable designers to leverage HTML 5 capabilities.
4.) Standardization on video codecs by browser vendors.

Don't get too bummed out about all of this. I actually think there is real progress happening on #1 and #3. #4 probably has to wait for #1 to happen. #2 is the most problematic. Since we're dreaming, maybe if IE 9 came out with H.264 support, Google could dramatically drop support for anything else on YouTube, and thus nudge all IE users to upgrade?

If you want to drink the HTML 5 Kool-Aid, and this is bumming you out, I'm sorry. You might feel better to know that the HTML 5 situation is significantly better on mobile devices. According to AdMob, 81% of internet usage in North America was either on iPhones or Android devices. Now, most of those Android devices are running Android 1.5 or 1.6, whose browsers (can we call it Mobile Chrome please?) still use Gears -- not HTML 5. Let's  hope that most of those are upgraded (by their carriers) to Android 2.1 soon, and then we're in business. We've got all kinds of HTML 5 goodness available to 80%+ of the users out there.

The bad news is that the mobile market is fundamentally different than the desktop (though, that may be changing.) Here mobile websites compete directly against native applications. Desktop users rarely face the question, should I use an app or a website to do XYZ? Normally XYZ dictates one or the other. So for a company, there may be a lot of cool stuff you can do with HTML 5 on a mobile browser, but there are even more cool things you can do in a native app. Not only are the native apps more powerful, they are generally easier to build because of superior tooling and cohesive architecture. Maybe JavaScript vs. Objective-C vs. Java is a matter of taste, but HTML 5 has nothing even resembling the application models presented by Cocoa and Android. Instead it has the DOM APIs in JavaScript. Now throw on the differences in tooling, and you can see why for many companies it is cheaper and easier to build an iPhone app and an Android app instead of building one HTML 5 app. That's not even considering the hypothesis that the "app store" model is more appealing to end users than the browser model.