Simon Rumble’s blog

I bought the Beyonwiz DP-Lite PVR a few weeks ago so I thought I'd write up my impressions of it.  It's important to understand that I bought this after having used MythTV mostly happily for about 4 years.  MythTV's problem is that it relies on PC hardware and digital TV tuner cards, and so I've had various hardware issues over the years.  I've also had lots of problems during upgrades.  My hope here was that a dedicated hardware PVR would reduce some of these shortcomings.  So far it's reduced those, but at some costs.

What's with the live TV orientation?

Over the last few months I've had a number of hardware problems with my MythTV server.  The machine itself locked up fairly regularly, and there's been big problems with the driver for the dual-tuner card that had previously worked flawlessly.  I finally got the shits with it and bought a hardware PVR on Saturday, the Beyonwiz DP-Lite.

I've held off buying an off-the-shelf PVR because they've tended to be pretty poor.  The UI of the Beyonwiz is quite primitive, and very very confusing in parts, but it's good enough.  I wouldn't recommend it for my parents though.

You'll note I didn't buy my employer's PVR product. It has one significant limitation for me: while it has two tuners, only one can be used to schedule recordings. The other is reserved for live TV viewing, which to me is a huge lack of insight into the way you use a PVR.  Hopefully that will get fixed in one of the coming software updates.  It certainly has a vastly better UI than the Beyonwiz and the movies service is quite attractive.

There's a few things I miss from MythTV beyond the UI.  The browser scheduling interface is a lot more flexible than IceTV + Beyonwiz.  With MythTV you can ask it to record a single episode of a programme each week, which means it can shuffle the recording to a repeat in a non-peak time if there's a conflict for a tuner.  This device doesn't do that at all.  I also miss the automatic ad skipping, but that's less of an issue because we only really watch ABC and SBS.

Browser impose the Same origin policy on JavaScript running inside a web page. It means that your code cannot access a resource through XMLHttpRequest that belongs on another server, even when it's in the same domain. This is a good thing, and the way to get around it in production environments is to use some kind of proxy if you're trying to channel a trusted resource. I've done this on a couple of occasions so that my apps could access a web service that is physically located elsewhere.

When developing your code, however, this can be a real pain in the butt. You might want to access the production web service, or just want to play around and prove that what you want to do is possible. I've recently discovered a much easier solution than the others I've used before.

This little snippet of JavaScript causes a popup in the browser, but then allows you to make an XMLHttpRequest to any domain you like. Very handy for testing!

// This sneaky bit tries to disable the Same Origin Policy
if (navigator.userAgent.indexOf("Firefox") != -1) {
   try {
       netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
       } 
       catch (e) {
             alert("Permission UniversalBrowserRead denied -- not running Mozilla?");
             }
}

Tip of the hat to miek on this Stack Overflow question.

After my last post an anonymous email arrived with an even better mechanism to de-obfuscate Omniture's code, including the line-noise base s_code.

I currently have a real need to be able to understand how Omniture works for a particular implementation, and have requested a commented version. Apparently it's kept very tight and I might be able to "see" parts of it. Ridiculous when you can rather easily do this. I'll now probably blow half a day working out what all the single letter variables are.

Copy and paste the following into Firebug's console and run it.

//code to unobfuscate the s_code
var str = '<hr><pre>';
var strFunction;
var strFunctionName;
var i;
for(i in s) {
       x = s[i];
       if (typeof(x) == 'function')    {
               strFunctionName = i.toString();
               strFunction = x.toString();
               strFunction = strFunction.replace(/^function( ?anonymous)?/, 's_object_name.' + strFunctionName + ' = function');
               str += strFunction + '\r\n \r\n   // ------- ------- ------- ------- ------- -------  \r\n\r\n';
       }
}
document.write(str)

Thanks to our anonymous tipster!

My current job involves working extensively with Omniture products. The company has an annoying habit of secrecy, with documentation only available on request for many aspects of their products.

They also attempt to obfuscate their JavaScript, despite the fact that a determined viewer should be able to work it out eventually. I'm told this is so that people aren't tempted to play with the code. The obvious methods of deobfuscation are pretty tedious, and because Omniture don't use standard (minify et al) methods of obfuscation so it seems a little more difficult. Fortunately I lucked onto a better approach.

