The Tablet Wars Have Begun

A few weeks ago I picked up a Samsung Galaxy Tab. Being an Android developer, I thought it was a good idea to see how my apps as well as other apps function on the Tab. After all, it’s hard not to remember what it was like for iPhone developers when the iPad came out. iPhone apps run on the iPad, but they are virtually unusable. They either look ridiculously small, or you can “2x” them and they look like crap. So there was (and is) a lot of pressure on iPhone developers to port their apps to the iPad. Would the same thing hold true for Android developers and the Tab?

I am pleased to say that this is not the case for the Galaxy Tab. Most Android applications look good on the Tab. In fact, I would say that most of them look great. The extra real estate only adds to things. Now there are cases where the apps could make better use of space, or maybe their buttons look a little too big on the Tab. However these are minor issues compared to what it is like to run an iPhone app on an iPad.

That being said, there are some apps that suffer on the Galaxy Tab. Notably some popular weather apps (The Weather Channel’s app, Weather Bug) looked bad on the Tab. However in subsequent weeks these apps have released updates that now look good on the Tab. During that time ESPN’s Scorecenter app also released an update. The previous version of the app looked fine on the Tab, since it relied heavily on ESPN’s mobile website. The update brought a more native UI with less reliance on mobile web. However, it has some serious layout issues and looks bad on the Tab.

So why is it that most apps look good on the Tab, but a few do not? Is it something inherent to Android vs. iOS? Well, yes and no. It is not really anything inherent to Android the OS or Android the SDK. However, Android is designed to work on different sized screens and always has been. As a developer, you are given many choices for creating the layout of your UI, but you are encouraged to use relative/flow-based layouts. These are fluid and resize beautifully on different sized screens. So you take those apps and drop them on to a tablet, and they look just as good.

Of course you don’t have to use these kinds of layouts. You can use layouts that are more fixed and absolute -- which is the norm for iOS developers. However, then you run into Weather Bug and ESPN style problems. Their developers can make adjustments to make their apps look good on tablets, but they may find themselves doing this again when ten-inch tablets start showing up.

I think the fact that most Android apps run seamlessly on the Tab is a significant selling point of the device. If you have 200 iPhone apps, chances are that either many of them will not have been ported to the iPad, or if they were, then it will be as a different app (Blah blah blah HD!) that you will have to purchase. If you have 200 Android apps, then you are good to go on the Tab.

The Tab has a few other advantages over the iPad. The one most people talk about is that it is more portable. This is not a small advantage. I just got back from a trip to Portland. When I’m there, I often like to go to the Starbucks near Pioneer Square to get tea and a scone for breakfast. One time I took my iPad with me, because I wanted to read blogs or news, catch up on Twitter and Facebook, etc. while I ate my scone. However I didn’t like having to carry it, and it was especially inconvenient once I got my tea and scone (3 items, 2 hands.) So I took it with me one time and never again. Instead I would just use either my iPhone or Nexus One. However this time I had my Tab and I always took it. Even with it raining, I could just put it in the inside pocket of my jacket and it was no trouble at all.

Then there is the related issue of weight. I have often read books (via the Kindle app) on my iPad while on airplanes, or at a café, or just around my house. The iPad always makes my wrist very tired, and I find myself switching hands or trying to awkwardly prop it up on something. The Tab is so much lighter that this is never a problem. I am currently reading Stephen King’s The Waste Lands on the Tab (also via the Kindle app) and have had no problems with my wrist tiring out.

I would say that the above three things are the major advantages of the Galaxy Tab over the iPad. Android apps work much better on it than iPhone apps work on the iPad; it is portable; it is much lighter. There are some other things too, like it having two cameras instead of zero, or being available on Verizon, T-Mobile, etc. Just to be fair though, the iPad still has some significant advantages over the Tab.

The bigger screen is obviously the biggest advantage. This really opens up the iPad for a lot of experiences that aren’t possible on the Tab, or would suffer. Also, it makes using non-mobile optimized websites much better on the iPad. For example, ebay.com is pretty usable on the iPad. On the Tab, it is ok in landscape mode, but definitely not in portrait. So I would not really consider using it on the Galaxy Tab, but would on the iPad. Of course there is still a decent chance that a non-mobile optimized site is going to have problems on the iPad still.

