ChromeMarks updated - 2011.12.06

Another ChromeMarks update.

The major change is the addition of synced Search Engines:

If you enable these for syncing in Chrome, they will now be available in the app and you can click on them and use them as quick search for the website in question.

In a later release, I'll try and add them to the Android Search Widget so you can do a similar thing to the chrome omni-box and hopefully the chosen search engine will be an option in the results list along with matching bookmarks/folders.

NOTE: The search engines will only be downloaded from a fresh sync - if you already have bookmarks downloaded, you need to reset the app. This is because it's a bit tricky to download search engines from the beginning and merge them with other existing data. Chromesync returns lots of excess data when you sync something from the start and I don't want to write a huge amount of extra reconciling.

Wherever the app used to show bookmarks or folders, it was in a statement that said "IF bookmark then do this else assume folder and do this". That wouldn't work now with a third option - search engines. Also, I didn't want to contaminate the Lite app with mentions of the search engine in code as that increases my testing efforts. So I've had to do another major rewrite to put this sort of logic into a handler for each type of "thing" the app will show. This gives future benefits as now it would be easier to (i.e.) add Passwords or Synced tabs, etc. This means that potentially only click or long click on any item might function differently to before - please let me know if anything is different!

Some other bugs squashed:

1. The last release included some severe changes to the handlers to separate some of the historic intermingling of ui, database and code. One impact of this is that at the end of a sync, the controlling code stops the processing thread. Unfortunately, there may still be some messages in the queue that haven't been processed yet. This wasn't an issue before as everything was one long chunk of code so ran in the correct order. But now, some of the final messages appear to be missed on occasion. If you have a fast phone, this means the controller finishes very quickly and the message to prompt for the credentials isn't being received in time. So some fixes to force the controller to wait for all the messages to be processed before the controller ends.
2. The new backups feature has a couple of reported bugs. They all stem from the android 1mb limit. I've made some tweaks which should improve it and allow the backup to retrieve > 1mb of data.
3. As request by one of my regular users, I've changed the format of the filename for the backups to something closer to CCYY_MM_DD_HH_MM_SS

Still lots on the agenda for future releases:

• Better search widget integration with search engines
• Scheduler for backups.
• Honeycomb integration
• More data types for syncing - passwords?
• More ui polish - split screen for tablets?

That's it for now - enjoy!

Chromemarks Updated - 2011.11.29

Time for another ChromeMarks update.

