Mike Rowehl: This is Mobility

Yahoo had a few services bundled under the name Next that looked interesting. They didn’t support S60, which made me sad. So I posted to the public forum for Next with my S60 woes. I subscribed to the forum (XML feed.. sweet!) and saw a few messages in my aggregator but mostly ignored them cause they didn’t seem to be related to what I was looking for.

But then today I tried to check my Yahoo mail using IMAP and it wasn’t working. Looks like Yahoo is no longer offering IMAP access to their mailboxes. And what’s the response from Yahoo:

We are no longer providing this service at this time. Please check with your wireless service provider for Yahoo! Mail services.

Check with your wireless service provider. Ahh, that’s more like it. I was wondering how one could possibly provide a useful service to mobile users that spans multiple access styles. It just didn’t fit with the existing offerings. It’s good to see that the carriers have shut down this potential blight of usability and convenience upon their networks. Now we’re back to expensive walled-off messaging. Remember to mention to your carrier that you love them for restricting your choices next time you have to talk to their sales or support.

I was chatting via IM with some friends today about setting yourself away when on IM to avoid people, or going invisible, or just not signing in at all if you have work to do or want to avoid some folks. And I realized that I left out one of the coolest comments from the June BayCHI meeting. I think it was Simeon Yates who said “SMS conversations never end.” I think that simple statement does a lot to call out some of the major differences between something like an IM or chat session and the use of SMS. It’s always on and available, and there’s no presence info. Once you start an SMS conversation with someone that’s it, they can keep it going if they want to no matter where you are and your willingness to receive.

I’m talking in generalities here, obviously you can call your operator and get them blocked or go to the persons house and steal their cell phone. But the affordances for the basic techniques of managing interaction aren’t built into the SMS interface. The totality of that control lies in knowing your phone number. It really helps to explain why there’s a much different set of evaluations to make when starting an IM conversation than there is with starting an SMS conversation. And why spam over SMS tends to evoke a much stronger reaction than SPIM.

As I mentioned the other day I’m searching for some sync options. So when I saw Jon Udell’s post about uploading Mozilla Calendar events to Google Calendar I immediately started wondering about doing the same thing for an S60 phone using Pyhon. So I put together a sample script for pushing events out of the native calendar on a Nokia phone to Google Calendar. My little sample just does the events for the current day, but I’m sure anyone interested in hacking on it will get the idea pretty quick.

The Nokia version of Python only has the original httplib. There’s a version of httplib2 that includes the Google Authentication handling. It’s possible I could have taken the httplib2 library and just put it on my phone, it looks like it’s all pure Python. However I’m not much of a python pro, so I just handled the authentication and redirection stuff. It’s actually pretty simple, so no pain. It would be interesting in general to see if httplib2 works on the phone though… maybe another time.

Rewind your technology time (those of you who can) to 1998. Back to a time when people didn’t laugh when you said you used a Palm device and there was still a grand vision of personal information flowing into and out of all sorts of devices gleefully chattering at each other when they’re supposed to and not just spitting out your info to random strangers when they’re not supposed to. Back in the day we used to read stuff like this during breakfast without the fear of spraying milk out of our noses. Here’s a sample:

“Bluetooth” benefits

“Bluetooth” will eliminate the need for business travellers to purchase or carry numerous, often proprietary cables by allowing multiple devices to communicate with each other through a single port. Enabled devices will not need to remain within line-of-sight, and can maintain an uninterrupted connection when in motion, or even when placed in a pocket or briefcase.

“Bluetooth” technology will offer new ways in which a user can use personal mobile devices, both for professional and personal use:

* Users will be alerted to, and can respond to, incoming e-mail via their mobile phone, even while their mobile PC remains in its carrying case. When the PC receives an e-mail message, an alert will sound on the mobile phone. It is then possible to browse incoming e-mails immediately, reading the contents on the display of the mobile phone.

* Users will be able to access the Internet via a completely wireless connection routed either through a mobile phone, or a wired connection such as the PSTN, an ISDN line, or LAN.

* Users will be able to send an ‘instant postcard’ by cordlessly connecting a camera to a mobile phone or any wire-bound connection. Users could add comments to their snapshots using a mobile phone or mobile PC, and send them instantly to recipients anywhere in the world.

8 years ago, wow, how time flies. And our little baby Bluetooth is all grown up. The problem is, we’re not all that proud of him. He just kinda wanders in and out without telling anyone, gives the car keys to his friends, and smashes the place up every once in a while. But hey, he’s our kid and like it or not we have to deal with him. Fortunately, for my purposes, a nice swift kick and the occasional backhand count as ‘dealing with him’. In the spirit of healing I feel it appropriate to share.

