Sunday, March 6, 2011

2.0.4 Landing (For Reals This Time)

Just wanted to let anyone who may be following the blog that android2cloud version 2.0.4 just landed in the Chrome Web Store. This is identical to the extension that was in public beta for the last week or so. It should fix any issues you have with links reopening. To clarify that:
  • You should uninstall version 2.0.3 or have it auto-update. You should never run two installations of the Chrome extension at the same time. Ever. I can't even begin to predict how that would affect performance.
  • You should uninstall the public beta version (which will not update automatically) and install the release version. You should never run two installations of the Chrome extension at the same time. Ever. You should  also always install the extension from the Web Store, if possible, because that will keep you up to date with new releases automatically.
  • You should see the links pop open one last time when you install version 2.0.4. I'm sorry. If I could prevent that, I would. After the first time 2.0.4 sees them, though, they should never open again.
For those that care about the technical details, I offer a post-mortem of the unfortunate situation.

This situation was created entirely from my own folly. For some unknown reason, Chrome disliked the mechanism I had worked out for android2cloud originally, which was storing the ID of the last link that Chrome received, then sending that to the server when it connected to have the server send back all the links received since that ID. In theory, it should have worked. In practice, it didn't. And I still have no idea why. I thought it would be easier to simply modify the database schema to hold a "received" field for each link. Now, when Chrome received links, it would phone home to the server and say "yup, got it!" at which point, the server would mark it as read in the database. So every time Chrome connected to the server, it asked the server for the links that hadn't been marked as read in the database.

Which should work, in theory, right? Right.

Except I was foolish, and didn't think things through fully. I assumed that simply turning around and giving the server back the same data we received would be the easiest way to go about things-- minimise the requests to the server, prevent parsing errors from mucking up the "mark as read" transaction, that sort of thing. What I didn't take into account was that, because it was an OAuth request, all the data got stored in the URL. Which is more than mildly annoying-- it actually broke the "mark as read" transaction by making the URL too long if you had a bunch of links. So the server never got the message to mark the links as read, and dutifully sent them back to Chrome every time Chrome connected.

The solution I came up with was simply parsing out the IDs of the links received, and sending those back to the server. That truncated the request nicely and, therefore, the server got the message that the links were received. This solution is not bulletproof, obviously, but it works as a quick patch until I can get the much more thought out 2.1 out the door.

Sorry for the issues. I'll try to do less foolish things in the future.

No comments:

Post a Comment