1. Pro users can now export/backup all their bookmarks to a file. This file is fully Chrome compatible. So if you accidentally deleted, say, every bookmark in Chrome and you haven't synced ChromeMarks then help is now at hand! Simply export from ChromeMarks, copy the file to your PC and re-import it and your bookmarks will be resurrected. Of course, folders and icons are part of the export as well. At the moment, you can perform the backup via the application menu. But I intend to beef this up in a future release by adding a "scheduler" so you can specify to backup before and/or after each sync, to possibly change the format, limit the number of backups, etc, etc. Note, the exported file is saved to the sdacrd and is not encrypted.
2. Encryption was new with the last release, so a couple of bugfixes here. Firstly, Google allows you to change your password/phrase at any time. Chrome is meant to re-encrypt *everything* then to the new password/phrase. But the odd bug in Chrome means it sometimes misses some things out. Luckily, it does sync the "keys" which you can use to decrypt both old and new stuff. ChromeMarks had a bug in it whereby it would only ever use the latest key, so stuff that was older was left unencrypted. There was also a condition caused by the randomness of data that meant if it went from new keys to old keys to new keys then an error was thrown and nothing was decrypted. I've fixed both of these.
3. Similarly, when you made any change to a folder (add, rename) then the app was not re-encrypting it. Ooops. Fixed that.
4. Decryption was extended further through the app - if you were creating/amending something and Google sent back a change to the encryption, the app can now handle it instead of ignoring it.
5. Several tweaks to the local bookmarks functionality. Thanks to Joe and Tom for providing debug logs. A recent change from Google is that the hidden tag I use to identify the local sync folder has to be unique in the users' account - which includes previously deleted ones. So if ChromeMarks created the local sync folder, and you deleted it, Google would not allow you to recreate it again. I've fixed that now with a random number on the end. And submitted a crbug patch to Google to correct their test server accordingly.. :-)
6. Staying with the local syncing, if you added/amended a bookmark or folder, the calculations for where to position the resultant object (which should the same place it it's being amended!) were not always right. Fixed. Or at least improved.
7. The fixes put in place last time for Honeycomb appear to have greatly improved the app for users (or at least, the number of bugs has dropped down to zero in the bits that I fixed). Added the same code to more parts of the app such as the create/amend popup.
8. A Huge refactoring of the heart of the app - the syncing engine. The code had grown up over time as was very bloaty - it had all the logic to communicate with Google as well as logic to display errors on screen and to handle various responses. I had to duplicate this logic everywhere the app needed syncing - so another copy in the automated sync, in the create/amend popup and also in the lite app. This meant each time I changed something, I had to ensure I did it right four times. I've created some common classes now and these reduce the complexity greatly. I've also seperated out the displaying logic from the engine to make it easier to maintain. Although I've done a lot of testing - I can't say for sure that the core of the while syncing process is working exactly the same as before!
9. Tested a few more browser apps on the Android Market to see if the full app can integrate with them. Unfortunately they all have private databases and will not allow another app to send them data. Sigh.
10. The usual sprinkling of bugs fixes throughout the app, but too numerous or trivial to list in any detail.
11. Updated the About popup to include info about open source licenses and the applications privacy policy. This was prompted by a snotty and annoying comment on the Market stating "now they have all my bookmarks" referring to me. Let me make this clear - YOUR BOOKMARKS ARE YOUR OWN DATA. I DO NOT AND WILL NEVER PASS YOUR BOOKMARKS THROUGH A THIRD PARTY. Feel free to use ngrep on your android to sniff the network traffic and you'll notice that it goes to exactly the same url that chrome does for syncing. The only additional bit is my app also uses Google analytics for usage monitoring, but you can see the full url being sent and can see there are no bookmarks or personally identifyable data on them. Why do some people think everyone is evil?

This was also the first release where I performed the overwhelming majority of my testing against the test chromiumsync server that is part of the Chrome codebase. It's a reasonably efficient piece of work, but it does respond a little differently in places. So I've raised two crbugs with patches for the chrome developers to upgrade the code accordingly. Previously I tried to create my own little app, but it was hard to get all the responses right. I'm thinking that my own little app might morph into a test runner to allow me to unit test the app properly.

And a quick touch on what's next for this app.

• A first time tutorial. Basically something that will give you maybe five small pages of info that you can swipe/click through that will give you some hints/tips on the app for new users.
• Search engines synced. I'd like to try to sync back the search engines from Chrome and make them accessible in the app. If that works well, then maybe some other bits could be synced - passwords is an option, but remember that the Android browser won't let another app send in an id/password to auto fill. So Passwords can never be integrated properly in the Stock Browser by a third party app.
• More improvements to the new backup facility - as detailed above, a scheduler function.
• Honeycomb integration. Google have released *some* of the source code. Not all of the bits I need, though. And they refuse to annote which bits cam from Honeycomb - they seem to be treating it like the ugly duckling and pretending it never happened. So it's hard to tell what code is running on Honeycomb and which bits are probably on Gingerbread or already on ICS. If anyone has root access on their Honeycomb tab *and* they can get partial native code syncing to work, then let me know! I need the native syncing to be functioning partially as the Browser changes it's database and I can't get anything to work in the emulator so I'm still flying blind.
• Better testing. I spend more and more of my time retesting the app to make sure things aren't broken. I need to try to perform some automated and re-testable unit tests. Android does allow some unit test functionality, but it's a bit clunky and the interaction with an external sync server further complicates matters since it keeps returning randomly generated ids. Grrr.

That's it for now. Enjoy!

ChromeMarks updated - 2011.11.13

A long overdue release of ChromeMarks today. As normal, the highlights:

1. The app can now handle Chrome encrypted bookmarks. This was originally  expected to be a pro only feature for some time next year. But recent releases of Chrome have started enabling encrypted bookmarks by default, so I had to accelerate the plans. There were a large number of challenges to implement this (see previous blog). And before the inevitable 1-star review and complaints appear on the Market - you need to enter your account password to decrypt the bookmarks. There is no way around this - and when you ticked the option to encrypt your bookmarks in Chrome when setting up sync, it clearly states "your account password will be used to encrypt your data". The password/passphrase is not stored on the device. It is encrypted to create a hash in exactly the same way that Chrome does.

2. Upgraded the database to the same as the current stable release of Chrome. Unfortunately this does mean you will need to re-download all your bookmarks again. Sorry!

3. PRO APP. Someone involved with the chromesync service contacted me and mentioned that some of the icons being created by this app were "larger" than expected and the sync service would soon stop accepting them. Since icons are normally small in size, something that was >2kb could only come from one of the external icon providers that the app uses. So a mild fix to ensure the app doesn't sync something that big again. Plus, this is the first time some acknowledgement of this app from Google!

4. PRO APP. For users integrating their bookmarks, some may have been experiencing "corrupt database" errors. Some of these were due to a hard coded limit of 1mb in Android for the amount of data it could retrieve. If you had a lot of bookmarks and most of them have icons then you may have hit this limit and android wouldn't go any further and return a data corruption error. I've tweaked things to no longer retrieve the icons themselves (since they are the majority of the data) and retrieve the icons seperately when need be. This may make a "sync local bookmarks" slightly slower if you have a lot of icons - but it should be more reliable.

5. Added a new menu entry to "contact developer". This allows you to goto my Twitter page (@chromemarks) or send me an email. The email option will also attach a zip file with some info about the device you are using such as language, screen size, orientation, etc. Nothing personally identifiable.

6. The app now works on x86 devices, and also devices with an ethernet connection. I'm not sure if there are many such devices out there - but I'm using x86 android in a virtual machine for a lot of my testing now as it's sooooooo much faster than Google's android emulator that it made sense to upgrade the compatibility.

7. Partial Russian translation. Tons of thanks to Kirill Simonov and Evgeny for all the help!

8. Partial Finnish translation. Tons of thanks to Patrik Selin for all the help!

9. Remember - if you want to help with the translations from one word to several phrases, just drop me a line!

10. Some tweaks for Honeycomb users. This may or may not fix the crashes you keep getting when restarting the app. But without the Honeycomb source code, I can't tell for sure what the bug is/was or how to correctly fix it. Complain to Google!

Some screenshots for the new release can be found in the previous blog posting.

ChromeMarks - Progress update

Hi all.

Thought it was time for a progress update since its been a while since the last release of the app.

The main piece of functionality I've been working on is decryption/encryption. Originally I wasn't going to do this - I thought this was an additional feature that users would have to explicitly enable in Chrome and they could easily disable it in Chrome as well. At best, this would be a potential pro feature only as well. But things have changed over the last few months.

Firstly, the encryption option ("Encrypt all synced data") has been on the dev channel for a while, but recently was released to the stable channel. This meant there was now a much bigger chance of users getting encrypted bookmarks. Indeed, when setting up sync, you can imagine a user reading "encrypt all synced data" and thinking that isn't a bad idea, why not?

Unfortunately Google knows the version of my app can't handle encryption, so they've been treating this in one of two ways. If you already have bookmarks in ChromeMarks, Google would simply not send you any updates. At. All. If you are syncing ChromeMarks from the beginning (i.e. after a reset/reinstall) then Google took a different tack and decided to throw an obscure "database id" error:

I raised a chrome bug and they confirmed this was due to encrypted bookmarks and the only solution was to disable encryption of the bookmarks, or to upgrade the app fullstop.

Add to that, a growing number of users have contacted me with encrypted bookmarks that they are sure they never enabled. Indeed some users have only ever used the stable release so not even had access to the encryption functionality. For those using dev/canary/nightly releases, I suspect a release a while ago probably had a bug in it that enabled encryption by default - you never even knew it happened. But once enabled, it was done and since users weren't aware, they would complain my app was broken since it couldn't possibly be their bookmarks... Of course all the mails start with the phrase "my bookmarks sync fine between my home Chrome pc and my work pc, so it must be your app and nothing I've done".

A handful of users have also contacted me saying they just can't disable the encryption fullstop. In the Chrome "customise sync" box, the options to disable it (see screenshot above) are just not user editable. I don't know why - it may be something to do with the age of the users account and maybe you can't disable the encryption on the fly? They can disable it by deleting the Chrome sync data from the dashboard and re-enabling sync, but that's a long winded thing to explain to a user especially when they don't think they have done anything wrong.

In the last few weeks, Google have changed they responses they return and now, if you have encrypted bookmarks, you get a nasty server error returned (see below). Google knows to return this as the app sends its version number with the request and Google knows this version can't handle encrypted bookmarks. 

Unfortunately if I add in code to detect encrypted bookmarks then Google will detect that and will then assume the app can handle encryption and will no longer send the errors! Grrr!

So I've started to implement decryption into the app by default. Several challenges along the way, though, and I thought I'd explain some of them here to detail some of the trickiness and the reason for the long pause between releases:

1. Chrome is written in c and Android isn't. To work out how to implement this, I had to understand the intricacies of the Chrome code, find the bits that do the encryption, decryption and work out how to do the same in Android. Android is in Java. Which isn't the same as c! So I basically had to write a line by line match for the existing c code into a different language which worked a completely different way and had different dependencies and expectations!

2. I tried in Java first, but struggled to work out how to do basic decryption. I found some Java code on the web and took some of the basic unit tests in chrome to test against, but it never worked. After several days pulling my hair out, I found some obscure documentation on the web that explained some of the Java decryption classes are at bit level not byte level. After a bit of division by 8, suddenly one of the Chrome test packs passed!

3. I spent another week writing more Java to keep testing it and adding in more functionality to match Chrome, including code to decode the keys that Chrome stores in the sync database that are the key to decrypting your bookmarks. This started working well, so when I was confident I'd got it all good, decided to stick some of it in the app and test drive it.

4. It failed immediately when run on Android. I discovered that the security classes in Android's Java have been crippled at birth. Basically several years ago, the US government decided they didn't want the free Java code to include the best encryption code, also for free. With the normal panic over terrorism, they wanted to restrict many counties of the world to only have access to the weak encryption in java and save all the strong stuff for USA and the countries it trusts. Android has a bit of an old version of Java in it and Android is also available over the world. So it lacks the tough stuff - the stuff Chrome uses and requires by default. Grrrr.

5. This basically meant all the Java stuff I had done tested locally was effectively worthless as it would not run in Android. Of course nowadays, the restrictions in Java have been lifted and there are other libraries you can also plugin to do the job instead. But I can't upgrade the version of Java on your device. And I couldn't use the other libraries as they annoyingly have to have files copied into your Java installation and again that isn't possible on Android.

6. So I went back to Chrome and tried to see if I could compile some of the Chrome code as native code and see if that would work instead. But after another few days playing, it became obvious that I'd need a significant amount of the Chrome code base to get anywhere, and I'm definitely nowhere near a reasonable c coder to attempt that! Plus this was also a few weeks before they started actually checking in the initial code to the Chrome code base that might bring Android compatibility (note to readers, don't get excited...its a long way off before we will a nightly release of Chrome that runs natively on Android). But like the chrome devs, I still can't compile a working version for Android.

7. So instead I tried to see if I could compile some of the open source c libraries instead such as nss or openssl. Although I could find some posts out there from people who could compile it for android, I just couldn't get the damn thing to compile under cygwin. I tried ubuntu but got almost the same problems. In the end I went back to Java and persisted and managed to find a website that listed an alternative implementation of the missing encryption algorithm and found a way to simply invoke it manually (read: hook/crook/square peg/round hole) instead of via the default Java security classes - this avoided the need to install it on the device. Sorted.

8. Then started plugging it into Android. However Android doesn't have the operating system crypt classes that Windows and Macs have by default (or linux that would actually compile and work), so encryption on Android is increeeeeeeeeeedibly slow. I haven't had enough time to see if I can work out by how much...!

9. Then I had to find a way around what is sure to be the biggest gripe. Chrome uses your actual account password to encrypt and decrypt the bookmarks. Without your password, it ain't possible. If the app asks for your password, there will be uproar from people whingeing "why does this app need my password, it will have access to my Google checkout and credit card and emails, etc." Sigh. Of course people wouldn't remember that in Chrome where they ticked the radio button that says "encrypt my bookmarks", it says immediately below it "Use my Google account password." So people have already agreed to this - its the way Chrome works, people, and you agreed to it! Don't have a go at me!

10. But I knew this will bring complaints. So I next thought about the screen I'd need to get the users password. Instead of a simple standard popup, I made a full size screen that deliberately looked like the normal Android credentials popup. Here's a shot of the new password request/passphrase request screen:

In it, I then added a screenshot of the box in Chrome mentioning it would use your password and underlined it to make it clear to the user. Hopefully if anyone wants to complain, they can see this and realise they already agreed to Chrome using their password and its clear there is no other option other than disabling encryption completely or using a passphrase instead.

If you click on the "more info" button, you get an image cut from Chrome to prove why the password is requested by [ subtly! ] underlining some key text from Chrome in red:

11. Also started getting annoyed as to how long it takes for the Android emulator to start and run. It takes a large amount of my testing time waiting for the emulator. So I experimented with the latest x86 Android releases and got them up and running in a virtual machine. Starts in about two seconds and works each time by default! Amazing! Unfortunately that did mean the existing native code in the app wouldn't work for a different architecture. I recompiled it for x86 and after a day spent solving an annoying int/unsigned int compare that worked differently on arm compared to x86, it finally works as the arm version does and I use the x86 as my default test environment. Luckily the recent upgrade for androidpit help here as well as the x86 version doesn't have the market licensing installed which the app needs by default.

So that's where I am at the moment. I've yet to get new bookmarks and new folders sent to Google as encrypted items, so haven't tested that bit out, but I can read encrypted bookmarks and decrypt them once the user has supplied the key. I still think this is a pro feature, so I've added encryption to the app by default, but Lite users will only get the first five characters of the bookmark name decrypted (the URL, icon, and folders will all decrypt fine, just bookmark names will be partially decrypted). Can't wait for the one star complaints about that... :-)

Along the way, I had to build my own test Chrome sync server. Obviously the real thing isn't open sourced. There is a python version as part of the Chrome source, but its built for the unit tests so is quite limited in its functionality. I needed something where I could turn on or off decryption and emulate a changed password. This took me a while to build as well, but it's been useful to bang away my initial tests against it locally and not knacker my Google account along the way.

Word of warning for the next release - I've upgraded to the latest version of the Chrome protocols that are used in the stable and nightly versions. Unfortunately this does mean some database changes. Chrome uses the protocol version to determine how it might handle a bookmark or folder change. For example, one version might only accept numeric values for a certain field, but the next version might accept characters instead. If I attempt to upgrade in place, the user may have bookmarks already in their database that came from another version and the Chrome server will not accept that for the latest version number. So for that reason, this release will clear your ChromeMarks database when you upgrade so you are forced to download all your bookmarks from scratch. Sorry.

So some details on what I've been working on and what's remaining. Hopefully this will be  released in a few weeks!

Comments...? Do people like me to waffle away like this? Is it interesting/useful?

ChromeMarks - 2011.08.28 release

Another new upgrade today.

Mostly upgrading the internals, but a few new bits.

1. For the Lite app, I've added an "Upgrade Options" screen to the settings. This will show you what features of the full app are available to you should you choose to upgrade. So for example, can the app specifically integrate to your browser? Screenshot below.
2. Upgraded the crash reporter (ACRA) from v3.2 to v4.1. Not much difference to the user, but the info reported is a bit more helpful to me. Juicy bits that I really do need include the user's language, the rotation of their device at the time of error and the size of the user's screen. These help me to better work out what resources in the app might have caused a problem. It's also got functionality to save your email address keyed in such that if another error happens, you won't need to key it in again.
3. For the Lite app. Upgraded the admob ads. Allegedly they should cause less crashes - but talk on the forum is they fixed some stuff but broke some others.. :-) Also taken the opportunity to add in some ads for users that can't receive the ads previously - such as AdFree users. Previously, admob just hid itself away when it couldn't receive an ad. Now, you'll just get my ads instead. Sorry if you got used to no ads but, hey, you are using a free app supported by ad revenue, so please resist the 1 star comments..
4. Added Turkish translation. Thanks to Saner Apaydin for all his work! Another user who did it in record time - I have to keep asking these translators if they remembered to get some fresh air!
5. The usual handful of small bug fixes.

A picture of the new Upgrade Options screen in the Lite app:

Hope you enjoy the release - still more stuff yet to come..!

ChromeMarks update - 2011.08.07

Another new update for ChromeMarks. If a release could have a sub title, this would be the called the  "performance release".

As usual, the list of changes:

1. Finally taken the plunge and upgraded the the ACL (Android Compatibility Library). The most noticeable thing this brings is an improved way of loading the data for the screen and better management of the memory. For users, they should see folders open quicker and navigate quicker. For Honeycomb users, you (hopefully!) shouldn't get the force close when you return to the app after popping off elsewhere.
2. As another benefit of the above, if a folder takes less than a second to open, then the next folder will open without the "please wait...opening..." popup. The popup itself takes a moment to appear and then disappear, so removing it will make the results appear quicker generally. But I still need some kind of "progress" widget to let the user know the app received their touch event. I've added the ChromeMarks logo in the top left corner (Honeycomb users had it there already) and the logo will animate when you open a folder. Unfortunately Android can't animate the logo smoothly as it's busy furiously opening your folder! Once the folder is opened, Android now has the free cpu to animate it smoothly, but the op has finished so there is no need! Aarrgh! I might try to improve it if I can - but for now, it at least wiggles to let you know it's working.. :-)
3. Along the way, I've tweaked and eeked as much more as I can in various places to improve the core functionality and speed as much as I can. I even tried to get the icons to load after the rest of the screen to delay the non-essential stuff. But I had issues with the icons not recycling properly and appearing on the wrong bookmarks after you scrolled. This might appear in a later release, but for now it's commented out.
4. I've added a new fun stat to the "Info & statistics" screen. You can now see a total of much of Google's cpu you've personally used with each sync operation in ChromeMarks. It's not exactly useful, but anyone for playing top trumps?!
5. As requested by a user, since I added the "delete item" to the gestures, I've added it to the long click context menu as well.
6. More issues with Samsung devices. Dear oh dear, Samsung. Why do you have to make your own little changes to core Android and break something that works with *every* other device in the world...? A handful of reports from users experiencing force closes in specific settings screens only when using certain languages, or high cpu in various screens. I have no way of knowing what they broke, but they clearly broke something as no other device has these issues! I also can't reproduce any of it in the emulators (I've tested in 7 different android emulator versions) and can't reproduce on my personal phones. This further proves they've broken something in core android. I've no way of knowing what, but I've closed my eyes, spun round twice, cursed the Samsung deity and changed a handful of lines of code in a vain attempt it might make something work better or worse.
7. I've also added some extra tracing functionality such that I can explain to certain users how to enable it and send me extremely detailed traces. This might help with the high cpu - especially if I spot something in there that doesn't appear on any other device.
8. The usual bug fixes along the way. Thanks to all users who send in the automated errors reports - please don't click "cancel" on it - press send otherwise I'll never know about your bug and won't fix it. You don't have to enter an email or even any text, just press send! No personally identifiable info is sent either, so all you naughty pirates still using the 04.16 release can feel safe in sending the reports!
9. Some translation updates and corrections as well. More languages in the pipeline - Turkish is coming imminently!