I’m not a bluetooth naysayer. I would love for it to work, I just unfortunately find myself dealing with disappointment after disappointment. Way back in the depths of time I hacked up a tool that used to be meant for an old Linux bluetooth stack called Affix and made it work with Bluez. It was a shit simple tool called ussp-push that I jammed together in two hours one weekend so that I could transfer images to my t68 without having to pay the per-KB charges that were the norm back then. I took the site where that software was hosted down years ago. Yet I still find it linked all over the place when I do searches for stuff like “Bluetooth sync” or “Bluetooth calendar” or “Bluetooth Linux”. And that’s all I find.

Now I’m sure someone out there is thinking “Hey, there’s Linux Bluetooth sync packages, I use SyncML and GnuBox and Multisync to move my stuff over to Evolution”. Yea, great, I’ve kinda sorta gotten stuff like that to work before as well. But the grand vision we’re going for here is the magic of automatic syncronization. When my phone and my desktop come into range they should blip little invisible magic faries carrying bluebits back and forth and my contacts should now be merged on both sides.

I’ve started using obexftp because it actually works without me having to do anything on the phone. I leave my phone plugged in next to my computer at night. My computer can scan for my phone and connect via obexftp and manipulate files on the phone. Fantastic! I can use that to grab new images from my phone and keep them archived:


obexftp -b 11:22:33:44:55:66 -B 12 -c E:\\Images -l
obexftp -b 11:22:33:44:55:66 -B 12 -c E:\\Images -g 06042006.jpg


or push podcasts or video over using the same tool. Wow.. looking pretty good I must say! Just need to get those contacts and calendar entries out. My old phones used to have an IRMCSync service, but not so on the Nokia. It uses SyncML over OBEX over Bluetooth. Which everyone seems to avoid. They use Bluetooth to form an IP connection and then use SyncML over IP. Nice that it works, but useless for my automatic sync because setting up that IP tunnel is not transparent. So how about the Nokia protocols they use, supposedly MBUS and FBUS and who knows what else.. just take a look at this mess of a standardized library for access to mobiles. I’m not even sure my phone is supported. I tried it out and can’t get it working. If anyone knows about support for these protocols please let me know. Even just a starting point that I should be able to test and then work out from there.

So how about the extended AT commands for GSM equipment? Well the phonebook and calendar read/write functions are optional, and Nokia has opted out of them. Damn! Okay, so how about falling back on the obexftp stuff and using obex to pull the data files right out from under the OS and parse them somehow to get the info out? Unfortunately obexftp doesn’t list the System directories that those file live in. But guess what.. feed them into obexftp anyway and you can access the files in there. However when you try to grab the actual files we want to use you end up with errors. Grrr!! Apparently the operating system is holding onto those files in some way and not allowing access, even for just reading.

That’s where it stalls unfortunately. Anyone know how to go about getting something like this working? Are the Nokia protocols a good method? Should I be looking at the SyncML end instead? Is it going to require writing some kinda Yahoo Go style app to move the stuff around? God that would suck, but at least I would end up with my automatic sync.

I met Hansmeet Sethi from Onskreen at a mobile gathering in Palo Alto this past week. Onskreen has an interesting app called Fusion that replaces the home screen on a mobile with a widgety set of information services. Recent S60 devices have included something called an “active standby” screen that has quick access icons for apps and some info from the built in apps. I expected that the active standby would eventually grow more functionality. That the information that populated it would become that compelling reason to pull out your mobile all the time and check it (if you’re over 30 that is, lots of folks under 30 already pull out their mobile all the time). Not so, sad Mike.

Onskreen has an app that fits that bill pretty well however. If you install their app on a S60 phone it’ll replace that active standby screen with a framework you can fill with configurable widgets. Some of the stuff is pretty neat, including search widgets in addition to the standard info services. It’s got a lot of potential. You can minimize the Fusion interface to get access to that active standby stuff already there. I would have liked it to be somewhat more integrated. A calendar widget, todo widget, pulling from the info on the phone already.

There also aren’t any widgets I can muck around with the way I wanted to. I wanted a generic RSS widget so that I could play around with spooling stuff to my handset using an app that just sits there and caches it. There’s no widget that does that in the catalog of plugins though, and the SDK is targeted at operators who would build their own services on top of the stuff. So no toys for me, but I still like the idea. The download is free to play around with, check it out. Unlike most of the stuff I’ve played with recently, this one didn’t even crash my phone. I guess that’s what one would call “carrier grade”?

