BugTender updates

Can now post comments on bugs! Auth prompt at post time. No offline queuing yet.

Bug list defaults to showing recently filed bugs. Various search and sort options, incomplete but a start. Doesn’t handle huge return lists well; server gives chronic order oldest first, we want the opposite.

Initial appcache for offline usage. Limited as there’s no persistent data cache yet, but you can load the page when offline.

Restructured bug view to put comments first.

More details in bug list items.


High-density displays: mobile and beyond

High-density displays are already here on small screens, and should start hitting tablets, laptops, and desktops in the next couple years. Apple’s iPhone 4 and current-model iPod Touch sport a best-of-breed 326dpi display, while lots of Android and Windows Phone devices have an intermediate 240dpi resolution. With the new Galaxy Nexus, Android’s entering the 320+dpi world as well.

The most immediate effect is of course that text renders as sharply on screen as in print. As a web-based application, Wikipedia gets this über-shiny text rendering  “for free”… but for graphics, we’ll have to work a little harder.

Most images you’ll find on the wikis are either largeish raster images that are being scaled down for in-article viewing, or scalable SVG drawings that are being rasterized to PNG on the servers for broadest browser compatibility.

Unfortunately neither automatically takes advantage of a high-density display!

For SVG drawings, we can simply start serving the original SVGs instead of the rasterized PNG images, and they’ll look lovely (images from Gas giant article mobile view, rendered on an iPod Touch, with high-res versions swapped in by this bookmarklet):

We’ll need to make sure we can do this with a good fallback to PNG however — while all major desktop and mobile browsers in their *latest* versions support SVG, there’s still a lot of Internet Explorer users and Android users who can’t view SVG. Some less capable mobile devices may also be unable to handle full SVG (Android is rare among smartphones; SVG support is missing on most Android phones today but is present in Android 3.x tablets and upcoming 4.x phones).

We also need to make sure that file sizes and rendering times are reasonable; large maps might be very expensive to transfer and render client-side when we really only need a small map. See my SVG-Open 2009 slides for some data on PNG vs SVG sizes and the need for work on shrinking files.


Other files are usually available in a size larger than they’re shown on default-density screens, so putting a 1.5-sized or double-sized thumbnail into the same screen space makes it match the screen’s actual density. This is particularly useful for diagrams that were created as raster images instead of SVGs, since they often contain fine lines and text which benefits from the full resolution:

SVG and PNG images used for icons and diagrams are probably the highest-priority for high-density images. Photographic images can also benefit, but usually scale up better than line drawings and text because they have fewer sharp edges to begin with.

For raster images of all types, doing dynamic replacement is extra work; CSS or JavaScript can be used in various circumstances but it can take work to make existing code using <img> tags “just work” without loading up extra versions of images, or loading higher resolutions than you need on other devices.

Math equations are another thing; currently we render most math equations to PNG images (via LaTeX); these also render poorly compared to other text on a high-density display. The best solution for this appears to be to migrate towards client-side math rendering based on the MathJax library; using MathML or HTML and CSS, this system is able to use the browser’s native text rendering much more effectively for math.  Equations rendered this way look stunning at high resolution!


Introducing BugTender: mobile Bugzilla frontend

I’ve been looking for a good solution to catching up on bug reports on my morning commute. The regular Bugzilla user interface doesn’t scale down well to mobile, and using the regular web interface is too flaky when connectivity goes in and out.

Enter BugTender: a preliminary HTML web app with a mobile-friendly interface to browse (and later, comment on & triage) your bugs.

Using HTML and jQuery Mobile lets the app run on multiple platforms and browsers — it won’t be tied to just WebKit, and works in a regular desktop browser as well. Wrapping that in PhoneGap for a ‘native app’ will allow further integration, such as access to the camera and photo gallery on iOS and older versions of Android — think uploading screenshots straight from your phone about problems in the browser!

Anyway, that’s how I spent chunks of my Thanksgiving weekend… more to come. :)


Amazon Kindle Fire notes

Driven by curiosity, I went ahead and preordered an Amazon Kindle Fire tablet, which I’ve been using off and on for the last week.