Back to Samsung. The reality of it is, I'm actually spending more of my time investigating and trying to fix things that are broken only on Samsung devices, than I spend time making new features for the benefit of *all* my users. I'm afraid if this continues, I'll most likely have no choice but to disable Samsung apps from using this app completely and give up on them. I don't want to, but Samsung won't release the source, they won't answer emails, they won't answer tweets, they won't fix their remote testing developer site, they won't engage with the developer community even on their own website, they constantly make ill advised changes, what choice do I have..?


Enough with my rant... :-)

Next release..? A growing list of issues to fix with the local bookmarks syncing. Want to get an alternate Market integrated and working properly. Several changes to Chrome functionality that I want to pro-actively fix before another "July 12th" happens. A thorough restructuring of the debug messages which should make a noticeable decrease in file size. More gestures (double tap?). And that's just the list of things near the top of the list..

Still many, many  more new features and feedback on the plan for this app, stay tuned.

H.

ChromeMarks update 2011.07.22

Hi all - time for another update to ChromeMarks. Thankfully the changes made on the 12th July haven't had any issues that required a fix here, so these are all new features or fixes to things that have been broken for a while.

1. New features - Gestures. Only in the paid app. You can now specify that flicking up or down performs some action (i.e. up a folder, goto root) and swiping a bookmark or folder left/right will perform something else (i.e. open in new window, edit, delete). You can configure the "zone" that detects flings so it doesn't disrupt with your normal scrolling (i.e flings only work on the left half, right half, middle half, etc) and also configure the detection speed. I'm not too sure with the detection speed - it may be oversensitive, it's hard to tell as it also depends on the screen size and possibly the cpu speed. Some screenshots below.
2. New translations. Swedish, Dutch and Japanese. Thanks to all the translators who have helped (in no particular order) Kees Huiberts (nl), Gerben Markvoort (nl), Kjell Kernen (sv), Yutaka Takeda (ja), aozora (ja), Kazuo Ugai (ja).
3. It's clear from the automated bug reports there are many problems with the manufacturer builds of 3.0.1. There are many posts on the android developer forums where errors have been reported and the stock answer is "how can that possibly happen?" For whatever reason, some of the core java code is corrupted and invokes something else which will always be wrong. I don't know how it can happen, but it clearly is and many apps are affected by things that should *never* fail, but do! I've tried a few fixes here to deliberately avoid running the bits of code that knowingly fail on 3.0.1.
4. Note, the above fix is different to the other issues with Honeycomb generally regarding restarting the app keeps force closing it. That's due to changes Google forced on us with Honeycomb and neglected to make it backwards compatible with existing apps. Grrr. Hopefully a fix in a later release, but it will need a serious rewrite.
5. Some tweaks to the settings screens to dynamically resize the text for each setting's title. Hopefully you won't see text disappearing under a checkbox or drop down widget. Unfortunately I can't do this everywhere else, so popups and other text fields are still fixed sizes.
6. Changed the "Frequently asked questions" to "Help". The content is no longer hard coded answers. I've given a list of the most popular questions and linked them back to the community website. This allows me to provide more in depth answers, where needed, but to also be able to update them real-time. Also allows users to comment on them and get responses to those comments. Unfortunately this does mean the actual answers are no longer translated - though userecho (the website the community site is hosted with) says it will bring that functionality in at a later date.
7. If your first sync failed, you might have ended up with duplicate data on one of the tables in the database for each successive failed sync until it finally worked. It wasn't actually a big problem, but it might have simply made the database a smidge bigger and slower to access. Only talking a couple of extra records - if you had 1000 bookmarks, this would have had a negligible effect. On upgrade, the app will detect this and remove the extra records.