Russ Beattie pointed me at this new mobile service from Yahoo called Next, and I was already trying it out before I noticed that none of the stuff supports S60. The email part is the only one that doesn’t explicitly say it doesn’t support S60, but message sending using the built in client on the 6680 didn’t work so I’m counting that as not supported. Normally this is where I would spin off into some frothing rant, but I’m not going to do that. Cause I really really want this to work on S60 devices! I want to be able to sync my contacts and calendar on demand. I can’t get Go to do that.

Granted, S60 devices get sighted maybe once every two or three years in the states, but they are popular in other places with lots of people. And Yahoo is a global company. Please, please.. can we have Next for S60 devices? I would be happy with just the SyncML stuff. You can leave IM and mail broken, I don’t really care about those. But I would LOVE to have a calendar system that syncs and I can use from online. I would even come down to the Sunnyvale office with cookies, promise. I would even be willing to ignore the whole elmo incident. Bygones.

Do you have a S60 phone? Would you love to see these glorious Yahoo services support it? Pop into the discussion area and let them know.

I’ve been working for a while with Omar on AdMob. Things have been going fantastic so far. It’s given me a lot more insight into what’s happening on the mobile web than any of the other stuff I’ve worked on. Omar is great to work with, and I got a chance to meet Russell Buckley and have some great conversations over the last week. So today we just signed the papers today to make me an official AdMobber! I’m sure that means I’ll be soapboxing about mobile web stuff even more than I have been so far. Right now however I want to let you know that we’re looking for a few more people for the team. We’re looking for engineers for the server side (LAMP stuff) as well as sales folks. Drop me a line at mike at rowehl dot com if you’re interested.

The newest edition of the S60 platform from Nokia breaks binary compatibility. That means that applications which ran on 2nd edition devices will not run on 3rd edition devices. Apparently the porting barrier is pretty low (see the writeup at AllAboutSymbian for some info on the currently available apps) but that doesn’t change the fact that it is a binary break. The more I hear people talk about the issue the more I’m reminded of newspeak from 1984. Perfectly rational and generally well informed people start a conversation about the binary break discussing how terrible it is, but eventually come out the other side saying it isn’t that big of a deal.

It just reminds me of one of the repeated blind spots I see coming around in mobile over and over, that people close to a problem tend not to see the problem. People inside mobile have to live with the the binary break, and once they understand it they tend to ignore it. However that’s a crippling issue when having to deal with the mass market. When normal users get burned by the break because they have no idea they should even be concerned, there’s gonna be hell to pay. Just because the apps are available doesn’t mean the incompatibility problem is solved.

How long are publishers going to have to carry multiple Symbian versions? And require that users know if they have a v2 or v3 phone. If you can actually find someone in the US who has a Symbian phone, try asking them what version of the OS they have. Normally they’ll just stare at you. About 5% might say something like “I think it’s Symbian”. Ask them what model phone they have. I tried this acidentally actually. I ordered a 6680 from overseas when they came out, I really wanted one. And I knew they were coming out in the states as 6682 at some point, but I wasn’t following the release news. So I would ask people “If that’s the 6682?” when I saw them with a device that looked like mine. Outside of the people actually at the Mobile Monday events no one knew what I was talking about.

One of the worst instances of newspeakish behavior I’ve seen with respect to this is self-signing applications. v3 of S60 includes a facility for signing applications, with the signed application being signed with a certificate chained from I’m guessing the root certificate at Nokia or Symbian, or the carrier or something. The details aren’t really interesting, except to note that it’s a basic trust extension model like that used by SSL. At which point someone says something like “yea, like SSL, and self signed certs exist in SSL. So self signed Symbian apps are like that! What’s the big deal?” Right.. except when you use SSL you still have encryption being used at the endpoints. I see no equivalent on the Symbian side, it seems just wasted overhead. It’s more like using PGP/GPG for your email messages. But instead of signing the messages you want to sign and leaving the other ones untouched you instead tack on a big chunk of meaningless data to the unsigned ones saying “hey, this isn’t signed”. Not very useful.

So what does self-signing gain you for Symbian apps? After hearing an explaination of signing most people go “Oh, yea, to protect users, so I can deal with self-signing.” NO!!! The question is still unanswered. What’s being done with the certificate info? Is it used when installing an upgrade? If I install an app for which I have a previous version does it check to make sure that the newer one is signed with the same key? If I take the time to validate the identity of an application publisher can I check the fingerprint ID against a hardcopy I got from them in advance? Can I install my own certificates, and will the phone then treat apps signed with those certs as trusted? I see answers to none of this stuff in the public discourse. I don’t even see mention of it, and that makes me think no one out there is really considering the issue.

