Blog updates

Saturday, 14 July 2012

ChromeMarks 2012.07.14

A new update to ChromeMarks today.

Firstly - apologies for the delay since the last update. The normal day job, the usual PC problems and no internet for a month all contributed to it. But I've been tinkering away as normal and the updates are coming!

The juicy details:

  1. A bug fix for Jelly Bean users of the Full app. Turns out that Google made undocumented changes to the SSL implementation with Jelly Bean which was causing a crash when verifying the digital signature sent back by Google. There are other apps on the Market that are experiencing similar issues with the SSL classes. Once I've got this release out, I'll file an Android bug report as it's clearly a regression from Big G.
  2. A New feature for the Full App. You can now choose to backup your Chrome bookmarks before and/or after each sync. The backups are stored on your SD card and you can specify the maximum amount of backup files to keep at any one time. If you accidentally delete some bookmarks from Chrome, you can roll back and import one of the backups into Chrome to resurrect them.
  3. For the Full app, a bit better compatibility with some apps that "share" more than just a url (i.e. Flipboard).
  4. The Folder picker seems to have some issues on 4.0.x devices. There are no problems on 2.x, 3.x or 4.1 - just 4.0.x. Which makes me think this must be another Google regression they fixed for JB. However, as soon as I simply recompiled the app, the folder picker started working on my personal 4.0.3 device. wtf? Anyway, I'm gonna rewrite it soon to a simpler type of widget which hopefully won't have the same issues as a WebView with embedded javascript. But Android doesn't have any existing widget that does this kind of functionality, so it'll be completely bespoke.
  5. For the Full app, there were some issues with the Local syncing function - for most errors, it simply stopped syncing and didn't report a problem. I've made it start to return error messages now so if you get errors where you didn't previously, then it wasn't working properly anyway! A couple of fixes along the way - some new validation from Google was causing problems if you were a 2.x user using the "copy bookmarks to a new folder in chrome" function. And some improvements to the 3.x and 4.x integration.
  6. The long press context menu was a bit lopp-sided. If you long pressed on a bookmark and then changed folder and then long clicked on a folder, you'd get the same list of options you got for a bookmark (and vice versa). Fixed that.
  7. The "Mobile bookmarks" or "Synced bookmarks" folder now appears at the root level. Note, if you already have data in the app then you'll need to reset or uninstall/reinstall for the change to take effect.
  8. And many, many, many more bugs fixed along the way..!

So what's next..?

Well, I'd like to investigate getting synced tabs to appear in the app. And a way to "hide" the search engines folder. And allegedly, Dolphin now have an sdk that allows other apps to integrate with it - so maybe a play there.

Saturday, 17 March 2012

ChromeMarks - update 20112.03.17

