ORIGINALLY POSTED SEPTEMBER 9, 2010
There was an interesting forum post in the private webOS dev forums that I saw today talking about the Google Map app and how lousy it was (paraphrasing a bit- LOL). One of the biggest concerns, which I absolutely share, was around startup time. We were all wondering why it seems to take a lot longer to start than we think it should and why it seems to hang frequently, or sometimes times out saying no network connection is available when one clearly is.
If you aren’t aware, the webOS Google Map downloads code from Google’s servers at startup. Now, I haven’t dug into the code so I don’t know if it’s every time or what the logic is like if it fails, but one can kind of guess what it might be like. Specifically, what happens if the server can’t be reached for whatever reason? Do you think the code might fall through to a generic branch that says “network connectivity isn’t available” and not something more specific? I’d bet money it does. Whether that’s the case or not, it sure does seems like it’s doing a “dumb” load from the server every single time, based on my own experience, as well as what others in that forum thread were seeing.
To be clear, having portions of your app’s code “in the cloud”, even when we’re talking about a locally-running app, is a really nice idea. For one thing, you can ensure the user is running the latest version of your code, so they automatically get all the bug fixes and nice new features you build without an explicit update (which we’ve seen a couple of times now with the Map app). As long as it’s not disruptive, I think users like to be surprised with shiny new toys to play with all of a sudden 🙂 You could also use it as a copy protection scheme, assuming you built a proper infrastructure around it (it’s likely not going to be air-tight no matter what you do, but still). You can also use it to collect usage statistics (I’m not a huge fan of such things frankly, but I’m not going to go nuts about it or anything).
But, being a good idea doesn’t mean there aren’t implications to it, as I believe the Map app demonstrates. This all got me thinking about how I would implement something like that. The pattern seems fairly obvious to me and I believe would avoid the startup issues seen with the Map app… although, admittedly I’m assuming I know what the startup delays are caused by with the Map app, and I frankly could be wrong… without digging into the code I’m only guessing… but be that as it may, I think this is probably the right way to do something like this regardless, so I thought I’d share..
So, your app is starting up. There’s obviously some amount of “scaffolding” code, if you will, that’s on the device. As part of this code, you would load a much larger chunk of code from an on-device database and eval() it. Your app is then fully in memory and you can go off and begin doing whatever it is that the app does.
At the same time, in the background, you kick off a call to your server to check for a new version of the code. If one is found you update what’s in the database with the new version automatically and without the user even knowing it. At this point, the user is going to get the new version at the next application run automatically, good to go. You could also optionally pop an alert to the user asking if they want to restart immediately to get the changes.
If any problems occur, say your server is overloaded or the network is down somewhere, your user isn’t impacted by the failed update attempt. They aren’t aware of the problem and they aren’t slowed down at all.
Now, what code you’re actually downloading could get interesting. I’m not sure if you could have new webOS scenes for example… although, maybe. Would be an interesting thing to try (assistants probably wouldn’t be much trouble but how you’d deal with the view markup I’m not sure). But what you certainly can have is core application logic, stuff that, by and large, probably isn’t webOS-specific anyway. This is likely to be the kind of stuff you’d want to update frequently anyway, and that’s the real demarcation point. If you’re adding a whole new scene it probably makes sense that there’s a regular application update involved, but tweaking existing functionality or extending functionality, that’s ripe for remote download.
The benefit here, by storing the code in the database, is twofold. First, you don’t impact application startup much. I’d say it’s likely to always be faster reading from the local DB and eval()’ing than it is to get the code from a remote server, and in some cases, depending on network conditions, it could be a lot faster. It’s probably not going to be much slower than a regular application startup with the usual JS loads and evaluations and such that happen as a part of any application load either. Second, you don’t require an Internet connection just to start your app. If no connection is available the app can still start and run normally (assuming it doesn’t require a connection to run of course). Since the update is a background task anyway there’s no impact either to startup or to the user- they’re none the wiser!
I suspect the Google Map app isn’t doing anything like this. If it is then it’s absolutely baffling to me why the startup is so lousy and seems brittle. This is the way I’d implement such a capability for sure. It seems logical and frankly pretty simple while providing all the benefits of remotely-loaded code.