The bigger size of the iPad also leads to a larger battery. To me the battery life of the iPad is amazing. I do not use my iPad that much, so often it will go many days on standby. It blows me away how little battery is drained from say five days of standby. I have the non-3G iPad, so that makes a big difference, but still you just cannot beat the battery life of the iPad.

Big screen and big battery are big advantages. However if you want to watch TV & movies on your tablet-of-choice, then the iPad has an even more bigger advantage: iTunes. There is no good way to download a movie and watch it on your Galaxy Tab. I think we will see Netflix on Android and thus the Tab in the next few months. That will help, but Netflix’s streaming selection is still very limited. However, iTunes has an excellent selection. I would guess that we will also see Amazon’s Video-on-Demand on Android, since it is on the Android-based GoogleTV. That will help with selection as well, but still it will fall well short of what’s on iTunes. Plus any streaming solution is more limited than iTunes buy/rent model. Not to mention that there is already a Netflix iPad app, and it would be shocking if Amazon didn’t have a VOD app for the iPad sometime next year as well. If you want to watch TV shows or movies on your tablet, the iPad is definitely the way to go for the foreseeable future.

Based on the above, if a friend/family member asked me if they should buy a Galaxy Tab or an iPad I would ask them three questions:
1.) Do you plan on using it primarily at home/office, or do you want to take it with you when you are out or traveling?
2.) Do you use a lot of apps on your phone?
3.) Do you want to watch TV shows or movies on it?

Regardless of how they answered these questions, I think that a tablet like the Galaxy Tab or the iPad can replace a laptop for most people, but not everyone. If you are a heavy user of office-apps (word processing, spreadsheet, presentation software), then a tablet cannot be your primary device. I think the new MacBook Air is perfect for such folks. This is also a space where the ChromeOS netbooks have a chance to compete, as well as traditional Windows-based netbooks. If you do more “creative” activities, like graphical design, photography, and of course programming, then you need a real machine with serious RAM & CPU. That’s why my MacBook Pro will remain my primary machine for a long time. A tablet will always be complementary for folks like me. That’s why I think the portability and lightness of the Galaxy Tab outweighs the bigger screen and battery of the iPad for people who really need a laptop or even a netbook.

C2DM on older versions of Android

Back in May, I made my Android Wish List. The #1 item on my list was push notifications. The Android team delivered in spades with Cloud to Device Messaging. C2DM is much better than push notifications as they exist in the iOS world, because the user does not have to see the message being pushed. Instead your app can have a background service process the message and decide if a notification should be shown or not. That allows apps to receive many more types of events from the cloud, since they don't have to worry about bothering the user (or the user just ignoring the event.)

Of course there was one obvious downside to C2DM: it required Android 2.2. This is obvious, but is a bummer since it meant that developers needed to wait until 2.2 adoption became very high before they could start using C2DM. Here we are six months later, and only about half of all Android phones in use are running 2.2 (for the US, this is lower in other countries.) Who wants to ship an app that can only reach half of the universe of users, or update an existing app if half of your loyal users will be left in the cold?

This is definitely one of the places where you have to envy the iPhone. When iPhoneOS 3.0 came out, the adoption curve was pretty fast, even though users had to hook up their phone to iTunes. The reason for this was simple: OS 3.0 was available on all iDevices, and it was immediately available to everyone via iTunes. On Android, updates are pushed out over-the-air, which is great. However, it is up to vendors to do this. Plus a specific flavor of Android must be made for each Android device (this is true of iOS as well, but there are a lot less devices), and sometimes an update is not made for some devices for whatever reasons. For example, there are a large number of devices out there running Android 1.6 that will never be updated to Android 2.x.

Don't get so down though. The point of this blog post is that all is not lost with regards to C2DM. It is actually entirely possible to add C2DM to your application, even if your application is compiled at API level 4 (Android 1.6.) Actually, it would probably work against API level 3 (Android 1.5), but there aren't too many of those devices out there. The key is that the way that you communicate with C2DM is through Intents, no 2.2-specific APIs needed. Let's take a look.