Note, there may have been some other changes that either Google started making from 12th July, or took effect due to me upgrading to the latest version of chrome sync service:

1. Some Chinese users were constantly getting ssl handshake errors. The analytics confirmed these errors were coming out for previous versions of the app as well, so it wasn't related to the last upgrade. It looks like an internet server somewhere in China that passes the traffic through to Google was mis-configured. After exactly a week, the reports started dropping fast. Thanks to Leo for sending me debug logs and for testing every few days and confirming things were working. Good job to, I wouldn't know where to complain about it!
2. Some users have started receiving "throttled" errors in the app when they change bookmarks or make new ones. Google normally throttles users to 100 changes a day. But previously it had always been a specific client software that was throttled (i.e. your desktop browser was throttled, but you could happily make 100 changes in ChromeMarks). The comments from some users might indicate that Google has changed this to throttling per user account - so irrespective of the client software, *you* can only make 100 changes a day. I've tried to get more info from Google, but don't hold your breath. Remember that auto-fill entries also count to your 100-a-day, so if you fill in a lot of form fields and have auto-fill synced, you'll hit your limit fast. More updates if I find out more info.

Some screenshots of the updated main settings screen and the Gestures screen showing some of the options (more off the bottom of the screen):

A reminder that I'm now on twitter as @chromemarks. Follow me if you want to hear about new features or Google outages and feel free to ask questions or comments.