You'll need Firebug, and if you don't have that already you should anyway. Go to a page that already has the Omniture "plugin" (function) you want. Open the Firebug console and run alert(s.functionNameYouWant) and run it. You'll be shown a nicely-formatted anonymous function, which will be much easier to read than the line noise you'll see in the actual s_code.js file.

In my case I'm after Cross-Visit Participation, and that's used on the Omniture site itself (though an older version than the latest available from Omniture which has a very useful additional feature).

Update on 22nd March 2010

I discovered, while trying to reverse-engineer the s.Media() functions, that some plugins are loaded as "Modules" which presents a further layer to get through. But it's still pretty simple. Using this handy snippet you can decode the objects. So, for example, to get readable source for s.Media, do this in Firebug:

function concatObject(obj) {
  str='';
  for(prop in obj)
  {
    str+=prop + " value :"+ obj[prop]+"\n";
  }
  return(str);
}
alert(concatObject(s.Media));

Another update

I received a better way to do this, detailed in this post.

Work is providing me a mobile, so I went to cancel my phone with Exetel. Unfortunately this is the UI you see. So first of all, you can helpfully cancel it in the past. But then the button is labelled "Cancel". So does that means clicking it will cancel my service, or cancel the request to disconnect?

The resulting page is even more confusing. Does that mean my "Cancel" was successful? Or do I now need to "Submit" to make it happen? Terribly confused.

So I've been using the Google Android phone for about six months now, and it's about time I reflected on how it's gone. Here's a bit of a rambling review.

The hardware

The G1 hardware is pretty limited. There's not enough RAM, and the default Android way of storing apps on the phone rather than on the removable flash storage means you run out of space pretty quickly. The latter is fixed by using a custom image like Cyanogen, which is awesome.

The buttons on the phone are kinda dumb. There's green and red buttons for call management, just like most phones. Then there's a home and a "back" button, which are kinda superfluous as they could easily be replaced by some sort of touch gesture. The "Menu" is kind of a universal interupt button, and I suppose might be useful. And the trackball is completely useless yet seems to be mandatory for all designs. I never use it. On the sides are the camera and volume buttons, which I suppose are handy.

The buttons that would be really useful are missing. I'd love a pause/play button for when I'm using the thing to play music.

The G1 has a built-in keyboard. This is great, but has been dropped on later releases. Given a decent touchscreen interface, I think I could live without it. Not convinced that the on-screen keyboard is good enough, but it will make the device smaller, lighter and sexier. Though the keyboard rocks for answering emails or using ssh.

Multistasking: good and bad

Multitasking, the key difference between Android and the iPhone, is a double edged sword. It means you can run cool third-party apps that need to run all the time, like apps that show your calendar and weather forecast on the home screen. It also means that crap stays running all the time, meaning performance can be glacial if you've got something hogging the CPU in the background, and memory fills up very quickly.

Some allowance for the slowdown of background apps could be incorporated into the OS. It'd be nice to have apps not slow down core phone functions. I'd even be willing to completely pause background apps while something important is going on, like an incoming phone call. I kid you not, I've missed incoming calls because the phone's CPU has been busy on some other crap. Many is the time I've given up taking a photo because after pressing the camera button, whatever I wanted to snap has long finished before the camera app is up and ready to take a photo.

Shitty memory manglement

Android takes the same "automatic" approach to memory management as Symbian: if it runs out of memory, it kills something random that's running in the background to make some space. Apps tend to run in the background unless you explicitly exit, or use a power user tool to kill the process. That means while you might have something cool running in the background, it could randomly and without notice be killed at any time because you opened something else that wants more memory. The usual excuse for this kind of thing is you don't want to make users of consumer devices think about things like memory. Try telling that to some angry consumer whose fancy alarm clock app got killed to make space for another app meaning the user overslept and was late for work! How much sense does it make to kill the music player when I'm listening to music just to make space for something else? I'd much rather have to explicitly manage the memory and be asked what should get killed.

None of this is helped by the miserly allowance of RAM on the G1, 192MB. The Nexus One's 512MB should make this much more useful, though it's going to make running a G1 or any of the first generation Android phones somewhat suckier, given developers will now be targetting the new, faster, roomier Nexus One.

How about event-driven OS callbacks?

