Blog updates

Sunday 19 February 2012

Chromemarks Updated - 2012.02.19

Time for another update. As usual the highlights in detail:
  1. Google broke something. This was affecting the way my app was determining parent/child relationships between folders. It was making some folders appear multiple times and other folders "disappear". It looks like Google have clearly changed the way the sync server responds in the last two weeks. I've raised a chrome bug and attached evidence, but it's clear there is a change and it's deviating from what the documentation states it should be doing. At the least, I've requested Google update their documentation, but that'll never happen either. I've fixed this in the app, but it warranted a change to the database as the data being received by each sync wasn't being added to the database correctly in the first place. As such, the app will remove any bookmarks/folders already downloaded and you'll need to re-download them. Sorry, not my fault!
  2. Google broke something else. For the full app, some users were getting a 500 error when using the "copy local bookmarks to a new folder in chrome" option. Again, Google changed some of the validation on their server. The documentation is ambiguous at best and I had to make several guesses at various fields before I could find out which one they've actually changed. So this should be fixed now.
  3. Google broke another thing. They have started to mark the decryption keys differently to previously. Ironically, Google used to do it this way. Then they changed. I raised a Chrome bug and pointed out the difference. They've just changed it back again. Sigh. I've tweaked my app so it can now handle both methods.
  4. A huge rewrite of all the "sync local bookmarks" functionality. It's been long overdue. This gives me better seperation between the syncing and the integration parts of the app. It also gives me a more flexible and generic way to perform ad-hoc functionality to bookmarks both before and/or after a sync. Obviously one usage is integration to a stock browser or any other browser. Unfortunately there *still* isn't a single browser app on the Market that is open and will allow me to touch their bookmarks. A couple of small bugs fixed along the way.
  5. A tentative first stab at integrating bookmarks and folders into the Honeycomb and ICS stock browsers. It's been a tricky one this. Google will only release partial source code for the required functionality for ICS devices. There is *nothing* for Honeycomb. I've had to try and work back through commit logs and heavily debug the browser on the Honeycomb emulator (which isn't debuggable by default!) to try and guess what commit of code is running for individual classes in Honeycomb. But I've got something that integrates now for 3.x and 4.x devices. It's a bit flaky around the edges (for example bookmark widgets are a bit wacky if viewing a folder that is integrated and a sync happens). But it seems to work okay on my personal transformer running Honeycomb, so good enough for a release, methinks!
  6. Fixed an annoyance with the androidpit authenticator. At least I hope I have. Since several of the official emulators don't have built in LVL functinality, this means I could never actually test the full app on any device >= gingerbread without deliberately knobbling the app. And then what is the point of the test? So I've been using the andoridpit LVL for a while on most of my emulators. But every now and then it keeps failing with an unknown error. This annoyed me so I spent a day debugging further. Turns out the sample androidpit code has a weak spot and assumes that their authenticator responds immediately. In reality, today's devices have a mild delay between starting an app and it being ready to reply. So I added a small delay in before it asks for authentication and I haven't seen an error since.
  7. The usual small bug fixes in various places throughout the app.
That's it for now. For the unlucky 99% of you who don't have access to ICS and Chrome4Android, I'm still here and will be for a while!

One item possibly on the horizon. I spotted this in a recent chrome bug:
In the next few months, we'll be migrating to a new encryption solution that is not reliant on the user's google account passphrase
[ The mention of passphrase above is more accurately referring to the google account password, given the context of the original bug report. ]

Not sure what this means and what it will break. We'll have to wait and see!

No comments:

Post a Comment