Blog updates

Sunday, 26 February 2012

Chromemarks Updated - 2012.02.26

Time for another quick update. As usual, the highlights in more detail:
  1. Fixed a bug where the app would state "the folder is not found" if you were creating or moving a bookmark in an empty folder. Was due to a mild logic bug and has been that way for about three months. With the help of some log files from Jordan and Denis, I've found and fixed the bug.
  2. Fixed a bug whereby a large number of encrypted bookmarks could not be decrypted. This was another "1mb Android limit" bug. So it only happened with a large amount of data - in the reporting case it was on the 2248th bookmark which was one too far. Have corrected this to process the data in several smaller chunks instead of one big chunk. Also made the app save any decrypted bookmarks as it goes through them so even if it fails again, at least something should be decrypted and saved. Thanks to Bjorn for the log files and for testing a beta release.
  3. Some routine maintenance - have updated the chrome protocols to the same as the currently stable Chrome - we're now at version 30.
  4. As spotted by another user - when creating a new bookmark, the name field was being pre-filled with a "New Bookmark" value. This would need to be deleted before you could insert/type the new name, which was a bit annoying. It's always been like that since the create bookmark screen arrived! Have removed the default text and now the box just shows a hint.
  5. Found the reason why some users with Honeycomb devices were seeing no integrated bookmarks. Turns out if you enable the native bookmark sync in Honeycomb, it adds some flags to the Browser database. It then uses those flags afterwards to determine what data to show. Unfortunately that filter means it will only ever show data synced by the native method - and not my app. Android won't let my app clear this data, so I've added in a message and popup suggesting the user clicks on the "clear data" option in the Browser application settings. Thanks to Kenneth for helping.
And an honourable mention - Google have again made some changes and this time they are affecting Chrome users directly. See for more details. They changed something on their server which affects the data being stored on Google's servers and it's returning empty folders, renamed bookmarks and/or duplicate bookmarks. Google are working on a fix from the server side which will probably restore data from a previous backup. Don't know how they will identify all the affected users, or what they will do if you've created bookmarks since...


Tuesday, 21 February 2012

Chromemarks Updated - 2012.02.22

A small update to the Full app only:

  1. Since a user may use the local bookmarks function and then disable it at a later date, after each sync the app would do a mini tidy-up. If local bookmarks were disabled, it would ensure there were no klingons and remove them just in case. But this was causing some errors for users who had uninstalled the stock browser, or frozen it. Fixed this with a bit of protection to see if the browser was actually there before trying to tidy-up or integrate. Sorry.
  2. A fix to the local bookmarks settings screen. Noticed a few automated errors. Looks like some people had multiple local browsers on their device and certain scenarios made the app think the selected one was number "-1" in the list. This obviously crashed each and every time. Fixed.
  3. A bug reported from a user with decrypting bookmarks - if you have over 2000 bookmarks then the initial decrypt may hit the android 1mb data limit and fail. Annoying the app wasn't even reporting an error back to the user. I've added an error message for now and will fix the underlying issue shortly.
And a whinge back to that annoying person who raised a 1 star comment on the Market about the Search Engines:
I will NEVER insert my own agenda of bookmarks or data into the app on YOUR device. 100% of the bookmarks, folders and search engines you see come from YOUR Chrome browser. If there is something in there that you don't like the look of, well - I'll be blatantly honest - YOU either bookmarked or visited the website.

Enough said.

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!