Wiki-specific notes:

  • Wikipedia (regular site) is on the default bookmarks, and displays nicely in the Silk browser (though the fundraising banners don’t quite fit in portrait layout!)
  • Our in-progress Android app mostly runs fine, though the small-screen layout feels slightly wrong on this 7″ screen. Will benefit from a more tab-oriented interface that can use sidebars or such. ‘Near me’ geo search doesn’t work, as it relies on Google Maps APIs that aren’t present on this device.

I’ll leave super review details for dedicated reviewers, but here’s a few notes from me:

  • customized UI mostly looks fairly polished, but has a few rough edges
  • performance is middling. reading, web, video playback are acceptable enough. Some audio skipping when playing & downloading music simultaneously (boo!).
  • battery life seems acceptable enough (not thoroughly tested, just using it intermittently)
  • A few parts of the UI are actually very smoothly animated, such as the ‘cover flow’-like bookshelf on the home screen — however it’s not synchronized to vertical refresh, and there’s visible tearing. Points for near-60fps animation, but points off for the tearing.
  • Silk browser seems pretty much like the stock Android browser with tabs. Disabling the server-assisted acceleration is easy in prefs.
  • Kindle book reader looks and behaves pretty much like the stock Android Kindle app but with some customized menus. It also can view comics/graphic novels which don’t appear to be available on Android/iPhone/Cloud Reader yet. :(
  • Built-in store stuff looks & works well; nicely designed to funnel all your money into Amazon. ;) They gave me a “free month” of Amazon Prime subscription, designed to get me used to streaming video, but I’ve already got Netflix, Apple, Comcast, and who knows what else available so who cares.
  • Since the Fire lacks hardware back/home/menu buttons, it has a software toolbar which displays these, similar to the software buttons in Android 3 & 4. Unfortunately it’s poorly laid out, centering most of the buttons so they’re hard to reach with your thumbs while holding the device.
  • Firefox runs, but isn’t yet available in the Amazon app store and the main download links herd you to the Android Market which isn’t there. There are manual download links which work though.
  • the onscreen keyboard is very comfortable in portrait mode when holding the tablet with two hands; I can type with the thumbs, and it’s easier than on a tiny phone. In landscape mode however the keys are too widely stretched to reach the middle comfortably.

On the software freedom front: the Fire actually fares better than I expected. Like most Android devices it defaults to allowing only apps from ‘known sources’ to install (in this case, the Amazon App Store) but this can be flipped easily in preferences, and you can install .apk packages from direct download or USB transfer.

Hooking up to a computer for debugging over USB works but requires some tweaks to get the Android SDK to recognize it. This is the only way to do screenshots, since self-hosted screenshots weren’t added until Android 4.0 (grrrr! my fave little feature from iOS since the 2007 iPhone release).

As a practical matter, lack of access to Google’s Android Market is inconvenient; even many free apps haven’t set themselves up on the Amazon store and don’t offer direct downloads. Additional alternate app installers can be used as well though, such as F-Droid or the various custom markets folks have been using in some areas.


Canvas game tweaks

A few weeks ago I threw together a quick demo HTML canvas game ‘FlatRoller’; I’ve updated it this weekend to add a few things:

  • touch controls now work on IE 10 in Windows 8 Developer Preview on a multitouch device. Microsoft is adding yet another touch event model alongside the classic mouse & iOS-style touch events. Urgh!
  • full window is now used for the canvas; the directions and touch controls overlay it
  • visual feedback on the touch controls
  • the directions switch from showing ‘left/right’ to showing ‘jump’ as appropriate when another touch would trigger jump

It’s a little sluggish on my first-gen iPad, but runs very nice in Metro IE 10 on my Dell Inspiron Duo tablet/notebook convertible. Yay!


I’ve also tried it out on my Android phone (Nexus One) and tablet (Kindle Fire), both running Android 2.3. Unfortunately both run pretty slow in both the stock browsers and Firefox, and only appear to pick up a single finger’s worth of touch events so the jump control doesn’t work.

Find source on github or play the game in browser.


Weekly whinge: offline feed reader for Android?

Google Reader for android is great… if you’re always online. If you have a subway commute, fly a lot, or otherwise like to catch up on your blogoverse when the rest of the world isn’t talking to your phone, you’ll quickly discover that the app’s offline sync feature is poor enough to be more frustrating than not having it at all.

They seem to have done a lot of things right; starring or marking things read works just fine while offline and queues the server updates transparently for later.  And when an article is available offline it fetches it cleanly and quickly.

There are basically three problems:

