mobile – Page 5

Mobile dev trade-offs: emulator vs simulator

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.

We are all dual-booters

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? :)

Game review: Myst for iPhone

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!

More AT&T games

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. :P

Android Review: Nexus One

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. ;)

Dell Mini love

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. :P

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. ;)

Handheld and print style customization

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. :)

Handheld CSS variants

For MediaWiki 1.14 I’m doing some refactoring of the CSS configuration to simplify some of the ugly and dupe code and to make things like adding handheld-friendly stylesheets easier…

An older experimental handheld CSS for MonoBook got trashed some time ago after complaints from some Opera folks that it just didn’t seem to work properly… so to experiment with this anew, I’ve added a site config option. By setting $wgHandheldStyle, you can now specify a custom style to use for browsers that think they’re “handheld” media. (These would normally exclude the regular stylesheet anyway, which is listed for “screen” user-agents.)

I’ve currently got it set on Wikipedia to specify the “Chick” style sheet, which is just an extra style variant on the MonoBook HTML, so fits rather conveniently.

Some bits of the HTML output for the curious:

You can preview it on-screen by adding &handheld=yes on the URL, just like &printable=yes for the print stylesheet.

I’m still a bit unclear on what devices actually support the ‘handheld’ media type, but I’m pushing for adoption of it with some device makers. :) Note that the iPhone/iPod Touch doesn’t grok ‘handheld’, probably quite deliberately since they want it to understand real ‘screen’ styles most of the time. You can make the iPhone (and Opera Mini in its new, fancier default view mode) use the handheld style by setting $wgHandheldForIPhone to true, which transforms the media types to use CSS3 media type queries on the screen size.

It’s a little funky-looking, but theoretically totally backwards-compatible. :)

Currently I’m not using this option live as the Chick style is still pretty awkward, and there’s no good way to disable the ‘only screen and (max-device-width: 480px)’ stylesheet if you don’t like it (well, other than adding UI and cookie crap).

So you can play with the handheld style on… Opera in “small screen” mode, Opera Mini in “mobile view”, and… anything else that you’ve found that I haven’t. ;)

OSCON reports: Open Mobile Exchange

Been here in Portland for a couple days for the start of OSCON, but still recovering from Egypt time… :D Some notes on the Open Mobile Exchange sessions…

A lot of the sessions told the same sad story. To make a long (sad) story short:

The good news:

Highly-capable “real web” browsers are here and becoming more widespread. WebKit, Gecko, and Opera-based browsers are shipping now on various devices or available for installation, and the Mozilla folks are working on a next-generation Gecko-based mobile browser.

Making the “mobile web” actually able to reach the real web is a huuuuuge boon:

People can reach sites that haven’t been optimized for mobile access (eg, 99.99999% of the web)
Mobile-targeted versions of sites can actually look good and be useful
Developers finally have a chance in hell of testing their mobile-targeted sites — the desktop versions of the browsers provide many of the same capabilities as the mobile ones, so you can preview faster and more reliably during iterative development.

The bad news:

Oh, where to begin! First, the bubble-burster:

Phones with good browsers are expensive! To reach those oft-touted billions who will own a mobile phone before setting eyes on a computer, we’re going to need the browsers in the $20 commodity phones, not just the $500 luxury smartphones.
Phones with good browsers are a tiny, tiny, tiny percentage of those out there today — even a tiny percentage of those shipping now.
To wit, for many years we’re going to see a lot of phones with no or crappy browsers.

Now, we can hope that Moore’s Law For Phones will push all the cool stuff into the commodity devices Real Soon Now, but I didn’t see anybody showing me evidence that it’s actually happening. Even the Symbian guys, who boast their OS runs “90% of the world’s smartphones”, realize they have only a tiny share of the total phone market.

We’ll consider this a “growth opportunity”. :)

The second challenge is that web apps today, while very capable with AJAXy stuff, have several major limitations:

No access to native device capabilities (camera, GPS, telephony)
No consistent system for offline functioning and data storage — you lose access to the world when your train goes in a tunnel or you get on a plane
Performance problems due to running JavaScript on top of HTML on a relatively slow, limited CPU

You can get around these limitations by writing native applications, but Here There Be Dragons.

Huge array of incompatible OSs, with
incompatible development models, and
incompatible application delivery formats

The “Linux mobile” people like the LiMo foundation are putting effort into standardizing some of the base software which should help with that, but honestly even us Penguin lovers hate that it’s virtually impossible to build a distro-independant package for the desktop and server Linux worlds. Do we really expect it’s going to be different for mobile Linux?

Even if that was solved, you still have to produce your Windows Mobile, iPhone, Android, and Java FX Mobile 2ME P2P WTF versions just for starters.

It seems to be everyone’s hope that native apps will “fade away” in importance as web apps become more capable.

But this is going to depend on the various browser makers and device makers agreeing on some things:

Sensible offline code & data storage. There’s motion on this with things like Gears and HTML 5 work, so I’m optimistic here.
Creating, then hopefully standardizing interfaces between web and native capabilities. This feels like a coming browser war… worst case is we can hope that JS libraries will abstract away the competing interfaces. Sigh.

So in the meantime, we’ll all make our pretty little web apps, churn out the occasional iPhone or Android or Mobile Linux app to use geolocation data or the camera or work offline, and wait for things to get better.