this space intentionally left blank

September 24, 2009

Filed under: tech»mobile

Everything's Heavy

The default Android homescreen is a generally pleasant piece of software. It's easy to rearrange, hosts widgets for quick access to information, and has a fun parallax effect when you pan between "desktops." Add a handpainted Legend of Zelda wallpaper, and you've got yourself a classy launcher.

That said, I have two minor issues with it. First, if it's killed by the system (say, because the browser is hogging all the RAM), it can take a few seconds to restart itself. Second, it clears the activity stack when you load it, so the Back button becomes useless for multitasking. The Activity Stack/Back button combo is one of the best things about Android: together with the pull-down notification bar and the powerful Intent system, it lets users address incoming events without losing their place. Take, for example, this typical activity path:

  1. Launch Twitter client. Follow link to:
  2. Open blog post in browser.
  3. Get a message via GChat. Click notification to open chat window, type a reply, and press back button to return to the browser.
  4. The blog post links to a YouTube video. Click to open in YouTube client.
  5. Mid-video, receive incoming e-mail notification. Jump over to the e-mail application to read and reply, then press the back button to return to YouTube.
  6. Press back to finish reading blog post.
  7. Press back to continue browsing Twitter stream.
What you can't do out of the box is directly jump from one program to another (say from Text Edit to a Wikipedia entry) and back, because the Home screen will clear the Activity Stack. Instead you have to return to the launcher every time--way too slow for an alt-tab junkie like myself. One way to address this is to use one of the many utilities like Launchpad or Barcontrol to put links to favorite programs in the notification space. I've done this for a while, and it works, but it's clumsy (particularly compared to the elegant model used by the Palm Pre) and it means there's less room for actual notifications.

A better way would be if there were a way to augment the Home button as a kind of "quick launch" key, one that doesn't destroy the Activity stack. That's what my first Android program, Underground, does. It's not a full Home screen replacement, but a color-coded list of your favorite applications triggered by the Home button for fast, effortless multitasking. Think of it as a subway system for your phone.

I'll be putting it in the Android Market in the next day or so, but in the meantime you can grab the installation package here (don't forget to enable "Unknown sources" in the "Applications" section of your device settings). It's small: less than 50KB when installed. I'm also making the source available, in case anyone feels like tweaking it.

After installation, there won't be an icon in the application drawer. Instead, press the Home key. Android should ask what program you want to use to respond to the event, Home or Underground. Choose Underground to start using it. I also recommend clicking the checkbox to use Underground by default--don't worry, you can still get to the old Home screen, and you can always reset this in the "Manage Applications" section of your device settings.

When you start it for the first time, Underground has three items onscreen: a sample link to the web browser, "add new," and "home." You can choose "home," or press the hardware Home key again, to return to the default Home screen. To put your own favorite applications on the list, choose "add new" and pick one from the list (be patient: it takes a few seconds to find them all the first time). You can also long-press on a list item to change its tag color or to remove it from the list. Most importantly, just tap on an application's name to switch to that activity--Underground will quietly remove itself from the stack, so that the Back button will return you directly to your previous task.

That's all there is! Simple, fast, and effective multitasking in a memory-conscious package, without removing what was already great about Android's Home. I'm not much of a designer, so I've left it pretty simple: bold colors, nice big fonts, and liberal use of the platform's long-press interaction model. But that doesn't mean it couldn't stand some improvement: feel free to leave feedback here in the comments.

Notes on Programming for Android

It's extraordinarily impressive how easy this project was. Granted, it's a Java API, and after a couple of years in dynamic languages it feels like a real regression to go back to strict static typing, no first-class functions, and a million subclasses. And of course, it's not like this was an incredibly ambitious project. But for all that, Google has made working on Android about as simple as it could be. I've particularly grown fond of the XML-based layout tool and the package resource system, which makes it easy to build little chunks of UI (like tagged list cells) and pass them in to the view builders. If only S60 had been this easy!

And of course, it says a great deal about the openness of the platform they've built that I can literally take over from the preinstalled program manager (and that I was able to refer to its source code when I got stuck on a few tricky bits). All in all, it was a great experience, and I'm looking forward to working on a few more Android projects when I get the chance. Suggestions?

June 8, 2009

Filed under: tech»mobile

Electric Sheep