First, there’s no way to tell what feeds will actually be pre-downloaded. It claims to fetch your “most read feeds” but it gives no indication which those are. After several weeks of use I’m still getting confused by what is or isn’t being fetched.

The second problem is that the list displays do not distinguish between new feed entries *that have been reported to exist by the server* and those that have already been downloaded. You can see a clear count of entries and be faced with a “no network; retry” screen. Worse, if the connection is intermittent it’ll try to connect for a few seconds before telling you there’s nothing to see.

And to add insult to injury, images are not prefetched, consigning subway warriors to a pure-text life devoid of photos, screenshots, charts, icons, diagrams, maps, etc.

I could probably whip something up that does what I want, but polishing it won’t be trivial and I’m sure there are other tools out there that would suit my needs; anybody know a good offline-friendly feed reader of Android, preferably with Google Reader sync or import?

Apple’s pricing still winning the tablet war, mostly

Apple’s long had a reputation for high prices, and certainly there have been times and product lines where that’s very true. But there are a lot of places where Apple’s prices are actually quite competitive, especially where they have a huge lead in market share.

Everybody and their brother have been gearing up for the last year to launch their “iPad-killers”; so far Apple’s iPad is pretty much the only tablet-factor computer to ever sell well in the mass market (despite — or perhaps in part because of — the iOS platform’s many odd limitations). The only one to actually reach market yet with a tablet-optimized operating system is Motorola’s Xoom which recently launched running Android 3.0 “Honeycomb”; tech specs of this and another upcoming tablets are pretty similar to Apple’s just-announced iPad 2, available March 11 at the same pricing as last year’s models.

There’s been much hoopla about price, with no high-end competitor yet coming close to Apple’s entry-level pricing. The lowest-end iPad rocks in at $499, just under the $500 “wow that’s closer to $1000 than to free!” price point.

The Xoom so far has only a single 3G+Wifi-capable model, which retails for $799 standalone. This actually isn’t insanely awful — Apple’s 3G+Wifi models can run up to $729 or $829 with larger built-in storage, while the Xoom can have storage added with an SD card, so the gap is less than that initially visible $300 if you’re going for the beefier models.

Verizon also offers a $200 subsidy for a 2-year contract, making pricing more comparable to the unsubsidized $629 base 3G+Wifi iPad. But… let’s be honest, we all have phones with 3G or 4G data plans already. Do we really need to shell out for another cellular radio and another data plan?

Which tablet will actually cost you more will depend on which one you buy and on which data plan you get, if any. For those of us who want to pass on paying for a third (or fourth …) Internet connection every month when we can already use our phones as a wifi hotspot, any data plan is a huge expense, and subsidized pricing doesn’t make up for it:

  • iPad 2 Wifi-only: $499
  • Xoom 3G+Wifi w/ 2 years contracted data plan (sticker price only): $599 (pay extra $100, but you really pay more…)
  • iPad 2 3G+Wifi w/o data plan: $629 (pay extra $130)
  • Xoom 3G+Wifi w/o data plan: $799 (pay extra $300… but Best Buy ads say you actually need to buy a month of service to activate it…)
  • iPad 2 3G+Wifi w/ 2 years month-by-month $15/mo data plan: $989-$1229 depending on taxes/fees? (pay extra $400-$600):
  • Xoom 3G+Wifi w/ 2 years contracted $20/mo data plan: $1080-$1300 depending on taxes/fees? (pay extra $500-$700; plus another $350 if you terminate contract early)

Bigger badder data plans will let either brand leapfrog the other in price, depending on where you pick em… The cheapest thing is to buy a Wifi-only iPad and donate a few hundred bucks to your favorite Free Software-related charity. :P

The most important thing to remember is that for devices that incur a monthly data plan fee, the costs of the data plan can dwarf the original purchase price. This is why so many phones are insanely cheap or “free” — carriers have spent years playing an arms race to the bottom on your initial buy-in price to make way, way more money from you in the long term.

Update 2010-03-21: Motorola has announced a wifi-only Xoom model at $599; still above the iPad 2 entry price point but MUCH cheaper than getting anything with a data plan. I’ve placed a pre-order and hope to be trying it out by the end of the month!

Beta testers for StatusNet Mobile wanted soon…

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

Yet another iOS mulititasking explanation post

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.


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.


Nexus 1 + Froyo notes & iPhone 4

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.