Twitter action!

Just a quick message to say that I'm on twitter as @chromemarks and http://twitter.com/chromemarks. I'll try and tweet on new features I'm working on, new bugs or issues and anything else that might be useful. Send me a message if you have ideas, comments or questions!

ChromeMarks broken - IO Exception errors

Google have made some changes somewhere which has broken all ChromeMarks functionality.

I'm trying to fix it and hope a new release in the next day or so. Please bear with me - remember this app is coded and maintained by a single person during his spare time!

I don't know what they changed. From what I can see, the data is coming back fine, but at the very end of the sync are a couple of fields to denote the final progress and I suspect they've changed something around that area. It's a bit annoying as one of the fundamental purposes of the protocol buffers Google invented and use for this communication are meant to be always backwards compatible.

I guess Google thought that the only people using chromesync would be users of Chrome and since they should be auto-updating, what's the harm in turning off some old server functionality, eh....?

More updates later.

UPDATE: 22.45pm BST. I think I've fixed it. Will update more here in the next hour while I refresh the Market.

UPDATE. So, I'm still not exactly sure what they broke, so I've had to upgrade the app asap to the latest protocols. The app has gone from release 24 to release 27. Google have made quite a few changes along the way, partly why I've been putting this off for so long.

But with a nice bit of Fiddler (where would this app be without it??) and I *think* I've worked out how the new protocols work. They didn't quite fit immediately in, but with a squeeze, they work.