When I first got a cell phone, and for several years afterward, I stuck with the classic Nokia 6010, which is one of those phones that they now use on TV shows to indicate "low social status" for a character, like a cop or a high school English teacher. Even back then, the phone was practically a relic--no camera, monophonic MIDI ringtones, barely any MMS support, even. I didn't think there was any real point to those kinds of features. It's funny how fast I got used to them, not to mention all the other advantages, when I picked up a smartphone.

So last week I bought an Android Developer Phone (basically an unlocked HTC Dream/G1) to see how it suits me, and I decided to write a little bit about it here. After all, most of the reviews I've seen of the phone are from its launch, and don't take into account the improvements made since. Also, the vast majority of that commentary is from Professional Technology Bloggers, making it largely unsuitable for human consumption (my favorite: Jason Chen at Gizmodo gets the USB storage mode wrong (twice!), then writes: "pressing the power/end button, which you'd think would power up the screen, actually just hangs up the call." No, really? The end button ends the call, just like on every other cellphone ever made? Who'd've guessed?). This isn't a review per se, just some thoughts spurred by the device.

With this being the month that so many new phones are being released--the Pre, the N97, and the HTC Magic among them--why go with the old G1? The answer, like my botched attempt at origami self-portraiture, is threefold. First, I prefer hardware keyboards, and the Magic is touchscreen only. Second, although Palm's new OS looks intriguing, it also looks largely locked-down at the moment, and Symbian has the same problem. Android's hackability is a big advantage. Finally, I need a GSM phone for a variety of reasons, and the Pre is CDMA-only at the moment.

Another thing I've been thinking about since the reviews for the Pre started rolling in: building a platform based on AJAX with hooks into the OS is clever, but it's also short-sighted. After all, developers on any of Palm's competitors--iPhone, Android, and soon Qt on S60--have the ability to easily embed a Webkit view into a native environment, complete with hooks in and out of that view. I'm guessing within a year of the Palm SDK release, I'll be able to run WebOS apps on other smartphones, either via a dedicated emulator or clever tools like Oilcan, Jeff Sharkey's port of Greasemonkey to Android.

The Android's Dream

My first reaction to the ADP was that it's a remarkably solid device. It's mostly plastic, but it doesn't feel cheap at all. The one thing that jumps out, after reading commentary online, is how unobtrusive the "chin" is. The actual angle for the trackball area is only about 10 degrees--really very subtle. It quickly becomes obvious that for prolonged web browsing or interaction the natural way to hold the phone is very similar to a Sidekick, with the screen flipped up so that one hand can type or use the screen while the other supports the device and manipulates the trackball for fine selection. Going between the trackball, touchscreen, and keys is flawless, and each has its uses--Google's done a great job there.

The battery life is not fantastic, compared to S60 devices that are exceptionally frugal with power. I usually charged the Nokia E51 every three and a half days, when its power meter dropped to three bars out of seven. With similar usage, it looks like I won't have any problems making it through the day with the ADP, but I'll probably want to charge it every night, since I've been hitting around 40% by the time I go to bed. Luckily, it charges via standard USB cable, and I spend my entire day surrounded by USB ports, so I shouldn't have any problems.

Power drain's a very personal thing, however, and someone else's experience might differ. For example, I work in an office all day, usually in front of a computer with my webmail open. So I don't usually set the phone to fetch e-mail automatically--what would be the point? Likewise, I don't use GMail, so I've unchecked its synchronization option to save a little bit of energy. The radio is always the most expensive part of the phone, power-wise, and I try to be smart about how I use it. While I do a fair amount of browsing, checking Twitter, and (since Belle loves being able to send me instant messages) GChat, it's possible that I'm not pushing the battery as hard as others would.

Speaking of radio, though, one of the interesting differences in outlook between S60 and Android is the way they treat the data connection. On Nokia's phones, connections are discrete channels initiated in response to a request. So if you want to go online, the phone opens a connection, letting you know which radio is in use, or asking you which one you'd prefer. When you're done, it shifts the radio back out of packet data mode. Android, in contrast, is online all the time, whether it's using the connection or not. It'll switch to the WiFi if a known network is available, but otherwise keeps the packet radio warmed up for you. Apparently it doesn't require much power to let the radios idle this way, but it does take some adjustment to stop worrying about it.

