leŭksman

A few weeks ago, we released the first public beta of StatusNet’s dedicated desktop client for Linux, Mac, and Windows.

We’re still working on bug fixes and improvements, but we’ve also been working on a mobile version, which runs on Android and iPhone/iOS platforms (Blackberry support isn’t ready yet in the Titanium cross-platform runtime we’re using, but it should come along in a few months). If you’re really brave you can dive into the source code, but we’re in the middle of major restructurings and UI design so it’s not really usable yet.

Once we get the UI polished up in the next week or so, we are going to need some testers to help make sure things work on different devices, different OS versions, at different screen sizes, with different servers, etc…

If you have an iPhone or iPod Touch and want to test without being a developer yourself, you’ll need to find your device’s UDID number and send it to us; due to the way Apple’s code signing works you won’t be able to install the beta distribution unless your device’s ID was included when building the signing key.

Android users will only need to ensure that “Unknown sources” is checked in Application settings, which allows installing apps from the web as well as from the Android Market. (Some models unfortunately don’t allow changing this setting, in which case you may need to root your phone to get the beta running. Sorry!)

Particular things we’re looking for…

• older iPhone 2G, 3G devices still running iPhoneOS 3
• Android phones running older OS versions (1.6 or later; 1.5 does not work with our runtime)
• Android devices with unusual screen sizes:
  • small low-res screens (less than 320×480)
  • larger tablet devices

There’s been a lot of confusion about just how multitasking works in the iPhone’s latest iOS 4.0, and just what the limitations on background processes are. Most of the articles I’ve seen attempting to clarify it have concentrated on the addition of the new suspend state and how apps being background vs suspended vs terminated relates to the task list interface. That helps with the end-user confusion, but to me has just made it even more confusing from the developer’s perspective — I want to know what my app will be able to do in this brave new multitasking world, and what its limitations are going to be.

I’ve gone ahead and actually looked at the documentation (RTFM); here’s some notes… (Impatient readers may wish to skip to the summary at the end!)

Application state lifecycle

First, let’s go ahead and put those “background” and “suspend” states into perspective…

	Not running On screen? no Running? no In memory? no Resources none In the beginning, there was nothing… Before your application is started, it just doesn’t exist in the system yet. An app that’s not running has no way to execute code, but popup notifications may be shown on its behalf by a registered server application or from earlier scheduling.
When your app gets launched, your code gets loaded into memory and you transition into:
	Active state On screen? yes Running? yes In memory? yes Resources as you like Your app is large and in charge! Your code and data are in memory, code is being executed, and you’ve got free control over the user interface, audio, network, etc. There’s also an inactive state when the system takes over the UI and event loops for stuff like showing the incoming phone call dialog; your app is temporarily paused from the UI, but all your resources stay intact and you’ll get them back soon.
When it comes time to switch apps (through the home menu, task list, or programatically), your app loses control of the screen and enters the…
	Background state On screen? no Running? yes In memory? yes Resources restricted* Your code is still running, but you’ve got no access to the screen, and various resources start getting cut off. Usually this is a temporary state giving an application a chance to save data, close out unneeded resources, and generally tidy up before being suspended completely. There are some special exceptions which can allow an app to run in background state for prolonged time, which is where the really interesting stuff comes in. We’ll get to that soon!
When we’re done with background state, the OS can put your app to bed; now it’s in…
	Suspend state On screen? no Running? no In memory? yes Resources mostly freed This is the biggest change in iOS 4: after your post-switchaway cleanup, the app remains in memory so it can be continued at a moment’s notice. Previously, after your app did a little cleanup on the way out it would be terminated and all its memory and network resources freed. Instead, the app is now simply stopped at this point, but with the explicit warning that it may or may not ever be continued.
If the app is reactivated from suspend mode, anything you kept in memory is still there — you have a lot less work to do to reestablish your application’s running state than when relaunching the process. But you may die before you wake, in which case you’re back to…
	Not running state. If the system needs more memory to assign to another application, or gets shut down, your suspended app will be terminated without being woken to inform it. You need to be prepared for termination before entering suspend state… but really, you’re already writing code that assumes it could crash at any time and saves state at intervals and key points so it won’t lose user data, right? Um, right?

Background mode limitations