And to top it all off, all that stuff I mentioned is geek stuff. No user is ever going to check fingerprint IDs for their apps. They’re just going to ignore the warnings and pound accept over and over till they get to their app. Which will probably end up somewhat crippled by the restrictions, and fundamentally uninteresting. So I just don’t see how this really benefits users. On the other hand.. I don’t have to think at all to see how it benefits Symbian, Nokia, and the carriers. It benefits them in a slash-and-burn/rape-your-customers/scorched-earth kinda way. But it benefits them directly at least. Good for them, hope they’re proud.

I had another one of those WURFL hacking episodes aimed at getting WURFL to work better for sites with large groups of active devices. And here it is. I’ve started calling it WURFL lightweight. Everyone looks up device info by user agent, so it’s optimized for that. It also assumes a few things:

• The suggested caching method, multicache, is the caching method being used. It will be, no choice about it any more.
• You want to front load as much work into parsing as you can. Parsing is a one-time offline process. Do as much as you can there to speed up the work that has to happen when a request comes in.
• Rewriting files as the library is working is bad. No more agent to id cache (though I might bring this back in some form. Tune in next update to find out why.. dah dah dah!), no more option to auto update.

And that’s all it does. I ripped out the code related to other stuff. Especially older stuff. And I tweeked the caching and algorithms a bit:

• The agent name to device id mapping files are divided up into a bunch of smaller files based on the initial two letters of the user agent. A lot less to load, and a lot less to search through.
• There was an loop over the user agents to find the one that matched that decreased the length of the agent to match by one character on each iteration and just scanned the array over and over. I thought maybe this was because the PHP implementation underneath was heavily optimized to handle those operations, but my testing hasn’t shown that. So I changed it to a single loop through the agents and finding the longest matching prefix.
• Sort the agents in the serialized array. This does change the matches for some devices. In the case where a user agent matches multiple entries to the same length the existing implementation returned the first match. Which I still do, but now that the entries are shorter that can be a different device. In some cases this corrects problems. In others I think it was acting as another defacto defaulting mechanism and I might have broken something. But in either case the differences list was pretty short (about 70 entries) out of the 3600 unique device agents I pulled from log files.

This one has given me quite a speed boost for the stuff I was testing with, we’ll have to see how it does in the wild. Here are the further refinements I’m thinking of:

• Move the fallthrough processing into the parser and make the multicache device entries flat. Pulling a device from the multicache means pulling the device entry itself. Look for a fallback entry for that device, and if present pull it. Repeat until you’re at the root. And then collapse all those entries into the device entry. Do all that processing in update_lw_cache.php and put the full version in the multicache file. We’re reading at least the same number of blocks or less, doing no processing. This should be a net win. Unless the common source for the base devices end up cached, and the processor time to merge them is less expensive than the cache hit from the extra working set. Hmm.. this is one to test, and could vary for different setups.
• Caching the user-agent to device lookup once we find a new one… like the agent to id cache did before.. HOWEVER not make it hold anything besides new agent to ID mappings. Then we can also make the initial lookup in the array hash the lookup, and only scan linear if we can’t find the agent we’re looking for. That’ll be pretty hot.

I helped out some with the Python on Series60 Phones presentation at SDForum last week, and I’ve been meaning to post about it. Hartti already put a post up, so I really have to.

I had a bunch of little code snippets to show off, stuff running on the device, cause I figured a lot of the discussion would be around the capabilities of the Python port. And there was some interest around particular areas like accessing location information (both the cell ID of the current location as well as interfacing with external Bluetooth GPS devices) and transforming the audio stream of an ongoing phone call (you can use the play() method to push a sound into an ongoing phone call, or the record() method to record chunks of a call, but as far as I know you can’t hook into a call as an audio transformer intercepting both inbound and outbound audio in realtime). But overall a lot of the questions were really about the mobile development environment as a whole and how Python fits into it.

Folks in the audience seemed to be really doubtful about the Python port being a free (as in freedom of speech) tool. There were lots of questions about redistribution rights, and “gaurantees” from Nokia about the availability of the Python API going forward. We tried to explain as much as we could that the Python S60 effort isn’t at all like Java support on handsets, and more like Linux support on PCs. Or even Python support on PCs. The open source ecosystem for any environment has fundamentally different influences than what exists on the commercial side, and there isn’t always a good direct mapping. The Python port is open source itself. It used to be a closed project based on open source, which is something I think hurt the effort quite a bit. For the first few releases there was no source available for the port of the Python interpreter. But now there is, and the effort can claim open source in all regards.