Another radio note: I'm using the phone on AT&T, and since it's set for T-Mobile's 3G frequencies, I'm back on EDGE for the time being. I don't really miss the bandwidth so much as the response time: 3G connections have a lot less lag, which is noticeable when browsing and particularly so in an SSH session. A lot of mobile-optimized websites nowadays disguise this with some client-side Javascript, which is a nice touch, but they bring their own problems: Facebook's Android/iPhone site is very clever, for example, but it's much less functional than the low-tech mobile version.

To Live in Fear

For Windows Mobile or S60 users, the hubbub around tethering seems misplaced. It's built into those two platforms: plug them into a laptop, or pair them via Bluetooth, and the laptop can almost instantly go online using the phone as a modem. US carriers don't usually care for this, since they'd prefer to be able to charge twice for the same bandwidth, just because it's being piped to another machine. On the iPhone, when someone created an application for tethering, Apple pulled it from the store to keep AT&T happy, and a user can't get it from anywhere else. There's no option for consumers/hackers outside of the walled garden. When Apple adds the option to the OS itself, it'll probably in a way that enforces AT&T's bottom line.

Google also has an application marketplace on Android phones, and although they're not as arbitrary as Apple, they also don't allow tethering applications to be sold. But here's the difference: Google doesn't stop you from distributing Android packages outside their store, either via a connected computer or directly through the browser. So there's nothing to prevent me from installing TetherBot on my phone and using it as a web proxy (a poor man's tether), or running PdaNet for a slightly easier ride (technically-inclined users have additional options). This is the simple value of an open platform: the device is owned by the users, not by The Man.

The ADP, and Android by extension, reflects a tension between openness and ownership. Google ultimately profits from open standards, something it knows well and reaffirms at every opportunity. So while it removes offending software from the official marketplace with a wink and a nod to free development, it's hard to miss the way that almost everything on the device also connects back to Google. Contacts, calendar, maps, the ever-present search (which includes the address bar in the browser, doing dual duty as a Google search field with autocomplete)... all of these are feeding back into Google, and being fed from it. It's understandable to be a little paranoid about that.

As Bruce Schneier says, computing has always been about trust, and cloud computing hasn't changed that any. So how much can you trust Google with all the information that a mobile platform can provide to them? And really, how much choice do you have, even on other smartphones, without giving up many of the advantages of these devices? It's not like there's another, better local map search, or a webmail service that comes close to Google's offerings. It's probably not technically a monopoly, per se, but it does indicate just how much power the company has amassed. One day we may have to nationalize those guys, just for our own protection.

I've Done... Questionable Things

You can array smartphone platforms into a spectrum between two extremes: those that trust users, and those that protect them--protection being a synonym for "limit." The iPhone, for example, does not let users touch the filesystem or run multiple applications at once. I've seen this described as a way of safeguarding the experience: apparently, people find the idea of closing programs to be confusing. At the other end of the spectrum is Windows Mobile, which is ironically the most user-hackable of the consumer options. Everything's pretty much open to interference, and you can run as many simultaneous applications as you want. Android is not quite at that level, I think, but it's definitely at the more trusting part of the spectrum. What's I find interesting about this is that while defenders of the protectionist model claim that it keeps things simple for users, once you step out into more complex applications, it's actually a huge obstacle.

For example, thanks to the open development platform, I'm got ScummVM on the ADP. Loading my old Lucasarts games is as simple as hooking up the USB cable and dragging the data files onto the SD card. On a stock iPhone, there are no easy facilities to do this--ScummVM would have to have its own conduit for getting the information over somehow. Even on a jailbroken device, you've got to resort to hacks like SFTP. And the advantages of multitasking are obvious: if nothing else, location-based applications like Locale wouldn't be possible without it.

Ultimately, the protectionist model does an interesting thing: it conflates applications and data from the user perspective. The e-book formats used by Stanza and Eucalyptus might be exactly the same, for example. But you'll never be able to read your Stanza books in Eucalyptus, and vice versa. The applications and their files are inextricably linked. It creates a world where code is often just host for a single set of data, each locked in its own little cabinet. There's no real incentive for interoperability or standards, and the platform itself is training users not to expect any. Some people may prefer that, but I think it makes Jonathan Zittrain's warnings look a lot more prescient.