So just what are the limits of what you can do while running in background state? The docs mix together a lot of strict limits along with recommendations for being a good citizen; I’ve tried to split them out here:

YOU CANNOT (technical restrictions on what you can do):

• Can’t make OpenGL calls; they will terminate your app.
• Can’t accept new connections on a listening socket.
• Can’t use shared system resources like the Address Book (it sounds like they might sorta work if still open, but you could get terminated if there’s a conflict.)
• Can’t use external accessories — you must register for and handle disconnection events.

YOU SHOULD (recommendations for behaving well):

• Should be prepared for loss of connectivity — open network connections could be torn down at any time.
• Should save your state, since your app could be terminated due to memory pressure.
  (You should be saving state during regular operation anyway to protect against application or system crashes, power failures, etc. Programs that assume orderly shutdown are asking for trouble!)
• Should avoid updating your windows and views; it’ll work but since your UI is hidden it’s a waste of time & battery.
• Should normalize your UI state — cancel modal alerts, hide temporarily shown passwords, etc.
• Should “do minimal work” while in background.

Reaching the user when not on screen

iPhone OS 2 introduced networked push notifications, where — through the magic of the internet — your app’s web services can trigger a notification dialog on the phone, even if your application is no longer running. iOS 4 extends this to local background tasks; if your app is in the background state, it can pop up a notification immediately without needing to go out to the network.

You can also schedule a future notification at any time (up to 128 scheduled per app), which will trigger even if your app has been terminated — obviously handy for alarms, calendars, and timer apps.

Notifications are limited in that they alert the user, not the app. If you were suspended or not running when the notification came, you won’t be woken unless the user pushes the button that opens your app.

When in background…

Any app can start up background task threads, which will block the background->suspended state transition.

This is primarily intended for orderly shutdown tasks, like completing that photo uploading to Twitbook or syncing mailbox state to a server after reading a bunch of messages. The system actually gives you a time limit, and will terminate your app if you don’t declare your tasks complete when the time limit’s up! Once you’re done, you’re forced to suspend… absent other triggers, your app is going to stay that way until the user switches back to it or it’s terminated.

You can also register to receive an event for “significant location updates“, which will wake or even relaunch your application when the cell network has noticed that you’ve moved a non-trivial distance. This avoids running down the battery with the GPS if you want updates but don’t really need to be watching it continuously.

Special backgrounding modes

An app can declare itself to have certain types of backgrounding characteristics, which can allow some additional behaviors in background state. Since these are pre-declared in the code-signed app bundle, you need to be aware of what affect they’ll have on your app’s runtime behavior, and will have to run the App Store approval gauntlet with an extra bulls-eye on your forehead.

Background audio mode

Normally, the system audio frameworks cut you off when transitioning from active to background state. If your app is marked as a background audio app, you get two perks:

• Audio in/out continues to work in background state.
• Suspend is blocked while playing audio, so you can keep running in the background arbitrarily long.

If audio is not active, your app will still be able to suspend — so a music player that’s paused, or reaches the end of its playlist in the background, can free its resources.

Articles I’ve seen have had a lot of vague language seeming to indicate that apps in this mode can “only” play audio and do nothing else, which might imply that there’s some kind of wacky alternate API for bg audio — this is not true. The docs recommend avoiding unnecessary work while playing background audio to keep resource usage down, but there’s no artificial restriction beyond the general limitations on backgrounded apps.

You’ll still use the same old network interfaces, the same old audio APIs, etc; reportedly it only took an hour to port Pandora’s iPhone player to use background audio.

Background VOIP mode

The VOIP mode is really about management of long-running network clients — an actual VOIP app will probably need to also mark itself as needing background audio. Your app will still get suspended if the user switches away with no active call, but gets a few special abilities:

• Sockets you register as VOIP control channels will stay live when your app is suspended. If data comes in, you’ll be woken up — this lets you handle an incoming call.
• You can register a timeout to be woken at intervals, so you to send keepalive pings if needed.
• The app is automatically launched in the background on boot, so you can connect to the server.
• The app is automatically relaunched on non-zero exit code, so a one-off app crash won’t break the VOIP service.

Note that while this mode sounds ideal for IM/chat apps, connections to real-time update streams for social networking clients, etc, I suspect that Apple would not actually approve such apps.

Continuous location mode