The first thing I showed off was using the bluetooth console to connect to the Python interpreter running on the phone. You can find instructions for how to do it on Linux, Mac, and Windows linked to from the Python on Series 60 wiki. A lot of the samples I showed off came from bits and pieces of that as well. These are all examples of things you can throw right into the bluetooth console as soon as you have Python installed and your PC connected, they “just work”:

• The graphical “hello world” for Python S60:

  #
  import appuifw
  appuifw.note(u'Hello SDForum!', 'info')
  

• Scanning for Bluetooth devices is done using some built in dialogs. When you scan for devices using the bt_discover() method you get the dialog you might recognize from any standard S60 app:

  #
  import socket
  addr,services=socket.bt_discover()
  

• Example of a slightly more complex UI interaction, a popup menu:

  #
  import appuifw
  opts = [u"C++", u"Java", u"Python", u"Scheme"]
  choice = appuifw.popup_menu(opts, u”Pick a language:”)
  if choice == 0 :
      appuifw.note(u”You must be joking”, “info”)
  
  if choice == 1 :
      appuifw.note(u”It really is everywhere”, “info”)
  
  if choice == 2 :
      appuifw.note(u”A nice comfy environment”, “info”)
  
  if choice == 3 :
      appuifw.note(u”Simple and elegant”, “info”)
  

• An example of using the camera to capture an image and save it to device memory, then use the content handler to display the image on the screen (yep, still all built in functionality):

  #
  import camera
  import e32
  filename=u'c:\\picture.jpg'
  image = camera.take_photo(size = (640,480), position = 1)
  image.save(filename)
  lock=e32.Ao_lock()
  content_handler = appuifw.Content_handler(lock.signal)
  content_handler.open(filename)
  lock.wait()
  

• Use the packaged Python networking libs to send the image from the previous sample via POST to a server somewhere out on the Internet (madgat.com in this sample, my server… obviously my server isn’t included in the Python distro, but if you have a server to post to you can use it instead):

  #
  import httplib, urllib
  f = open( filename, 'rb' )
  i = f.read()
  f.close()
  params = urllib.urlencode({'image' : i})
  headers = {"Content-type": "application/x-www-form-urlencoded", "Accept": "text/plain"}
  conn = httplib.HTTPConnection("www.madgat.com")
  conn.request("POST", "/ps60/take.php", params, headers)
  response = conn.getresponse()
  conn.close()
  print response.status
  

• Access to contacts:

  #
  import contacts
  ctact = contacts.open()
  ctact.find('rowehl')
  

• Access to the calendar, finding all entries or todo items associated with today:

  #
  import calendar
  import time
  cal = calendar.open()
  cal.daily_instances(time.time())
  

• That previous example will return you an array of items with id and datetime parameters. You can use the id to get the details for the entry (the __getitem__ method is what it’s called in the Python for S60 docs.. yes I know that’s the overloading endpoint for container emulation, so you can write cal.__getitem__(61) as simply cal.[61], but that doesn’t help someone searching the docs). You should use the id of an entry in your calendar in place of the 61 I use here:

  #
  entry=cal.__getitem__(61)
  entry.content
  entry.location
  

• And writing to the built in app data, which is managed with transactional requests. Do this if you don’t mind overwriting the calendar/todo entry, and then pop out of Python and you’ll see the item has been changed in the native app:

  #
  entry.begin()
  entry.content = u'Mike was here'
  entry.commit()
  

One of the samples I had wanted to show off was a script that pulls a sample from a Bluetooth GPS and displays a Yahoo map image to go along with it. It was a longer sample though, and we were inside so I knew getting a GPS lock would take forever. Plus, of course, it’s against the Yahoo terms of service. I figure terms of service aren’t like the DMCA though, so posession of a program that violates the terms of service does not constitute violation… I’m guessing. I could go back and read the TOS again and see if they say anything. But instead I think it would just be more interesting to post the Python script for Series60 that reads a sample from a bluetooth GPS unit and displays an associated Yahoo map image. Really unfortunate that Yahoo can’t allow folks to use their API with realtime data, cause that image tile interface rocks hard core.

Links (should be all you need to get started, and the wiki for samples to play with):

• http://opensource.nokia.com/projects/pythonfors60/
• http://sourceforge.net/projects/pys60
  
• http://www.postneo.com/postwiki/moin.cgi/PythonForSeries60