Anyway, apart from ScummVM and Locale, there's a lot of very nice software on Android already. I'm impressed with ShopSavvy, which finds prices online and locally based on product barcodes. ConnectBot and AndFTP are great for logging onto Mile Zero--the latter is especially a relief, since S60 never did get an SFTP client. There are a few augmented reality applications that show a lot of potential: SkyMap uses the compass, accelerometer, and location services to provide a live star guide, and Wikitude overlays the camera view with local travel information like something out of Virtual Light. I've been using Twit2Go for Twitter posting, and PicSay for image editing.

The built-in applications are largely great. Browsing, maps, and YouTube work pretty much as you'd expect. I do wish there were an easier way to connect Contacts and Calendar to their Outlook counterparts. Loading phone numbers from the latter required uploading a CSV file--it worked pretty well, but not something I really want to do on a regular basis. The one exception to the high level of quality is the POP3 email program, which is patently awful. It doesn't remember which messages are already downloaded, refuses to delete items from the server, and regularly fails to connect. I'm using K9, an open-source client, instead.

In general, the OS is sturdy and tasteful, but not flashy. One feature I do like a lot is the unlock screen: it presents a 3x3 grid of dots, and you draw a pattern between them as your "passphrase." Ironically, this is not terribly secure since, like all touchscreens, it eventually ends up with fingermarks all over it. If you don't wipe it down after locking it, the pattern is often still smeared across the screen, especially if you're a heavy trackball user. The notification shade is also pretty genius, and key to the multitasking implementation. Someone needs to invent a quick task switcher that sits in the windowshade, and then it'll be pretty much perfect.

Overall, I'm comfortable replacing the E51 with this phone, but I'm probably not going to get rid of it entirely. There are still uses where Nokia has the edge: real tethering, speed, battery life, and size among them. And I hope their steps toward open-source models, and their sense of corporate social responsibility, will provoke Google as well. After all, someone needs to do it.

May 26, 2009

Filed under: tech»mobile

Hope Phones

Joshua Nesbit's Mobiles in Malawi (now Jopsa) is a very cool bottom-up health development project: using a copy of FrontlineSMS and a bunch of cheap cell phones, it allows community health workers in Africa to network with patients and each other, producing more efficient checkups, patient-tracking, and emergency response. Nesbit says in six months, a hospital using this system saved 1,200 hours of staff time, as well as $3,000 in motorbike fuel.

Jopsa has now launched a side-project called Hope Phones, allowing people in developed countries to contribute, both ecologically and financially. The program takes in discarded phones, recycles them, and uses the cash from the recycling to buy multiple appropriate (read: cheaper, more durable, and longer-lasting) phones for health clinics. They even pay for the postage. It's a fantastic win-win situation, as Trackerblog writes: the recycled phones not only reduce the number going into a landfill, but they reduce the industry's dependence on "conflict minerals" like coltan and tin.

Americans and other developed nations throw away a massive number of cell phones every year. Recycling helps--but Hope Phones, I think, is even better. Something to keep in mind the next time I upgrade.

Update: Jopsa has a post about the progress made by the program since its launch a week ago.

May 1, 2009

Filed under: tech»mobile

Area Code 575

So you've gotten yourself a mobile device that does e-mail--a smartphone, Blackberry, tablet, whatever. Now, how do you let everyone know how important and technologically-savvy you are? The mobile signature line, of course!

This being DC, about half the e-mail in my work inbox contains the phrase "Sent from my Blackberry." "Sent from my iPhone" has yet to show up, but it's probably only a matter of time. And although I mock them, these postscripts are obviously useful as a way of preemptively apologizing for the short length, SMS-style spelling, and typos that inevitably result from text entry on a tiny keyboard. Or, as one Lifehacker post advises, maybe they're just lazy.

I actually try to keep my mobile messages grammatically-correct, but there's no doubt that my typical outpourings are a bit reduced when I have to tap my way around predictive T9. So while I wanted a signature line, I'd prefer something that's less branded, less bland, more... haiku?

Nine keys for typing
Brevity thus expected
Sent from my cell phone

What's your signature selling?

February 5, 2009

Filed under: tech»mobile

make -widget

When people talk about scripting on S60 (and you know what a hot topic that is), they usually mean Python. But there are actually two scripting engines on the platform: in addition to PyS60, there's also a Webkit-based widget engine for building apps in Javascript with some hooks into device functionality. Widgets have to be compiled into a .zip-based format, though, which means that (for me, at least) the whole appeal of a scripting language--the ability to cobble together quick solutions on the fly--is basically lost.