Navigation apps, GPS tracers, etc may need a more direct way to monitor the GPS for location changes while backgrounded. This is similar to the background audio mode:

• Continue to use the regular location services APIs…
• …while you’ve got it active, suspend will be blocked and you can remain in background mode arbitrarily long.

GPS has a particularly bad reputation for running down the battery, so if you’re just looking to ping 4square or something you should probably use the “significant location updates” event registration instead.

Summary

Now that we’ve seen something about how it all works, let’s take some sample cases and ask whether they’ll actually do what we need… So what do we need?

I’m a media player (Pandora, Airfoil Speakers, etc)

• Can I continue playing audio after switching away?
  • Yes — mark your app as requiring background audio, and it’ll stay backgrounded on switch.
• Can I keep communicating with the network while playing audio?
  • Yes! But if you’re doing other stuff not needed for your audio and Apple notices, they may not approve your app.
• Can I start playing audio later on after having been backgrounded, like an alarm clock?
  • No — if you’re not playing audio at switch time, you’ll still get suspended. You could schedule a local notification to alert the user and they could push a button to launch your app and then you could play the music. Ewww!
• Can I keep a socket open to listen for other computers to connect and send me audio to play?
  • No — your listening sockets will be closed, and you’ll have been suspended anyway as above.

I’m a VOIP client (SIP clients, Skype etc)

• Can I keep an active call going after switching away from the app?
  • Yes — mark your app as requiring background audio, and a running call will be able to keep on going.
• Can I maintain a connection to my server to listen for incoming calls?
  • Yes — mark your app as needing VOIP mode, and set the special flag on your control channel after setting up the connection.
• Can I be automatically launched on boot, so I can open that connection?
  • Yes — mark your app as needing VOIP mode, you’ll be automatically launched if you
• Can I maintain a listening socket to receive direct SIP calls?
  • No — all listening sockets will be closed in the background. You need an existing connection to a server which’ll send a packet down when there’s an event.
• Can I auto-answer calls?
  • I’m not 100% sure on this one; if the system fully foregrounds you to handle incoming events so you can show an “incoming” screen then yes, otherwise I don’t think so.

I’m an IM or social networking client (AIM, Meebo etc; StatusNet, Twitter, Facebook, etc)

• Can I finish uploading a post in the background if the user switches apps before it’s done?
  • Yes — do it from a background task thread, and notify the system when you’re done and ready to be suspended.
• Can I poll my server in the background to check for updates?
  • No — you’ll need to pair with a server component and use networked notifications to alert the user.
• Can I keep a socket open to listen for real-time updates from my server?
  • No — in theory the VOIP mode would allow this, but Apple would have to approve your app’s using it for non-VOIP use.
• Can I be woken to check status when the physical location has changed?
  • Yes — you can register for significant location updates and be woken or launched to check if you need to perform any actions.

I’m any kind of server:

• Can I listen for clients while in the background?
  • No. Your listening sockets will be closed, and any Bonjour service stuff will be torn down.
• Can I finish up an existing client connection after switching away?
  • In theory this ought to work, if the operation can complete in a background task thread before you’re forced to suspend.

I’m any other bit of software:

• Can my app be woken at a specified time?
  • No. You can set a notification to display at a given time, but user interaction will be needed to wake or launch your app.

Whee!

The Android 2.2 “Froyo” update finally came through over the last few days for Nexus 1 owners. After a few days of on-and-off usage, some notes to add to my initial review of the N1 running 2.1:

What’s new:

• Speed: Things definitely feel snappier than they used to, but not really in a firmly quantifiable way. I’ll try another head-to-head scrolling test after a bit, but I can still expect to see the N1 way behind on that — scrolling still feels jerkier, and usually slower, than on an iPhone.
• Tethering: For me, this was one of the main the killer features that pushed me to actually buy the N1, and I’m very happy to see it working! AT&T might finally have gotten around to enabling tethering for the iPhone, but they’ve shot themselves in the foot by making it cheaper to buy a new Android phone instead of the $20/month to not get a bandwidth limit increase on your iPhone. Over your 2-year contract, that comes to $480 wasted on AT&T… and it still wouldn’t power your Wifi iPad while the Android will! Sorry, guys. I know which features I want.
• Screen: my background image is still pretty badly banded, but gradients in the web browser look smoother. There may be piecemeal improvements in how images get rendered and dithered for fullcolor output, but it’s still a bit inconsistent.