First things first, you still need the proper permissions and receivers setup in your manifest. In particular you need a BroadcastReceiver that receives Intents with an action of com.google.android.c2dm.intent.RECEIVE or com.google.android.c2dm.intent.REGISTRATION. The names of actions are not constrained in the manifest schema, so that you can use custom/application actions. Thus this causes no problems on devices not running Android 2.2. Check out the official docs for all of the gory manifest details.

Next, your application needs to check if the device is running Android 2.2+ or something older. If it is, then you can register for C2DM. Here's how you check:

if (Build.VERSION.SDK_INT >= 8){
    registerForC2dm();
} else {
    // continue to use your pre-C2DM solution here
}

The only thing hacky here is that normally if you compare Build.VERSION.SDK_INT to something, it would be a defined constant like Build.VERSION_CODES.FROYO. However that constant is not available in Android 1.6, so instead we use its value of 8. I sure hope that constant doesn't change in future versions of Android!

Finally, you need to handle the registration and message Intents that C2DM will send you. Again, you are just specifying a string for the actions on these Intents, so no API dependency. That's it! No reflection, no compile against API level 8, but declare you only need level 4 hack (as is commonly done to enable an app to be installed on the SD card.) I've tested this approach on a device running Android 2.2 and on a device running Android 2.1. The 2.2 device gets C2DM messages, just as you'd hope, while the 2.1 device simply ignores the C2DM code and is unaffected.

Android Love

My colleague David Beach recently penned a great post about developing apps for Android. If you haven't read it, go read it now. Seriously. I know a lot of you will see that he's a product manager and stop right there, but get your lazy ass back over there and read it anyways. Look, even TechCrunch picked up his post. Ok I know that might actually be a disincentive for some of you, but still...

Anyways, I want to make a retort of sort to Beach and talk about why I love Android. However, I have to start by making a confession. My go-to phone is my iPhone 4. So why would I, an Android fanboy and somebody who is writing a book about Android development, use an iPhone 4? The answer is really quite simple. The apps are better.

My secondary device is a Nexus One, and I use it a lot. I would say I use it about 30-40% of the time. Many of the apps that I use a lot are available on both: eBay, PayPal, Facebook, Twitter, Foursquare, Yelp, Urban Spoon, Bank of America, Bump. However, in almost all cases, the iPhone app is just a lot better. This is definitely the case for the eBay app. It is most obviously the case for Facebook, which often dumps you off to their mobile web site to do things that you can't do in the app, even though you can do them on the iPhone app. The one app that I would say more than holds its own is the Twitter app, but even there I miss the conversations feature on the Twitter app for iPhone.

It's understandable that the apps on the iPhone are better. In many/most cases, these apps have been out 1+ year longer than their Android equivalents. So they have more features, less bugs, and are more refined in general. Further, most companies have a lot more iPhone users than Android (this is obviously changing), so they are going to invest more heavily in iPhone development. You probably want your best developer working on your iPhone app. Then again, Joe frickin' Hewitt is doing Android development now, so the developers have arrived.

I went off on this little tangent because it actually brings us back to the original topic. I use an iPhone still because its apps are better. I claim that the apps being better is mostly because of the head start that the iPhone is still enjoying. However, you could definitely infer from Beach's writeup (you did read it, right?) that it is easier to develop a great app for the iPhone than it is for Android. Heck, of the apps I listed earlier, the one that holds it own is the Twitter app. This is an app that was largely developed by Google -- who has to scratch their Android itch by developing 3rd party apps, because they largely focus on mobile web apps instead of native apps despite their ownership of the Android platform. Maybe all of us 3rd party developers have no chance of developing a great Android app because it is just too hard?

Obviously I do not think this is the case. The challenges that Beach lays out are absolutely spot on. For designers, there is no HIG, it is very much a free-for-all. I would add that the default controls and themes are also poor. You simply must do some significant styling to your app or it will look like ass. I think some/all of this will be addressed with the Gingerbread release. It is fair to say that Apple would have never gone this route, i.e. wait until the 3.0 version of their software to focus on user experience. That is fair, and since we haven't seen Gingerbread yet, maybe it will continue to fall short. Even if you can't rely on the OS+SDK to make your app look spiffy, you can still do it yourself. It's not that hard. I mean, it's not like you have to re-invent the button or something. It just takes some experience and knowledge of what is possible with Android.