That said, I do like Javascript, particularly as a "scratch pad" kind of language. And the .wgz files used to install these apps can be created on a phone, using the Zip Manager program and a decent file manager. It's just a pain, during each "recompile," to delete the old .wgz, create a new .zip, add the project files, close it, change the extension, and run it again. Exactly the kind of thing, actually, that Python could easily automate.

In that spirit, wgzPackager.py is a kind of compiler script for generating Web Runtime widgets on S60. It takes care of archiving (hopefully with the right structure), renaming, and even runs the installer file for you. This should take a lot of the pain out of creating widgets on the phone itself. It's not flashy, but it's fast and can be run repeatedly with minimum hassle--I thought about adding a GUI, but I thought for the intended audience streamlined execution was probably a lot more important.

To set it up, you'll need to create a directory containing the widget project as detailed in the WRT development guide, including an info.plist XML manifest for the application. Next, edit the wgzPackager script to point it toward this directory: the relevant variables are dirString and wgzString, with the former being the directory above your project, and the latter being the project name itself. So, for example, I keep my projects in 'e:\\documents\\wrtdev\\' (the backslashes are doubled because they have to be escaped), with a subfolder of 'AppName' for each application.

I hope somebody finds this useful, but to be honest, I'm ambivalent about widget programming on mobile. It still strikes me as too limited, too slow, and too resource-hungry to be enjoyable. On the other hand, I recently started looking through Symbian C++, and that's a nightmare: oddities like two-phase constructors and the weird garbage collection stack mean that it's hardly in a good position to foster developer interest in the platform. And since, as far as I can tell, S60 is the smartphone platform with the greatest amount of flexibility and software freedom, having good developer support is important. I'm hoping that Nokia's upcoming port of Qt for S60 development will change things, by eliminating a lot of the weirdness and giving it a strong foundation for moving forward. In the meantime, if Python's not your thing, I guess widgets are the way to go.

January 26, 2009

Filed under: tech»mobile

Mobile Site Machinations

Nokia's Mobile Web Server (a port of Apache paired with a dynamic DNS service) is one of those "because it's there" kind of things. Not only does that seem to be largely why they built it, simply to prove that it could be done, but that's the spirit in which I've installed it. Do I have any good reason to run a website from my phone?

In fact, this is probably the wrong question. The point of the MWS isn't just to drive a website, although that's pretty cool. It's also to open the phone up to the lingua franca of Web 2.0: HTTP requests. There's a whole world of information services out there standardized on exchanging GET and POST over the Internet, but it can't usually talk to a phone without going through a proxy of some kind. The Mobile Web Server changes that--take a look at the services exposed through a REST API to see what I mean. In this scenario, your mobile presence isn't a limited client to the cloud--it's a full-fledged node of its own, capable of being directly queried and extended with new capabilities.

In developing countries, it should be said, we're seeing applications that work the other way: computers are learning to communicate via SMS with phone users, or to transfer data over the SMS channel instead of using data packets. Mobile applications in the developed world have been forced to either adopt this method of communication (like the SMS functionality on Twitter, or Google's short code) or distribute special code as discrete programs for communicating--the mobile Facebook and Google Maps applications share a common method of talking to servers, but they install as completely separate binaries and can't talk to each other. This is, frankly, a pointless duplication of code, as well as going completely against the spirit of mashups that makes mobile access so intriguing.

That said, there are no doubt interesting pages that could be served from a phone, and good reasons to do so. It would certainly be a workable option for people with my paranoid fear of centralized coordination, if you could find a way to create lots of routes to the dynamic endpoint (or to let people know the IP address when the phone goes online). For notification purposes or short announcements, RSS is more than sufficient: it's versatile, lightweight, likely to be available on a lot of phones in nthe near future, and (as Daniel O'Brien notes in one of the essays I linked yesterday) reliable enough. People don't need 99.999% reliability, O'Brien correctly points out, and RSS readers will just keep polling until a site comes back up. Frankly, for dissidents, always-on hosting might even be a disadvantage.