Unfortunately Google have changed the way they track changes and moved from an increasing "number" to a semi-random byte array (may not be random to them, but clients should not expect them to follow any logical pattern). This necessitated a change to the database that ChromeMarks is held in. If I'd done this as normal change in my own time, I would have written a migration into the app to fix this as soon as you upgrade. But I didn't want the app to be offline for too long and my wallet can't afford all those annoying people that vote one-star, so I've chickened out and made the app reset-to-default when you open it to force you to redownload. Sorry! Not my fault!

I've tested what I can in the time so far, but since the bug happened 24 hours ago, I've needed sleep, travel time and a normal job, so please be gentle if there are a few more bugs I didn't spot! They will get fixed as soon as I can. I've only checked it on Froyo as that's the most prevalent - I'll have a try shortly on Honeycomb as that's the most likely to be tetchy.. :-)

Annoyingly I was going to make a release this weekend with some real goodies for the paid app (could I say it was a "gesture" to "fling" these changes in your direction?), but now I've got to merge two changed versions of the app together. So the next official release (barring bug fixes) will probably be next weekend.

As usual, thanks for your support and to the people that mailed me letting me know there were problems, and to everyone else who actually read the note on the Market.

I think I need some sleep...

ChromeMarks updated 2011.07.02

Another update. As normal, the details in more detail (!)

1. Experimental fix for Samsung owners who experience disappearing local bookmarks created by ChromeMarks. The root cause is due to Samsung making naughty changes to the Stock Browser and neglecting to make those changes work with the hundreds of bookmark apps on the Market. Lots of thanks to Emiel who sent me enough files to guess the changes made by Samsung. There may still be some more changes needed here to polish it a bit, but the bookmarks are now visible, at the least. NOTE this has only been tested on the GT-I9000 - other Samsungs may work, or not! Let me know! When you first upgrade, the app will attempt to fix any bookmarks you may already have there and then. Otherwise, the normal sync should do the work anyway.
2. Added Portuguese translation. Though I'm a bit worried as to wether it's Brazillian Portuguese or normal Portuguese! Time will tell... :-)
3. Fixed the Folder browser on Honeycomb devices. This is used in the settings when choosing the Home folder, or when editing a bookmark/folder and choosing the folder it is saved into. It was definitely a Honeycomb bug as it worked fine in all other versions. But it was hard to track down! But for some reason, I made a sprinkling of tweaks that made it suddenly work - I saved the changes immediately and cross the fingers it doesn't stop again!
4. The usual bug fixes along the way.

No pictures this time as nothing UI has changed. There are a sprinkling of UI improvements I want to make soon, Gingerbread needs a bit of TLC now.

ChromeMarks update 22.06.2011

Another update to ChromeMarks. The juicy details:

1. When a sync finishes, the last date something was received by Google is displayed back as well. This should hopefully allow you to see quickly if your Chrome browser is actually syncing - if the last date reported is two weeks ago but you know you created a new bookmark in Chrome yesterday, then Chrome is lying to you.
2. Initial work on a "first time use" popup. Currently this just confirms the date of the last change received by Google. Will detect and add more soon, such as "have you enabled sync in Chrome?" or "you have duplicates, would you like to know how to fix Chrome to correct it?" Again, trying to step the Market comments saying my app is not working, when it's completely down to Chrome bugs!
3. Authenticate with Google once per week instead of every sync. Should speed things up a bit. A checkbox under Advanced settings can turn this off if it causes trouble. I may be able to extend this to maybe two weeks or more? It should handle password changes, but I haven't tried to confirm it!
4. German translation. Tons of thanks to Steven Jung for all his help.
5. Some tweaks to the settings screens, specifically for Light themes. Someone whinged in a Market comment which prompted me to check on the status of android bug 4611. There had been a recent update from someone suggesting another way to try. Things look better now.
6. Corrections to some translations, just a handful of Italians ones tweaked.
7. A sprinkling of bug fixes.
8. Big G made changes that meant I may not have been receiving bug reports for the last month. Google changed it such that Docs form submissions had to be by https where previously they could be unsecure. There had been a change to ACRA recently to ensure the submitted bug reports are https so I upgraded the single line of code. There's a newer version of ACRA that I might migrate to soon as it captures a lot more helpful info after a crash.