Once you get past the eye candy, many things about Android development are actually quite nice. The development environment is excellent. Yes, there will be people who just don't like Eclipse and thus ADT, just as there are people who just don't like XCode. However, ADT's capabilities are quite advanced. One common complaint I have heard is about the amount of time that it takes to start an Android emulator image. This is contrast to the iPhone simulator, which starts up rapidly. However, if you consider that the Android emulator is an actual virtual machine being booted up, and not a shell that is simply relying on the underlying computer, then this is understandable. The advantages are obvious. Most apps run slower on the Android emulator than on a real device. The only advantage they may have over a real device is the network speed, but even this can be easily throttled to emulate edge or 3G conditions. If your app runs fast on the emulator, it is going to run great on a real device. You just can't say this about iPhones apps running on the simulator.

Going beyond the tools, Android is a more advanced operating system, at least from an application developer's standpoint. It lets you do things that are just not possible on the iPhone. The obvious thing here is multitasking. With Android's background services, you can always have the latest data from a remote server and never have to wait for it when your application launches. Imagine if you had an up-to-the-second Twitter stream always waiting for you before you launch the Twitter app. It is possible on Android. It is not possible on the iPhone.

It doesn't stop there. Communication between apps is formally supported on Android (though it could be improved) and can only be hacked on the iPhone. How many apps do you have that have some kind of "post it to Facebook" feature? Wouldn't it be great if you could just use the Facebook app to handle this -- thus no need to re-enter your Facebook name/password? It is possible on Android. It could sort of be hacked in a limited way on the iPhone, but it is not going to be pretty or seamless.

These are just a couple of examples. My point is that even though the UI/UX issues on Android are significant, they are not insurmountable. Once you get past them, the other advantages of Android are even more significant. As Android apps mature and Android developers mature, we should see the day where Android apps are better than iPhone apps. I don't think that day is too far off. Now would that counter-balance the arrival of the iPhone on Verizon and other carriers? I think so.

I will conclude on a more personal note once again. I work with all of the mobile teams here at eBay, including our iPhone teams. I've had a much more involved role on our Android app for awhile now, and I want it to be one of the first examples of an Android app that is significantly better than the iPhone equivalent. That's not because I'm an iPhone hater (though I'm sure we'd all agree that competition is a very good thing)  or something, it's just because I think that by fully tapping the capabilities of the Android platform, we can deliver something incredibly useful to our users. Mobile software development is an amazing experience. Our users get to connect with our software in a much more personal way. Our software literally runs in the palm of their hands. That's a remarkable place to be. Right now I think Android is the platform that can deliver the most in that place, and I'm going to put my money where my mouth is.

Phone Number Fixer: The Glory and The Shame

A couple of months ago, I wrote a little Android app called Phone Number Fixer. I wrote this for my friend Maria, but decided to put it on the Android Market for free. Since then it has a decent number of downloads, around 1000, and had several good reviews. However, recently not only did its number of downloads jump up, but it started getting some poor reviews. The reason? The Samsung Galaxy S.

I have to admit that I had not been impressed with Samsung's previous efforts in the Android world. They seemed like decent "second-tier" phones. They were not in the same class with the Droid, Nexus One, or the MyTouch. Now the Galaxy S has come out, along with several other notable Android phones like the Evo, Droid X, and soon the Droid 2. I must admit to paying more attention to those phones than to the Galaxy S. However, it looks like Samsung has a winner on their hands.