Another trend lately has been using phones for data collection, taking advantage of the cameras, accelerometers, and GPS/location sensors built into the devices. Nokia's version of Apache gets access to all the APIs normally available to Python, including SQL databases and most of the hardware. The idea of making that data accessible via a web interface--or indeed, being able to interact with it and control it live--is pretty powerful. But more importantly, building that interface through the web server means that it's capable of being a self-contained presentation tool for the data it gathers. The phone may not be able to run the latest version of Flash or compile Javascript at full speed, but it could certainly host viewers in those languages for clients connecting over the network for a portable, no-install data-crunching session.

And finally, of course, there's the possibility of simply hosting a standard website on the phone. I can't imagine running Mile Zero this way, but there are some kinds of content that would be tempting just because of the accessibility of the platform--voice/audio posts, perhaps, or a constantly-updated picture blog. If nothing else, there's the "because it's there." Why host a web page from my phone? Well, why not?

January 16, 2009

Filed under: tech»mobile

Palmed Off

This week, Palm announced a flashy new cell phone called the Pre. It's based on Linux, and runs its applications as HTML/Javascript with hooks into deeper APIs (similar to Nokia's Web Runtime). Unspoken, this is Palm's announcement that they're finally driving a stake through PalmOS, the operating system that made their name (but which, for licensing reasons, they don't actually own anymore). And it's about time. For years, PalmOS has been the Mobile Thing that Would Not Die, and its ab-life hasn't done anyone any favors.

I should qualify that statement by saying that there are a lot of points in PalmOS's favor: as someone who got started programming C for the platform, I have fond memories of versions 3 and 4. Indeed, at the time, PalmOS was well-designed for the challenges it faced. Unlike Windows CE (which ports a subset of the Win32 API to embedded platforms), it was meant specifically to run on very low-end (read: cheap) hardware while still responding quickly. It did this through an event-driven application model that put the processor to sleep as often as possible, as well as a GUI that faked multitasking by having programs remember their state and relaunch in the same place. API calls were, as far as I remember, pretty much just bare pointers to functions in ROM, and you could patch the system traps with your own code to extend OS functionality, like fixing the anemic clipboard or adding pull-down menus.

Much like the Newton, PalmOS didn't have "files" in the traditional sense. All data on the device, including applications, was stored as records inside databases. Inside applications, GUI layouts and components were stored as entries alongside records containing binary code, making it an interesting platform to hack. On both platforms, it soon became obvious that while this is an interesting idea that provides some advantages, people have a lot of files that don't naturally fit into database records, and flat file support was bolted on. Unlike the Newton, Palm didn't try to implement full handwriting recognition, which is troublesome on mobile platforms for several reasons: the device is too small to write comfortably, parsing handwriting requires a lot of processing power, and it invariably fails in the face of chicken scrawl. Instead, they went with Graffiti, a set of simplified letter shapes users had to learn--this sounds cumbersome, but it worked surprisingly well. To this day, I can still write in Graffiti almost as fast as I can scribble longhand.

Palm made choices, in other words, aimed directly at creating a device for quick data lookup and entry. It was never meant as a multi-use mobile computer. And as time moved on, and users began to expect more out of mobile, that became increasingly obvious. The problem Palm faced was two-fold: it didn't want to leave behind the tens of thousands of useful programs that were the platform's greatest strength, but the underlying framework had been stretched the point of breaking.

The solution they created, comically, was to write a modern OS devoted almost entirely to emulating the old operating system. The PalmOS devices that you buy in a store nowadays do just this: programs are compiled for the Dragonball processor (with possible chunks of the binary in native ARM code), then run in a virtual machine with holes poked into it for networking and graphics. It's actually kind of brilliant, in a twisted way--like Java, if Java had been designed by old Apple hardware nuts instead of computer science professors. They've even made a VM for Nokia's Internet tablets, and another company has ported emulators to Windows Mobile, Symbian, and OS X Mobile, raising the very real possibility that classic PalmOS could actually become a defacto interplatform standard (a task for which, honestly, it's not badly suited--or, at least, could hardly be worse than Java's MIDP/CLDC mess).

That said, it's not a great basis for moving into richer mobile software. Even speaking as someone with great affection for PalmOS who finds its emulated incarnation ingenious (or at least highly amusing), the cracks in its foundation have gotten pretty blatant, so that tearing it up and starting again was probably the only way to go. Maybe someone could write an emulator in Javascript--it's probably possible, at this point, and for sentimental reasons I'd love to see it. It's a little sad to think that the PalmOS where I learned a lot of skills will finally vanish. But sentiment's not a good enough reason to halt progress. You'll be fondly remembered, PalmOS, but you won't be missed.

November 11, 2008

Filed under: tech»mobile

Given Latitude

Here are two Python scripts for getting latitude and longitude position from Google based on GSM cell tower ID numbers:

The first script is a slightly altered version of the script written by Google Maps Internals, with the struct.unpack() code updated (it originally cast the longitude into the wrong type). It hooks into the low-level data format used by the Google Mobile Maps application on S60 and other platforms instead of using JSON. This is very cool from a hack position, but it's obviously also very fragile, since the GMM API is unpublished and changes on Google's end can break it easily (and may have already done so, hence the improper cast).

The proper way to do this, then, is using the second bit of code, which accesses Google's JSON-based services. The primary function in that file, gGSMLocation(), is actually not specific to S60. It takes as its only argument the four components of a GSM cell tower ID in a tuple: the mobile country code, mobile network code, local area code, and cell ID, in that order. It returns the Google JSON object as a string. I left the return format serialized because working with JSON on PyS60 (or, as far as I can tell, any Python) can be a real hassle, and you may have a favorite approach. In Python 2.3 or later (S60 uses 2.2), you should just be able to use json.load() from the included modules.

The second function in the file, gGSM(), is useful only on Nokia phones. It's just a simple wrapper that feeds location.gsm_location() directly into gGSMLocation(), no arguments needed.

Working on this kind of code is frustrating in equal parts due to Nokia's design decisions and the limitations of Python itself. On Nokia's part, its idiotic code-signing initiative means that loading new libraries (such as JSON or XML parsing) into Python without cracking the signature check is way more trouble than it's worth. If you've broken the signature, you can just copy .py modules to c:\\resource\\, and .pyd modules to c:\\sys\\bin\\, but you can still run into platform security errors.

None of this is helped by the fact that Python is a pretty weird place to work. If you're used to ECMAScript, it's frustrating working with a scripting language that doesn't allow dynamic object creation, or doesn't support an alternate dot syntax for dictionary properties like Javascript does. The implicit declaration of variables, likewise, is kind of jarring--they just pop into existence, compared to a language with a dedicated "var" or type keyword. On the other hand, Python's significant whitespace is almost as annoying as the forest of brackets and parentheses used in Lisp or Objective-C, particularly on a mobile platform where screen space is at a premium.

Python actually has a quirk, I think, in that it's often pitched as a good learning language due (in part) to its lack of punctuation for blocks and line endings. But the flip side to that approach is that advanced code contains underscores (which are used to signal metaprogramming and low-level functions) and weird punctuation in direct proportion to its complexity. I feel like the learning curve goes from flat to nearly vertical the moment those underscores make their appearance, which seems like a serious flaw in a teaching language. Perhaps it's different when you're not teaching yourself.

In any case, I don't know what you might want to do with your latitude and longitude, but I hope people might find it useful. I have a few ideas I'd like to try, like creating a lost-phone-locator over SMS and a geotagged link generator, that could be useful for some work and hobby projects coming up. But these kinds of scripts are useful for all kinds of problems--Ethan Zuckerman recently wrote about farmers in Kenya who are using phones and GSM IDs to track elephant movement and protect their crops from pachyderm predation. You never know what you could do, given a little latitude (and longitude).

July 1, 2008

Filed under: tech»mobile

Open Access Control

Back when the iPhone first appeared, in response to its locked-down development environment (Shorter Steve Jobs: "Sure, you can make iPhone applications, if by applications you mean 'web pages'"), Nokia launched a short-lived ad campaign called "Open to Anything" for its N95 smartphone. They put up some posters and bought some TV time, and then they went back to doing what Nokia does best: ignoring the American market.

As a shot at Apple's legendary control-freak tendencies, it was a good one. But the sad part was that it just wasn't true: the N95 runs on Symbian 9, which requires applications using "protected" APIs (camera, networking, personal data access) to be digitally certified before they can run, for security reasons (probably an overreaction: a couple of extremely limited viruses had been shown running on the platform).

This is not to say that Nokia's phones aren't relatively open--even compared to the iPhone v2, which will introduce a centralized application store, Symbian devices are still much more accessible, and potentially more powerful. There's an open-signed program that allows developers and users to authorize a program with high privileges on a single phone. A number of Nokia's tools are open-source, including the Python interpreter that allows users to write and run applications on the device, using its full capabilities. And the standard browser on S60 is a Webkit-based system that runs Javascript and even some Flash apps.

And in theory, the principle behind the app signing is not a bad one. Sandboxing applications by capability is pretty much the same concept at work behind sudo on Unix, gksudo/kdesu on Linux, or UAC on Windows. As smartphones get more sophisticated, this will have to happen on mobile platforms as well if they want to use their full potential. The mistake Symbian made was not to enforce security, but to take it out of the user's hands.

Perhaps ironically, the mobile OS most open to developers is Windows Mobile, which offers free development tools and no code-signing or approval process required. You can even get some of the source for Windows CE, if you're into that kind of thing. The catch is that it needs to be this open, because Windows Mobile is not terribly useful without a fair amount of third-party software (and I say that as someone who actually likes the platform).

I probably would not be writing about this, except that I ran into a problem with PED, the Python editor I use on my phone. While I was messing around with the camera, I kept running into errors even though my code was identical to the examples from Nokia. Eventually I figured out the problem--the Python interpreter itself is signed with full privileges, but PED is not. In order to test scripts using the camera, I had to run them in the standalone Python shell instead of PED's built-in launcher.

Not cool. Kind of runs against the notion of an Integrated Development Environment when it's not actually Integrated. Again, I'm complaining about details, since the ability to write and run scripts (in a standard language) on the phone itself is still pretty advanced stuff. But it's a frustrating, needless, arbitrary detail--as details tend to be when security control is placed under control of a third-party.

In the end I installed a hack created by some Spanish developer that overrides Symbian's certificate check. Effectively, I "jailbroke" it. This means I can't upgrade the firmware on the phone, since new versions of the firmware intentionally closed off the security hole used in the hack--nice "open to anything" support, Nokia. Luckily, the existing firmware updates seem to have been pushed out primarily to close said hole, and don't offer any new capabilities that I need.

There is always going to be this dynamic on mobile devices: how paranoid are we going to be? Lord knows the communication infrastructure in this country often seems far from robust, so some attention to security is certainly required. But none of the existing answers seem sufficient. Windows Mobile simply has no real security model. At the other extreme, the iPhone will only run Apple-approved applications in a small sandbox without access to the filesystem, multitasking, or low-level hardware--no Bluetooth keyboards, wireless headphones, or copy-and-paste unless they come directly from Apple, I'm afraid. And in the middle, Symbian has its signature program, which is much less irritating, but it's certainly not "open to anything."

I have my own doubts that the mobile revolution in this country is going to arrive anytime soon--I suspect that the ridiculous cost of data rates on cell plans will keep it stillborn. And the most interesting uses of mobile technology that I see elsewhere are often decidedly low-tech: microbanking and automated information services over SMS or voice, the kinds of technologies that aren't Web 2.0 but have changed lives in lesser-developed countries. Nevertheless, any real innovation in mobile, location-based services is going to require actual open systems for development. I like that Nokia is bringing snark and criticism of the tightly-locked carrier ecosystem to the table. But I hope that as it has announced plans to open-source Symbian, the company will also be starting a real, flexible, consumer-friendly security model, instead of the opaque Symbian Signed system.

June 27, 2007

Filed under: tech»mobile

Didn't PAN out

In 1996, IBM begins researching the personal area network:

as electronic devices become smaller, lower in power requirements, and less expensive, we have begun to adorn our bodies with personal information and communication appliances. such devices include cellular phones, personal digital assistants (pdas), pocket video games, and pagers. currently there is no method for these devices to share data. networking these devices can reduce functional i/o redundancies and allow new conveniences and services. the concept of personal area networks (pans) is presented to demonstrate how electronic devices on and near the human body can exchange digital information by capacitively coupling picoamp currents through the body [emphasis mine]. a low-frequency carrier (less than 1 megahertz) is used so no energy is propagated, minimizing remote eavesdropping and interference by neighboring pans. a prototype pan system allows users to exchange electronic business cards by shaking hands.

Instead we got Bluetooth, transmitted over boring ol' radio waves. It's too bad IBM's research didn't get more traction. There's something appropriate to the idea that the earpiece-wearing Blackberry addicts on the Metro might have to coordinate all that gear by running low-powered electric shocks through their bloodstream.

Future - Present - Past