I think many of the problems with multitasking could be solved by introducing some OS-level event-driven triggers. What I'm thinking is instead of apps having to hang around in memory and periodically using the CPU, they could register with an OS service that they want to be woken on specific events: an SMS is received, the phone's power source changes, it's a specific time, the phone's location gets within x metres of a coordinate. That way you wouldn't need, for example, to keep your alarm clock app in memory all the time, wasting RAM and CPU cycles. The app would register the events its interested in, then explicitly exit.

No idea how practical this idea would be once implemented, and whether the overhead of loading up the app to handle the event would kill performance, but I think something different to the always-running-but-could-be-killed-any-time approach needs to be looked into.

Integrated apps

If you've taken a good slug of the GoogleJuice Kool Aid and moved your whole life into the cloud, Android is a really easy integration. I've got my email, calendar and instant messaging all in my Google Apps cloud, and have done for a while now. Starting with Android was as simple as logging in and waiting for it to all sync up. Brilliant. Everything Just Works™.

The apps are good too. Email is just like you'd expect, all your contacts are right there where you expect. A live calendar is life-changing, especially if you sync your work calendars into the cloud too.

One area that could do with some improvement is the way the GTalk app works. When I'm sitting at my desk and someone opens a chat session with me, I get three notifications that this has happened: inside my current browser Gmail session, the desktop GTalk app, and on my phone. Surely the server can work out which one I use to handle the session and close the others for me? Instead I have to go in and close those sessions myself, which is kinda clunky.

It'd also be nice if the instant messaging apps were a bit smarter. Let's say I want to contact someone, and the contact record shows the person has GTalk and a mobile phone. Surely I shouldn't have to work out which one to use, it can instead use the user's presence to work it out. If the remote user is on an Android phone, it could be really clever about it and switch to SMS if that user isn't online. All these contacts should show up in the same interface, regardless of underlying mechanism.

My favourite apps

By far the finest app so far is SlideScreen, which replaces the default home screen. At the top are your "private" communications: phone calls, SMS, email, calendar. Below are your "public" comms: Google Reader, Twitter. In the middle you get some status info: date, time, network connection, current weather. You can slide the middle part up and down to give more space to one area at the expense of the other. You "throw" an item to the right to mark it as read and get rid of it.

It's a beautifully-designed app, and nearly completely suits my way of working. Unfortunately it's just too heavy for the poor little G1. It takes up pretty much the whole of the RAM, so if you run another app it gets killed, and you can't really run it and another app. Should be great on the Nexus One though!

Ever since I lived in London, I've read the Guardian as my newspaper and news source of choice. I subscribed to the Guardian Weekly until recently. Part of the reason I stopped subscribing is this app, which downloads the whole paper overnight and presents it in an awesome UI that doesn't require network access. If you're writing a newspaper app, you should copy the design of this app.

Conclusion

The Android OS is excellent and improving all the time. Its openness means you can swap out much of the bits you don't like, which contasts well with Apple and Nokia's smartphone efforts, where you're stuck doing things the way the vendor tells you.

The app marketplace started off pretty poor, with lots of not very good apps, but is improving fast. People point out the high quality of the iPhone apps, but it's worth also pointing out that a popular app there can easily pay for multiple full-time developers. Android isn't there yet, but the marketplace is expanding incredibly fast. Some stand out apps are appearing (like SlideScreen) and you can expect more with the hundreds of Android handsets that will be available by the end of this year.

I'm looking forward to upgrading to the Nexus One, especially since I dropped the G1 and now have a lovely big crack across the LCD. Just have to keep working on the boss to release the funding. It'd be really good if a version appeared that handles the 850MHz UMTS band, since I'll probably be scoring a work SIM soon and Telstra's network uses this slightly-unusual frequency range.

Good

• Multitasking means you can have awesome apps running all the time. The iPhone just can't do this unless Apple makes the app.
• Open platform makes for some very cool apps: custom home screens.
• Integration with Google apps is very slick.
• The app marketplace is awesome, and growing fast. Apps are getting slicker pretty quickly.

Bad

• Hardware on the G1 is very limited. Nexus One appears to solve this.
• Memory management is "automatic" which means "dumb and confusing".
• Multitasking means a background app can make the device glacially slow.
• Stock music app is awful.
• Buttons are kind of pointless. Trackball even more so.
• Integrated messaging is needed.
• Connectivity lost when you switch from 802.11 to GSM/3G.