Otherwise, the OS isn’t mind-blowingly different, but definitely has a lot of nice little bumps. Ars Technica has a general review of Froyo on the N1 if you want to peek at a few other under-the-hood changes.

Update: There’s also a notification system that looks like a very flexible superset of what the iPhone platform has, which might be very nice for things like sending realtime updates to our upcoming mobile client without it having to poll in the background. That ain’t much useful to users yet, but we’re sure gonna use it in future!

Compared to the iPhone 4

Of course, Apple’s been moving as well. iOS 4 is out for the existing iPhone 3G and 3Gs, and the new iPhone 4 is available and busy fighting a reception issue scandal.

iOS 4 on my iPhone 3G feels like a very nice incremental improvement. Things aren’t radically different, but it’s definitely a bit nicer: folders have helped organize home screens by moving out rarely-used apps, background processing is a big help for a few apps (like Pandora!) and there are other niceties like threading in the mail reader.

I haven’t picked up an iPhone 4 for personal use yet, but I did swing through an Apple store the other day (when the crowds had died down a bit!) to check it out. There are only a couple of interesting user-visible hardware changes beyond the case change:

My favorite is the awesome, awesome high-resolution display. I am really looking forward to this pixel density being available on desktop-size screens… some day we can stop worrying about pixels and just have text and graphics that look good.

There’s some talk that HDTV has actually set display technology back for large formats; I’ve seen only a handful of commercially-available monitors that venture much beyond 1920×1080, and those are all to gain extra desktop space not to improve density/sharpness.

The screen on the Nexus 1 is visibly sharper than the iPhone 3Gs, but even with my slightly blurry vision is visible pixelated at smartphone-usage distances from my eye. The iPhone 4 really, literally, truly moves it into the realm where pixels no longer matter; as this level of display technology makes it out into the broader market, I think it’s going to make a big difference in what we’re comfortable reading on a small screen.

The front-facing camera & video calling support is the primary selling point in Apple’s current ad campaign; the nice saleslady demoed it for me, and the quality’s pretty good for what it is. But honestly I don’t see myself ever using it as more than a gimmick; I’ve had a webcam on my laptop for 5 years and have never been on a video chat that’s not about trying out the video chat feature. Perhaps Apple will prove me wrong — and like with video chats on computers, some people get a lot more mileage out of it than others. I can certainly see if I had a small child we’d probably be on with my parents a lot more often — my mom doesn’t need too many real-time updates on the cats.

There’s also an improved main camera, which may be a nice extra but isn’t a killer feature for me — the current phone cameras are adequate (though not great) and aren’t main selling points for me.

Along with other projects at StatusNet, I’ve been poking at the mobile version of our open-source client reference implementation (still in pre-alpha but getting usable for desktop version). We’re building the client with Appcelerator Titanium, a JavaScript-based cross-platform toolset for development and packaging; the desktop version uses a WebKit-based HTML environment, while the mobile versions use a thin bridge between JS and native controls.

There are some differences between the JavaScript and native bridge implementations between the different target platforms, but cleanly-written backend code can be shared between all platforms, and we’re able to use a single codebase for the mobile UI on both iPhone and Android.

The fun part, though, is with testing and debugging. I’m doing most of the mobile development on my MacBook Pro since I can test both current mobile targets in their respective emulators or real devices from there.

The Android experience

There are several really nice things about the Android SDK setup. First off the download isn’t a bandwidth-shattering 2.3 gigabyte disk image. Once installed, I can create custom emulator images with particular combinations of screen resolution and API versions. And, of course, I don’t have to pay $99 and set up a bunch of code-signing keys just to run my test app on a real device!

Android’s SDK emulator is a real, honest-to-god emulator, built around the amazingly versatile QEMU. (I remember using QEMU to simulate an x86_64 system back before I could afford one! Oh the memories…) It runs a complete virtual ARM-based system, booting up a full Linux kernel and Android userland environment.

The good thing about this is that you’re going to be running the exact same real actual code that you’d load onto a real system.

The bad thing is that it takes fricking FOREVER to boot up. Even on a fast modern desktop CPU, emulation is a bit sluggish… booting and general UI actions feel much slower in the emulator than on my Nexus 1 with a 1GHz Snapdragon CPU. And if you accidentally close the emulator you have to wait for it to boot up before relaunching your app…