The Galaxy S is available on both AT&T and T-Mobile. On AT&T it is known as the Captivate, and on T-Mobile it is known as the Vibrant. I think this is the first time that AT&T has carried a top-of-the-line Android phone, i.e. a phone that is a significant competitor to the iPhone. Of course we all know that the iPhone is coming to Verizon, so this should be no surprise (Big Red is getting the Galaxy S too, as is Sprint. Hey isn't that everybody in the US?)

Anyways, it seems like there are a lot of existing AT&T or T-Mobile users who are buying the Galaxy S. Of course they just want to take their SIM card from their existing phone (maybe even from their old iPhone?) and plop it into their new Android phone. That's when they run across the contacts-imported-from-SIM card problem that my little app can help fix. However, apparently there is something different about the Galaxy S. Not only is the phone immune to the power of the Phone Number Fixer, it even causes the app to hang and crash.

Unfortunately I do not have a Galaxy S of any sort, so I cannot test against it. I know the Fixer works fine with a Nexus One, Evo, G1, and a Droid, and I did not get any negative reviews until the Galaxy S. So I think there is something unique about this device. Once I get my hands on one, I will fix the problem. I am really curious to see what the cause of the problem is.

A Tale of Two Mice

For a couple of years now, I have used a Logitech V470 mouse. It is a laser mouse that uses bluetooth. I've used it with a black MacBook and two MacBook Pros and it has always worked perfectly. The only negative I could ever give it is that it is a little small for my hand (but I have large hands, I wear x-large gloves.) However, years of heavy use have taken their toll on the mouse, and I decided it was time to replace it.

This picture shows the V470 in the front, and its replacement a Targus AMB09US which they call "Comfort Laser Mouse." Why did I pick the Targus? Well it is also a laser mouse that uses bluetooth. I read many a rave review, so I figured it was just as good of a mouse as my V470. It is a bigger mouse, as manufacturers have started realizing that just because I want a bluetooth mouse does not mean that I want a "travel" (small) mouse. However, after several weeks of use, here is what my desk looks like:

Yep, the old V470 is back, despite being chipped and have plastic peeling off of it. The Targus mouse is just not as good for several reasons. Its interaction with my MacBook Pro is buggy. Often the cursor on the screen does not change as it should (imagine web pages where you don't get the little hand to indicate a link). The sensitivity of its sensitivity is way too high. What I mean is that a slight adjustment in sensitivity has huge effects. It is either sluggish or spastic. I've tried adding a mousepad to the mix, but it only helped a little. Finally, it does weird things when interacting with OSX. I hide my Dock on the left of the screen. If I put the cursor over there, then the Dock appears as it should. However, if I roll over items in the Dock, they are not magnified as they should be. I can still click on them, but this messes with me and makes me think too much when I just want to launch something from the Dock. Also, I actually missed horizontal scrolling with the V470. Its wheel could move left/right to allow for horizontal scrolling. The Targus mouse does not have this feature, and I didn't think I'd miss it. However, I did not realize how often I actually used this, especially in Aperture and OmniGraffle.

Now I know that many/most of these problems may have as much to do with OSX as with the Targus mouse. But I don't care. I'm not going to switch operating systems. Instead I will switch mice. I'd really like to get a larger version of the V470, which is why I have not just bought a new V470 and continue to use my old beat-up one. At some point I will probably give in and just buy a new V470.

LBJ, Cleveland, and Miami

I was one of the millions who watched Lebron James announce that he would play for the Miami Heat next year. I have to say that the aftermath of this has been one of the most entertaining non-sports things in sports I have ever experienced. Where to start...

1.) To all of the people complaining about what an egotistical p.o.s. Lebron is for having the TV special: take a look in the mirror. Did you watch it? If the answer is yes, then shut up. You created the market for his ego, and he was simply smart enough to milk it for what it's worth. Good for him. So why are you bitter? Maybe it's because you didn't like The Decision (and I'm not talking about the TV special.)

2.) To Dan Gilbert, owner of the Cavaliers: thanks for playing! I want to tell you to grow up and stop acting like a fool, but that would be dumb. No, you've made this whole thing so much more enjoyable with your childish antics. Please continue.

3.) To the Cavaliers fans: I'm sorry, but what did you really expect? Your team has bumbled this whole thing. The kind of overpaid, underperforming players that your team has continuously brought in to try to Win Now has been predictable and pathetic. The Cavaliers as an organization is weak, and has been for years. The only reason they got Lebron seven years ago was because they lost a lot of games in the right season. Yay. They've needed a coach who could get the most out of Lebron's unprecedented talents, and that has not happened. Instead everything has been done to appease Lebron, and you see how that works out. If the Cavs had had a coach who moved Lebron to point-forward (preferably playing the four-spot), posted him up on 2/3 of the plays, and told him never to take a 3-pointer unless it was to beat the shot clock, would Lebron have stayed in Cleveland? Who knows, but I think the Cavs would have won more games, especially more playoff games. That might have lead to a championship, and that probably would have made it harder for him to leave... All that being said, I still feel sorry for Cavs fans just because of the TV show. I think that would have made me physically ill.