A screenshot of the new "this is the first time you synced, here's the last date reported by Google that they received bookmarks from your browser":

ChromeMarks Update 2011.06.05

A long overdue update to ChromeMarks. As usual, the list of the all important stuff:

1. New app icon and artwork. Thanks to Dries Oeyen (http://nexworx.com/dries) for his work and for everyone who voted. Thanks also to the runner up Émilien.
2. Significant changes to the core of the sync engine. I've written some of it in native code (which is C). This may not bring much performance improvements, but it does allow me the potential to easy merge large chunks of the real Chrome source code into the program and benefit from reliable code and not having to rewrite it into another language. But I'm new to this and I can't guarantee there isn't a memory leak here or there or any incompatibility. I'm nervous as it's compiled for a specific architecture which allegedly should work on all current android devices - but until it's out there, I won't know for sure!
3. A fix for users that had overriden the home folder and experienced a crash when they opened the app. This was usually due to that overriden folder being deleted later or updated later and the app not handling that well.
4. Italian translation. Thanks to Sergio Alisi for all his work.
5. More captures of corrupted databases. Android really does have a lot of soft spots..!

Sorry it took so long this one, but I had to learn C from scratch and it took a while to get something stable enough to prove this was a valid direction.

ChromeMarks - Vote for a new logo!

Hi all. I've opened up a public vote for a new app logo. Since so many of you [ :-P ] like to leave comments on the market about the logo, now's your one and only chance to help pick the new one!

Simply goto www.howardb.com and click on "vote" in the menu. There are four logos to pick as very kindly provided by two fantastically eager designers. Personally, I'm happy with *any* of them - but you've seen my last attempt, so this time, I didn't want to be the one making the choice.

Please register your approvals using the online vote. Votes are open for two weeks until 20th May and will be used from the next release of the app.

Feel free to leave some comments on the poll, but I don't think I can respond to them, so if you do have questions, it would be simpler to mail me direct chromemarks@howardb.com

NOTE also that the Chrome logo is still copyright Google, so I can't make the new logo any more "like" the chrome logo - it deliberately has to be different, so please don't ask for it to be more Chrome-y as my hands are tied.

Thanks again!

ChromeMarks updated - 2011.04.16

An update to ChromeMarks today. Was due to release this two weeks ago, but the Developer console was a bit sick and I haven't had a chance until now to try again.

Here are the changes:

1. User request. Added the ability to choose what folder the "home" icon opens. At the moment this is via the Settings, but I may make it an long click option when you click on a folder.
2. User request. Added the ability to choose from a list of installed browsers to open a bookmark with. Long press on a bookmark and select "Open in...". If you've only got one browser, then it will work just like a normal press of "Open".
3. FULL VERSION: Fixed an issue where Google would deny a "sync local bookmarks" if one of the local bookmarks has an empty name. Thanks to Andrew for the debug logs.
4. FULL VERSION: If you set the "force folder length" to an empty value (rather than a number) this caused an failure. 
5. Some improvements to the functionality for Honeycomb users (e.g. Xoom). You should now be able to use the menu properly. I've had to disable Theme support, though, as it doesn't work well. Sorry I missed it - I did try the app a while ago in the emulator but since it doesn't have the lvl installed (grrr, google, grrr) then I couldn't actually test the app properly.
6. For the American users out there, I've changed the spelling on initialise to the non-official spelling initialize. Always thinking of my users.. :-)
7. Some icon tweaks. If anyone would like to design a new icon, do please contact me!

There's a bit of a back log of auto-errors that I'm working through, so a belated bugfix release soon.

ChromeMarks updated 2011.03.12 - Integrated bookmarks

An update to ChromeMarks has just been published. Most changes are in the full app:

1. Experimental integration with the Stock Android Browser. The app can now export *all* Chrome bookmarks and folders into your local browser. Choose to include dummy folders, or omit the folders and prefix each bookmark's name with parts of the folders it is under. This is one way in this releaes - any changes made to the integrated bookmarks in the stock browser will be overwritten and replaced with the next sync. It's also only alphabetical at the moment..
2. Noticed from the analytics that a few people are experiencing database errors that are clearly Android corruption. This is not something the app can create or fix. So I've added some popups to let the user know that the app is unlikely to function properly until the database is fixed. The only fix appears to be an uninstall and reinstall. I don't know if a "reset to default" will fix it.
3. Noticed also that every now and then the inserts of local bookmarks fails due to an invalid bookmark. Again, a popup has been added to ask the user to mail me with details so I can try to help fix it.
4. The usual bug fixes.

A screenshot showing my stock android browser bookmarks. You can see dummy folders and the bookmarks beneath them indented according to their hierarchy.

If you try this new feature, please do mail me to let me know if it works for you - or not!

Chromemarks - updated 06.02.2011

Another update. This time to add in the feature most voted for on the community website (see, it works!):

You now have a choice of four sort options (though the Chrome sort order is only for the paid app).

This did require some changes to the database and most of the data I'd never been capturing anyway. So you need to re-download all your bookmarks anyway.. :-)

Some other bug fixes as well. I'm sure I've found a bug somewhere in the android installer process - *a few* users have been reporting the icons has gone missing for the app and the acra error reports are showing missing resources in the apps for a handful of users. I don't know what is making part of the install go missing for only a few people, but I've got a hunch it's to do with reserving id's for drawables and strings in the library project. The documentation doesn't say you can't, but it doesn't say you can either and I think this might be the issue. We'll see if this cuts down on the reported problems.

A sprinkling of other bugs as normal.

Barring any further issues or a sudden increase in votes on the website for other features, I'm back to looking at integrating bookmarks into the browser. Yikes!

More options!

Another update to ChromeMarks today.

Previously, when you long clicked on a bookmark or folder, you got this kind of popup:

...which was fine and reasonable. But it was based on an AlertDialog and as such had a maximum of three buttons (i know you can add more in the content area above, but that would look horrible) and those buttons were limited to a handful of letters each.

It didn't give much room for more options.

Today a new release with an improved context menu. It looks more Android now and has space enough to keep going, so more options can be added whenever:

The URL at the top is still scrollable so you can see all of it. The optons go downwards, so you can scroll to see more.

To start with, I've added several new options in this menu:

1. Open in New window. This depends on the browser you use, but should open the selected bookmark in a new tab and not overwrite any currently open tabs. If your browser doesn't use tabs or doesn't understand the message, then it will simply open as normal.
2. Share Link. This allows you to send the bookmark name and url to any other app that can respond to a share. So that means you can send a bookmark to someone else via email or facebook or twitter.
3. Copy Link URL. Copies the url to clipboard so if you want to copy it to another app that doesn't do sharing, you can still get it easily.

As I come up with new options, this seems a good place to put them. Note that the context menu now looks very similar to the context menu in the stock browser.

The Folders also have a new context menu, but with less options on it, but still room to add more over time.

The other big change was the first translation of the app to another language. This translation was into French by Guillaume who kindly did it for free! I offered refunds but he wasn't listening! Merci Beaucoup!

Theme support released

A new release of ChromeMarks today. The Theme support is now available for both the Free and Lite apps in the Market.

The app comes with three Themes built in at the moment, with room for more over time and as people request them.

1. Default. The one you all know and love (!) This uses whatever colour background and text you Android has by default. For most of us, that's a black background.
2. Light. A fresher look. This has a white background with black text and green urls. The header bar across the top is better styled and more professional looking and the buttons merge into the folder name. There is also a default icon for bookmarks that have no icon.
3. Light swapped. The same as the Light theme, but with the up and home buttons swapped over. This might be better for righties who probably want to press up more than home.

The usual screenshots are on the previous post and haven't changed since that beta.

Also included was a significant revamp of the Settings screens. Previously, it was one big list with stuff in any order and not quite related to the setting above or below it. I've now got a much better Settings screen where you choose the category instead. This screen has icons to help identify the categories and also a brief description of what the category does. Hopefully this further improves the feel of the app.

The usual bugfixes as well. As is traditional, the first release had a bug and was fixed half an hour later with the b release. Seems to be happening a lot recently.. :-) Thanks to Ted for quickly mailing me and letting me know of the bug.