It’s actually faster in many cases to plug in an Android phone and launch it there. With USB debugging enabled, a native phone can be treated much like the emulator, and Titanium’s wrapper on the SDK can install and launch my app remotely just as quickly as on the emulator — but without waiting for it to boot.

The iPhone experience

Apple went another direction with their iPhone SDK, which has some pluses and minuses. Rather than a true system emulator, the SDK contains an “iPhone Simulator” application, which runs much of the iPhone OS userland as native Intel code on the host system.

The downsides are obvious: you have to compile separately for the simulator and the real, ARM-based devices. Subtle bugs can arise from differences between the systems at both high and low levels. Low-level optimizations such as assembler or vector code won’t even compile, much less run (though that at least isn’t an issue for our JS-based code! An emulator wouldn’t have the same performance characteristics, but could help you confirm that  your math is right before sticking it on a real device.

But there are some upsides: most important to me, the simulator launches nearly instantly. This makes a big difference when you’re working in a rapid-development environment without a good debugging infrastructure; working in Titanium’s JavaScript involves a lot of ‘poke in this line of debug to find out wtf is going on, then fix it’ and I might have to restart the app over and over and over while working with it…

The thing that’s amusingly poor with the iPhone is launching the app  on a physical device. Thanks to Apple’s tight restrictions on app distribution, running your own program requires buying into Apple’s developer program ($99/year), setting up code-signing keys, an dropping a bunch of certs into iTunes so it’ll be willing to copy your stuff over. The Titanium developer tool can then recompile your app (this time for ARM) and shove it over to iTunes, which performs a sync of your phone to copy the app on. This is kind of annoying if you have a bunch of random crap on your phone and syncing takes forever!

What I’d like

Something in the middle might be nice… working with a real device is a lot easier without jumping through code-signing hoops, and the iTunes mediation seems like something that should be skippable if the toolchain’s better integrated, which could improve the iPhone experience.

Performance and boot time are the biggest issues with the Android emulator; making it boot within a couple seconds would be a huge improvement by itself. Cutting overhead by running a native i386 or x86_64 system image might be nice too, but might not be worth the trade-offs of being able to run native ARM code in the emulator.

Today’s personal computers basically run two distinct operating systems: the native host OS (Windows/Mac/Linux or iPhone/Android/etc) and the web.

Web apps have solved all kinds of problems that are still poorly handled by most native systems: apps automatically update every time you use them, they manage their own library dependencies, there’s a security sandbox that lets you run pretty much anything without concern that it’s going to eat your system (unless your browser is buggy!)

Let’s face it: most of us probably spend a lot of our time in the web, and even if they’re not doing everything that’s where a lot of action is. Some folks have used this as a sort of excuse for the extreme control some platforms exercise over software publishers – “don’t like the rules? Make a web app, you can do anything!” 

But web apps are still much more limited in some areas. Access to hardware is rare (cameras, audio recording, scanners, attached storage). Communication between apps is greatly complicated by that sandbox, and shared data on the host machine like contact lists and photo archives may be completely inaccessible without a host-specific shim. (Most impressive thing I’ve seen is a bank web site that did deposit via scanned check image, using a signed Java applet to hook into native scanner support. It only worked on Windows, alas.) Background processing is very limited, and most web apps give up on directly notifying you of new activity and just send you email, hoping you’ve got something else that’ll tell you there’s new mail.

There’s a lot of great activity going on in and around HTML5 these days that’s getting better graphics support, faster code execution, etc. But the things that really bring the web native are going to be about access to shared hardware and data resources.

Some good things have been coming in such as touch and orientation events in Mobile Safari, but there’s a long way to go. My pet peeve: I find it pretty surprising that HTML file upload controls don’t trigger something useful like the camera roll on the iPhone/iPad or the Android browser. I can’t believe nobody has thought of this, so I’ll assume for now that the various browser folks just ain’t gotten to it yet… Anybody feel like starting on patches for Android’s Browser and the mobile branch of Firefox?

So while fiddling around with the iPad I picked up for testing, I thought “hey self, this would be a great platform for an exploration/adventure game like the classic 1993 CD-ROM game Myst!”

To my great pleasure, i discovered that Cyan released a iPhone/iPod Touch version of the original Myst last year, which also runs quite nicely on the newer iPad.

The game features a richly detailed CG-rendered environment (all pre-rendered graphics thanks to 1993′s paltry CPU horsepower), where you wander around trying to piece together the history of a family power struggle that has trapped the denizens of a world where writing can literally create new universes.

Back in the 90s, the graphics, videos, and music filled an entire CD to the brim; the iPhone version weighs in at a similar 540 megabytes or so, which by today’s standards is a reasonable download.

The still graphics have been slightly rescaled from the Mac SE-friendly 512×384 or so down to 480×320, but appear to be from true color originals rather than the dithered 256-color versions of yore. Some screens have been further zoomed in to make small touch targets more accessible, but I still find it a bit awkward on an iPhone.

In pixel-doubled mode on the iPad, everything looks great and navigating by touch is a joy; the cleaner true color images outweigh the slight resolution loss for me, and it’s just the right size to go pushing things on.

My one big wish might be for an integrated note-taking feature. (Some of the later games in the series actually added a screen-shot feature, presented in-game as a camera!) On a 1990s desktop computer I could easily keep my notes on paper, but a portable tablet cries out for taking the notes on the tablet too, so they’re with me whenever I feel like poking at the game for a few minutes. Fortunately the game is great about saving and restoring state automatically, and starts up in just a couple seconds, so switching between the game and Notes or Photos isn’t too unpleasant. (Better multitasking on the system could help here too by keeping state live while you’re away in your notes.)

I would really love to see Myst’s sequels brought to tablets like the iPad natively; the higher-resolution graphics in Riven would look *fantastic*, and the iPad should have enough horsepower to handle the fancier video and panoramic effects in Mysts III and IV. I still need to finish IV and play V though…

Probably the biggest obstacle to the later games is storage space. Pre-rendering graphics from every possible view position and direction let them have visuals years ahead of their time, but at a huge cost in disk space. Riven should be tractable, but full downloads could run many gigabytes for the later games, which spanned multiple DVDs!

Summary:

• Game:Myst for iPhone
• Genre: graphical adventure/exploration/puzzle
• Platform: iPhone OS (low resolution)
• Cost: $4.99
• Awesome factor: pretty awesome
• Nostalgia factor: pretty big but not overwhelming the awesome
• Recommend? yes!

Note: typing html tags manually on the iPad keyboard is pretty awful, as letters, slash, and angle brackets are all on different screens. I’d really appreciate working rich text editing in Mobile Safari!

Good news 1: AT&T is exchanging their ‘unlimited’ $30/month iPhone data plan for a $15 200 MB/month and $25 2GB/month plan, with relatively sane overage handling.

This is good because AT&T’s been blaming a lot of its woes on out-of-control data usage by iPhone users exceeding their network capacity in the most crowded markets. If they’re actually charging based on usage, the incentive structure changes from them wanting to minimize our data usage [pushing costs down] to wanting to make it as attractive as possible to actually use the network [pushing revenue up, rewarding infrastructure buildout].

That means AT&T is more likely to give people things they want, and I can’t say a bad thing about that.

Good news 2: AT&T will finally start offering iPhone tethering (11 months behind schedule) for an extra $20/month on top of the 2 GB/month plan.

Adding tethering is a must for AT&T as the US exclusive iPhone carrier to compete with Android phones, which can already tether on any network without jailbreaking and will soon have the feature officially in the OS.

These exclusive carrier agreements are horrible for consumers; it took this long for a competing phone to catch up enough to actually push AT&T into action. If we’d instead had an open phone market, so you could buy any phone and use it on any network, we’d have had somebody offering official consumer-friendly tethering the second the iPhone 3Gs was announced.

Bad news: That $20/month doesn’t actually get you anything real — you have the same 2 GB limit that you’re already paying for, but you’re more likely to reach or exceed the limit. If the issue is data limits, why do I need to pay extra to NOT get a bigger limit? This is particularly silly if customers can tether for free on any other network, or on the same network with any other phone, or on the same network with the same phone if they jailbreak the software. Hello?

But let’s give AT&T props for baby steps — they’ve already been offering similar smartphone tethering plans that don’t add anything to your data caps for their other smartphones, so that’s what they know.

What it probably does for me is to make me feel less guilty about considering getting the poorly-advertised unlimited international smartphone data plan ‘without tethering’ and then using tethering anyway on my Android-based Nexus One. It’s enough money that I’d feel like I’m paying for my US tethering during the months that I don’t have any international travel.

I’ve been an iPhone user for two years, on both the original Edge-only model and the much snappier iPhone 3Gs that came out last year. This has mostly been a great experience, but there are a few things that bug the heck out of me and I’ve been looking around to see what’s on the other side of the fence.

I also need to be able to make and test software for Android phones, so when I saw there was an AT&T-compatible version available it was easy to talk myself into picking up Google’s officially-branded Nexus One, made by HTC.

After a couple of weeks of using it off and on, I’ve got a pretty good idea of what I like, what I don’t like, and what I’m looking forward to in the future. Unfortunately, it’s a mixed bag; I’m still recommending the iPhone to family and friends unless I know they need/want the geek-friendly features.

Some of my initial impressions of high and low points…

The good

The Nexus One’s high-resolution screen makes for visibly sharper text, and the dark blacks and bright colors make a good first impression. The next-generation iPhone is rumored to match or beat this, but isn’t yet solid.

For the geeks: Android allows you to install applications without hoping that a single company (who may be a competitor) approves them for distribution. This is kind of nice, and means I can actually use the phone for what I bought it for without having to subvert the operating system. Within an hour of opening the box, I’d installed a third-party app that enabled basic tethering (using the phone’s 3g connection to provide internet for a computer). iPhone has this feature, but AT&T disables it and Apple doesn’t allow distribution of 3rd-party apps that re-enable it.

Third-party apps on Android can also run in the background, which is great for running, say, internet radio (Pandora!). This will eventually come to the iPhone with OS 4.0, but it’s not there yet.

I’m a bit undecided on the Android “hardware buttons”: back, menu, home, and search (versus the iPhone’s single home button). While I think they make the interface more complicated, they do free up screen space that on the iPhone tends to be used for toolbars and navigation.

The combination of better multitasking and a system-wide ‘back’ navigation key does enable something very nice, though. A lot of iPhone apps have ended up implementing their own mini-web browsers so you can read links while the app can still run, downloading your RSS feeds or updating your Facetweets. This fragments your browser history, caches, bookmarks, settings, etc… Android apps just send you over to the regular Browser application, and you can pop back by hitting ‘back’.

The bad

The two biggest drags on the Nexus One are performance and display quality. Everything feels sluggish; simple actions like scrolling through a list or web page are visibly jerky (see slo-mo comparison video) and just can’t keep up with your finger. On a device with twice the processor speed and four times the RAM of the 2007 iPhone this is unforgivably bad, and it makes everything feel slow and unresponsive.

Updating to the new Android 2.2 (“Fro-yo” release) is rumored to improve responsiveness; it’s still slow in the SDK emulator, but when it comes in through the standard update channel I’ll poke around at it on the real phone.

The otherwise-lovely screen is illegible in bright sunlight — whereas the iPhone is just fine in my experience — and suffers from bad color banding visible on photos and gradients. It’s kinda like jumping back to 1994, when we didn’t have enough video RAM to run 24-bit color beyond 640×480. Seriously, guys?

Another huge annoyance is the way storage is split up: you can upgrade general storage from the default 4GB by swapping out a micro-SD card, but the operating system and all applications have to squeeze into a paltry 512MB. I have individual games larger than that on my iPhone! The latest OS upgrade is supposed to add the ability to install apps onto the SD card, so this may become less of an issue in the future.

I’ve also found myself hitting the ‘hardware keys’ by accident while typing. They’re flush with the touchscreen, with “menu” and “home” placed smack under the on-screen spacebar. It’s pretty common for me to accidentally go back to the home screen twice while composing a comment to post on identi.ca. Ouch!

More generally, I’ve been pretty frustrated with some of the built-in apps. Android’s Clock app doesn’t include a timer countdown, which is the thing I use most frequently on the iPhone’s Clock — cooking, laundry, stretch breaks, time to go pick up the sushi order… Another top app for me is Notes, which holds a lot of grocery lists. For both of these I was able to find rough equivalents in the Market as third-party apps, but the search interface is pretty poor, and I’m still not sure I like the apps I’ve ended up with.

The rest

For the most part, the iPhone and Android platforms are pretty similar from a user’s perspective. I still think the iPhone provides a better overall user experience, but Android’s moving fast too, and has a leg up in some areas.

If availability of particular features or applications is a make-or-break, then pick the one that does what you need — overall app (and game) selection seems better on iPhone, but some features just aren’t there. If you’ve got a strong ideological position that centralized control over what you can do with a device you own is A Very Bad Thing, you’ll be happier with the N1 but will have to put up with some annoyances.

Or if you’re a supernerd like me, well you know you’re just going to buy both.

We finally replaced my fiancée’s ancient PC with a shiny new Dell laptop. While ordering, I couldn’t help myself and tossed in a Inspiron Mini 9 for myself:

This little cutie weighs in at just 2.26 pounds, less than half of my MacBook’s hefty 5 pounds. I’ve found that the Mini is much more back-friendly than my MacBook; I can painlessly lug it to the office with my laptop bag slung over my shoulder (easier for getting on and off the subway) instead of nerding it up in backpack mode.

The top-end model I picked packs 16GB storage and 1GB RAM running on a 1.6 GHz Atom processor — far more powerful than the computer I took with me to college in 1997. Admittedly, my iPhone also beats that computer at 8GB/128MB/300MHz vs 6.4GB/64MB/266MHz.

The compact form factor does have some impact on usability, though. The 1024×600 screen sometimes feels too tight for vertical space, but they include a handy full-screen zoom hotkey for the window manager which opens things up.

The keyboard feels a bit cramped, and some of the keys are in surprising places (the apostrophe and hyphen are frequent offenders), but it’s still a lot easier to type serious notes or emails on than the iPhone. I had to disable the trackpad’s click and scrolling options to keep from accidentally pasting random text with my palms while typing…

The machine shipped with a customized Ubuntu distribution which is fully functional; they include a “friendly” launcher app which can be easily disabled, and even the launcher doesn’t interfere too badly. The desktop launch bar that’s crept into Gnome nicely handles my “I need Spotlight to launch stuff with the keyboard” fix. Firefox works fine (after uninstalling lots of Yahoo! extensions), Thunderbird installed easily enough, and I even got Skype to work with my USB headset! (AT&T’s international roaming charges can bite me…)

The biggest obstacle for me to use this machine every day is my Yojimbo addiction. I use Yojimbo for darn near everything — random notes, travel plans, budgeting, grocery lists, recipes, encrypted password stores, saving articles and documentation for future references. It’s insanely easy to use, the search works, I don’t have to remember where I saved anything, and it syncs across all my Macs. But… it’s Mac-only.

I’m trying out WebJimbo, which provides an AJAX-y web interface for remotely accessing your Yojimbo notes. It’s very impressive for what it does, but I’m hitting some nasty brick walls: editing a note with formatting drops all the formatting, but I use embedded screen shots and coloring extensively in my notes.

I’ve seen some reports of people hacking Mac OS X onto the Dell Mini — very tempting to avoid OS switching overhead. But I think if I really want that, eventually I should just suck it up and buy a MacBook Air. The form factor is the same as my MacBook (full keyboard, roomier 1280×800 screen), but at 3 pounds it’s much closer to the Mini than to my regular MacBook in weight, so should be about as back-friendly for the subway commute and air travel.

Of course, the Air costs $1799 and I got my tricked-out Mini for about $400, so… I’ll save my pennies and see.

After a previous reworking of MediaWiki’s stylesheet-handling code to allow adding handheld stylesheets, I’ve gone ahead and implemented bug 2889 adding per-site customizable MediaWiki:Print.css and MediaWiki:Handheld.css pages.

The ability to specify some handheld tweaks is needed to be able to work around issues with certain kinds of layout formatting, especially the big beautiful multi-column table layouts which are popular on portal and main pages.

While lovely on a large screen, on a small device they tend to either make the columns reaaaally tiny or push things out off screen. On English Wikipedia I’ve thrown in some quick style hacks to flatten out those tables on the main page (this was applied already by Opera Mini’s classic view, but not Opera’s other browsers in small-screen mode):

Before:

After:

There are still improvements that can be done, but it at least helps things fit on screen! MediaWiki:Handheld.css can be edited on each of our wikis to tweak things up as desired/required.

Of course it’s always best to try to use clean, scalable styles that work on small screens to begin with.