4.) To the Bulls, Knicks, and Nets fans: just shut up. The Cavs fans have legit gripe, but you guys don't. So you didn't win the lottery. Boo-frickin'-hoo.

5.) To Kobe Bryant: congratulations. You are no longer the most disliked player in the NBA, a position you have held at least since you kicked Shaq out of L.A. Your style of egotism just became slightly less appalling to people outside of southern California. One interesting piece of analysis I've read is that there is no way Kobe would have gone to Miami, if he would have been in Lebron's position. The reason is that he would never want to have a decreased role so that he could play alongside Dwayne Wade. This is probably true, but I have a hard time seeing this as a negative about Lebron. Imagine if Lebron had got on TV last night and said he was playing for the Knicks or Bulls next year because he not only wanted to win a championship, he wanted to be The Undisputed Man on said championship team. That's the Kobe Bryant brand of egotism, and is that really more appealing? Maybe to some people, but not to me.

6.) To Kevin Durant: your time has come. You have a very legit chance to become the most popular player in the NBA next year, and you seem to deserve it. He's an unbelievably good player. He seems to have a Kobe-like work ethic. He also seems to be unbelievably humble. He's also 21 years old. He has to be on the short list for possible MVPs next year (Lebron's stats will take a big tumble in Miami.) His team looks like it will be very good for many years to come. It would not be surprising if a year from now Durant is sporting an MVP trophy, and coming off an exciting run deep in the playoffs. The only thing that might limit his commercial/endorsement potential is his own desire to stay focussed on basketball. Can you honestly say that about any other NBA player?

7.) To my home state of Florida: basketball just became king. Between the Orlando Magic and Miami Heat, my home state has three of the top five players in the NBA, two teams that will be expected to win ~60 games per year for the foreseeable future and meet each year in the Eastern Conference Finals. The only teams that could possibly stand in their way in the East are the aging Celtics and ... Maybe the Bulls if Derrick Rose becomes a top 10 player next year (which he definitely could do.) Seriously, there are going to be a lot of Florida Turnpike Series over the next five years.

8.) To Pat Riley: you are the man. You've got your work cut out for you, filling out that roster, but I'm not about to start doubting you at this point. In fact I would not be surprised if Wade, Bosh, and James all wind up taking considerably less than max contracts, all in the pursuit of a championship roster. As an Orlando Magic fan, I really hope this is not the case, but I'm too scared of Riley to think otherwise. I'm also impressed with his willingness to part with Michael Beasley, a very high and hyped draft pick. Personally I think Beasley may still turn out to be a very good NBA player, but I don't think most GMs would be willing to so quickly admit a mistake.

9.) To the pundits: let's see how long your memory is. A lot of people are saying that Lebron is taking the easy way out (even though many of those same people also think that having two All-NBA and one all-star player does not guarantee much in terms of championships.) It's Wade's team still, they say. Lebron can't be considered one of the game's greats now. That's all ridiculous to me. If Lebron continues to play the high level he's played at, and the Heat win multiple championships, none of this will matter. Nobody will care that it wasn't Lebron's team. Magic Johnson was never the "give me the ball at clutch time and get out of the way" kind of player, but nobody doubts his greatness. Lebron is much more cut in his mold than he is Michael Jordan's, and frankly it would be pleasing to see Lebron accept this. I think his stats will suffer, but mostly just scoring. I don't think his assists will necessarily suffer, especially if the Heat play an uptempo game (which they should.) His rebounding will go up if he plays in the paint more, and again if the Heat play uptempo. Imagine if he had a three year stretch averaging 20 points, 12 assists, 12 rebounds per game, while shooting 55% from the field? Throw in a couple of titles, and you're telling me he's not one of the top five players of all time? Nobody will care if Wade has the ball in his hands at crunch time.

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!