Another release in a day or so - this should add a popup to appear if you have no bookmarks to say "Are you sure you've enabled sync in Chrome?" as I'm not happy with the comments on the Market from people who slag the app off when it's their problem. :-) Plus a couple of bugs fixed that users have spotted with the local sync.

Theme support and improved settings

Just a quick update to show off some of the new Themes and Settings:

The new "Settings" page. Each option opens a new settings screen. The previous Settings screen was a bit of a jumble with many things listed in a bit of a random order. It also looked a bit too "plain" and hopefully the new icons and the lighter indented text make it a better.

The preference to set a Theme. There are three currently coded.

The main bookmarks list rendered using the new "Light" theme. Note the rendered button bar across the top and a bit more colour in the results themselves.

For the people who asked to be beta testers, I might be ready to send something out tomorrow.

For all others, barring any bugs, this should be published in a few days.

ChromMarks - updated 2nd Jan 2011

A new update for ChromeMarks.

The major change is the (hopefully) working Android Bookmarks sync.

ChromeMarks will now be able to copy your Android Browser bookmarks to a new folder visible in Chrome and keep them synced there. You can edit them on your PC and when you next sync in ChromeMarks, the changes will be reflected in your Android browser.

This is the first release for this feature, and probably the one that makes most people use the "edit/create" functionality built into ChromeMarks - so I don't doubt that a few new errors may be spotted over the coming weeks as more and more people start using more of the functionality.

As such, I'd suggest that if you really rely on your bookmarks (Android browser and/or Chrome) then I'd hang off trying this out until most of the bugs are ironed out. The worst that could possibly happen is it just deletes a bookmark you didn't want it to, so it's not like it will set your phone on fire... -)

That said, it'll never get the bugs fixed unless some people give it a whirl!

Other changes this release include a ton of bugfixes. Thanks again for all the bug reports, they really do help me get exactly to the root of the bugs.

The main bugs so far have been due to the annoying way that android handles orientation changes. When you turn your screen around, android destroys the activity and starts it again. Sounds reasonable, but if the activity is busy doing something (e.g. opening a folder, syncing) then that existing work starts to crash as it is no longer attached to a working window. Grrr. Hopefully I've fixed most of these now - though admittedly I can't get the Settings screen to work well yet..

Additionally, I've made substantial changes in readiness of Theme support. Although you can't tell, the app is already running a new Theme. The next release should bring some more options, including a "Light" theme that looks a bit more fresher.

Enjoy!