Time for another update..!
  1. Some more changes made by Google on the chromesync servers which are starting to affect a few users:
    • Some new error messages were being returned which users have started receiving. Since ChromeMarks isn't aware of these messages, the app isn't showing anything back to users so you don't know there was a problem. One of the new messages tells users "your bookmarks have been upgraded on Google's servers - you need to reset the app and re-download them again". Fixed. But don't know what they "upgraded" in the first place - I suspect it's more fixes for crbug.com/114912 ..?
    • A subtle change to the way some timestamps were being returned from Google. They seem to now be changing when they previously weren't. Since they never changed before, ChromeMarks didn't know to spot that change and be aware of it. This may have meant (e.g.) a sync returned no new bookmarks since the timestamp ChromeMarks sent was old. Fixed.
  2. A revamp of the Search facility. Some new errors appeared when Big G released android 4.0.3 as they clearly changed something in the Stock Search Widget that didn't call ChromeMarks the same as all previous versions of Android. The rewritten code is smaller, quicker, simpler and strangely more compatible. Hey ho!
  3. For users of the Full app, if you have synced Chrome Search Engines, you can now search using them using the search from the app or the Stock Search Widget. So, if you have a Search Engine for Wikipedia and the keyword for it is "wiki" then you can search for "wiki android" and the app will suggest "Search Wikipedia for: android". If you click on the suggestion, you'll go straight to Wikipedia's search results for the word "android". Of course, depending on your Android search settings, you could possibly just use "wi android" and that might be enough text to find and suggest searching Wikipedia.
  4. A fix for HTC devices using the integrate local bookmarks function. Looks like HTC want to be different to every other Android device and they choose to sort bookmarks in the Browser differently. Thanks to some log files and screenshots from Steve, a fix to try and sort them the same as everyone else.
  5. There was a recent change to Chrome (#94992) to remove static initialisers (which should make Chrome startup quicker). This had the lucky effect that the protocols used for syncing became slightly simpler and quicker at runtime. I've rolled this into the app. This now gives the opportunity for a much larger change to the protocols which makes them considerably "lighter" in cpu, memory and speed. I hope to trial this soon as it might make a sync operation run much quicker - but I might have to wait for Chrome 19 to be stable first..?
  6. Tweaked the Gestures code to try and be more density independant. I had got some reports that higher dpi devices were harder to use gestures so this should make gestures work the same on all devices. But I can't easily test it as the emulator is tricker to test gestures well - let me know if this is better/worse..?
That's it for now!

On a side note, I've moved my main computer over to a linux build as I've had enough of Windows and I never really gelled with Windows 7 (don't get me started on the horrible changes they forced on us with the ListView component..). I'm currently using Kubuntu - I started with Ubuntu but found it a bit too lite for me - Unity was one of the first things to go. Seems to be working okay with a sprinkling of challenges along the way. Android building seems to be okay, but almost twice as fast as Win7 used to be on the exact same hardware. wtf..?

Laters.

    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 http://crbug.com/114912 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...

    TTFN.

    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.
    Its.
    That.
    Simple.

    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!

    Thursday, 12 January 2012

    Chromemarks Updated - 2012.01.12

    To continue with my new years' resolution of smaller, quicker updates - it's time for an update!
    1. Added a new Tutorial or "Quick Start" screen. This is only shown for brand new installs. It shows briefly how to perform the first sync, some common customisations and some common problems. Also uses the fancy swipey new ViewPager with a cute title indicator across the top. Also a nice offset image of the ChromeMarks logo behind the first screen - looks nice and arty.. Screenshots:





    2. Some fixes for the new OAuth2 process. The OAuth2 process relies on sending back the tokens in the title of the webpage which is easy for my app to pick up and then use. Unfortunately it looks likethere are a few devices out there that are returning *no* title. This makes the OAuth2 quite pointless on these devices! I've found another way to try it whereby the token is returned in the url instead and that's easy to grab. Hopefully that should work on all devices as a url is a url. Thanks to Curtis for being one of the first users with a Kindle Fire to kindly fill in his email address in the error box and happily test a fixed version for me.
    3. A mild tweak to the Google authenticator that was crashing if the user's token was more than 7 days old. Only had about 4 reports of this error, so it wasn't causing much trouble. Fixed nonetheless.
    4. Some tweaking to the size of the favicon shown for each bookmark and also when editing/creating the bookmark. I've made the icon one pixel smaller, but that now means it's rendered the exact size the icon is - this means the icon looks much crisper and cleaner. Hopefully the size decrease won't be too noticeable. Also tweaked the new "choose icon" popup to look better on higher dpi devices.
    5. Upgraded the Android Support/compatibility library to the latest version. I haven't spotted any issues arising from the previous one or the new so couldn't see any harm in doing this.
    6. Took the opportunity to revamp the help screens as well. Instead of having all the help links built into the app, the app now opens a webpage on an external website of mine. This allows me to easily change and reword the text and to add new answers should I get a flurry of new questions. This means we lose the translations for the original questions...but they still linked back to English answers anyway.. :-(
    Next release is currently slated to be Honeycomb/ICS browser integration. Full app only. The ICS should be do-able, but can't guarantee Honeycomb as the source still isn't fully released. It'll be one-way at first, but some of the extra columns added by Google in the browser should help make this easier to make two-way at a later date.

    I've had quite a lot of time off work recently which has helped with the recent releases - back to work again next week so releases may slow back down again.. :-/

    Laters!

    Thursday, 5 January 2012

    Chromemarks Updated - 2012.01.05

    First new update of the year. Sorry it took so long but some of the changes had the potential to impact many users so I needed to take my time to test them more carefully.

    As usual, the release notes:

    1. I've completely rewritten the network stack. There are two common ways of performing a network request in Android - apache http client and java net. Both have pros and cons and the app had been one for certain parts of logic and the other for other things. A while back a posting on the android developer blog suggested that they had been optimising one of these with each release of android and not touching the other one anymore.

      So I've made all network requests funnel through to a single place that determines the one method to use that is the most appropriate for your device (as suggested by Google on that blog). It's made the code a bit cleaner in many places as well. But just in case, I've added an override in the advanced settings that allows you to change the network stack to another one - use with caution as the app should pick the right one always and the different (i.e. not Google recommended) one may introduce other unknown errors.

      Preference to allow you to override the net work implementation. Use with caution!

      For users on Gingerbread and above, you may notice some performance benefits as the app is always using the more optimised version for your devices.
    2. Fixed a pet annoyance of mine. When creating/editing a bookmark in the full app, you could choose to fetch the icon. This did a round robin of three icon providers and picked the first that conformed to chrome's standards. Unfortunately they weren't always the prettiest icons returned by the providers - some times they were a bit washed out as the bpp had been lowered by the provider. There was also another provider out there that returned better quality icons, but wasn't in a format that Android could easily accept. I managed to find a way to accept the fourth icon provider, so now the app will allow you to see the results from all four. You can pick the one you like best and use that.

      Choose the icon to use. Click "view larger" to make them larger, but remember they are only 16 pixels so larger also means blurrier.

      May want a little more tweaking here as this all looks good on the emulator, but on my real phone the icons are a bit small and maybe hard to select - I think I'll need to add some scaling for device density to fix this. Also, they are requested one at a time and I'd like to try and ping off the request concurrently as if one provider takes a while to respond it holds them all up.
    3. For the full app, you can now add a widget to your home screen that will perform an immediate sync. It doesn't look pretty, but it works. My first foray into widgets - I still want to try and see if I can get a proper bookmarks widget sometime this year (but for users on 2.3 and below, there are no scrollable widgets so this adds a large amount of extra complexity). This "sync now" widget at the moment starts a sync itself. I may change that later to broadcast an intent which the main app responds to - this would then allow users to send that same intent from any other app they like, i.e. tasker, llama, etc.


      Rather boring screenshot of the new boring widget.. :-)

    4. Some hefty changes to the authenticator code. This is used to get tokens from Google to access your bookmarks and to authenticate/refresh them and authenticate to Chrome using those tokens. I've pulling it all out into it's own implementation. This allowed me to build an OAuth2 flavour as well. For users on non-google licensed devices (i.e. rockchip tablets, kindle fire, folio, etc), Google will not send back bookmarks to these devices if you authenticate via the android account. I'm guessing this is a large licensing block put in place. Over the last few months I've noticed some code going into Chrome to allow you to use OAuth2 to authenticate with Chrome instead. I don't know how to invoke it as the latest canary still uses the normal method of login - I'm guessing this might be there for chrome-os? Anyway, I've pinched some of the flags needed and now my app can do an OAuth2 request and retrieve your bookmarks. Now the standard Android account is still more secure, faster and most appropriate for accessing bookmarks, so please don't cut over to OAuth2 if the app already works for you. But for those who can't use the android account, this is the only decent alternative.


      NOTE: I still need some playtime - I'm not sure how this works with 2-step verification - I'm sure it does work, but I don't know which password to use yet. Hopefully this shouldn't break existing users authentication...:-)
    5. Some mild tweaks to the action bar for ICS users - before ICS the previous users with an action bar were wide tablets. Now with ICS, they might be mobile users and I noticed the action bar was getting mighty cramped and often the text wasn't all fitting in. I've tweaked this now to move the "sync" button to the main menu if there isn't enough space to display it normally.
    6. Another reason for the delays was that I wanted to try and get some proper testing suites up and running. Recently it's taken me longer and longer to test each release as I need to play on at least 5 different android emulators which might also further expand to include market and non-market devices depending on the changes. This takes a lot of time to keep repeating the same thing and if I make a mild tweak, I have to go back and run them all again and try to ensure I follow the same steps. So I've spent some time creating proper unit tests for some of the core functionality (simple sync tests, http tests, file export tests, etc, etc). It was a bit tricky to implement as I just couldn't get it to work in a seperate app like the documentation suggests (I had to keep adding more and more jar files to be exported and that just didn't seem right or automateable). In the end I've added them to the main app's codebase and my ant scripts that produce my builds simply hide or include that code. This also helped me fix a couple of bugs along the way in the authenticator and the main sync. Hopefully I'll add more over time.
    7. Some more tweaks to the backup functionality in the main app. Once again I was being stung by the android 1mb limit in a cursor, so I've split the data out and retrieve icons separately. Might mean a slightly slower export - especially if you have a lot of icons - but it should be more reliable. Also, some more fixes around the creation of the file itself whereby some errors to access the sdcard weren't being reported to the user properly.
    8. Also noticed at the start of December that the Lite app has been downloaded 250,000 times! Fantastic result! Also even better considering it only went on the market on November 28th 2010, so that's literally 250k in 12 months!
    That's it for now. One new year's resolution is to *try* and release smaller, quicker. So the next release will either have some Honeycomb/ICS browser integration in it, or more likely a first-run tutorial with pretty pictures. It's likely to be the tutorial as it takes a lot of my time to respond to the emails from people who state "app is crap - no bookmarks found" and when I ask them "have you enabled sync in Chrome?", they then seem to go quiet... :-)