Blog updates

Thursday 20 December 2012

CMarks - Updated 2012.12.20

Hi all,

An emergency bugfix to CMarks today. Only one change.


Starting late on the 17th December, Google enable some new validation on the chromesync servers. This meant that a small proportion of users started getting an "Error 500" message when they sync. It took two days before it started to affect one of my test accounts and I could finally reproduce the error. I started playing and found the field that I thought was affected.

I'd already raised a chrome bug so I commented on it about that field - I wasn't expecting anyone at Google would actually respond. I was happily surprised when a kind person from the sync team updated the bug report and confirmed it was indeed that field and suggested how to fix it.

The tricky part was producing a fixed app. Shortly after the last release I had upgraded my Android development software to the latest version and this required hundreds of small changes to the app before it would compile again (grrr!) Annoyingly, you can't really downgrade the Android dev software, so it was very hacky to force out a new release - I almost resorted to using some of those tools the script kiddies use for hacking apps.

Any-whoo, thanks to some kind users (particularly Robert) for testing the fix and it's now deployed. Hope it works well!

As for the app, I'm currently working on the next release - some major new functionality for the Full app.

Did someone mention synced tabs..?

TTFN.

Sunday 11 November 2012

CMarks updated - 2012.11.11

Time for an update.

First, a reason for the recent lack of updates. I spent a good few weeks (remember, I only have a couple of hours free time per week anyway) trying to add a new library for communicating with Google. The new library claimed huge performance benefits which I hoped could make each sync even faster. But it took a while to plumb in and I had to contribute several patches to it before it was useable. And then I compared the results with the previous library. No difference - in fact the new one was slightly slower on average. Right click, undo. Grrr.

Back to the updates

  1. I've upgrade the chrome protocols to the latest versions used in the chrome beta version 24. This brings in a couple of new fields which Chrome is starting to use. Note that there are many changes to the sync service coming over the next few months. Many of these rely on changes on the sync servers themselves - so until Google flick the switch, I can't test or prepare for many of these. So if something suddenly stops working, please mail me so I can investigate!
  2. There were a few bugs that were happening under some scenarios when integrating or backing up bookmarks. To be honest, the app had already failed for some reason, but it couldn't return the error message of the failure back to the user.
  3. I completely missed the fact that any Mobile bookmarks (or Synced bookmarks) weren't being integrated into the Stock Browser, Dolphin or any backups. Oops! Thanks to Pierre for nudging me.
  4. If you cancelled the decryption popup, the app would have checked for duplicated bookmarks and since everything still has the name "encrypted", the app would have mentioned you had duplciates. Until the bookmarks are decrypted, the check for duplicates is now deferred.
  5. If there were any problems during the auto-sync feature, the notification shown on your device might have had black text on a black background. Ooops!
  6. Some extra fields added to the Info & Statistics popup, but they might only appear depending on the data Google returns, which might depend on some new features they haven't turned on yet.
  7. A sprinkling of the usual bug fixes - quite a few within the decryption dialog.
Enjoy - see you laters!

Sunday 16 September 2012

CMarks Update - 2012.09.16

Time for a quick update.

  1. Added the ability to "hide" any of the Root folders i.e. Search Engines, Synced Bookmarks, etc. Also added a new option in the Settings, Application Defaults to allow you to manage this list. Only for the Full app, though!
  2. Fixed a couple of crashes happening during the local sync on 2.x devices when syncing to the special folder in Chrome. 
  3. Some performance improvements when navigating to the root folder.
Enjoy!

Sunday 9 September 2012

Cmarks Update - 2012.09.09

A quick CMarks update. This is for the Full app only.

  1. CMarks can now integrate your Chrome bookmarks into Dolphin using the same ordering you've specified in CMarks. Some caveats - though:
    • Dolphin always shows Folders alphabetically and at the top of a list. I can't change the ordering or placement of Folders.
    • Dolphin always removes any bookmark being inserted that has the same url as any existing bookmark. So if Dolphin already has www.google.com as a bookmark and your Chrome bookmarks also have it, then you won't see it in the bookmarks integrated as Dolphin will simply remove it.
  2. Performance improvements integrating bookmarks to Dolphin. Since Dolphin doesn't accept icons during the integration, I've disabled the code from retrieving them from the database which does make a difference.
  3. Fixed a crash from some devices when clicking on the "About" link the Dolphin CMarks Add-On screen.
  4. Some improvements to the "Sync" widget. Widgets require a lot more effort to make them look pretty and I never had the opportunity to make the widget look really good before. So some changes this release to make it better. Annoyingly the stock homescreen widgets have differing layouts on GB, HC, ICS and JB. So I've had to specify a widget layout for each release of Android otherwise it all goes south. At the very least, it no longer has that boring phat white background.
That's it for now - enjoy!

Sunday 2 September 2012

2012.09.02 - CMarks update

Time for another update!
  1. Users of the Full app can now integrate their bookmarks into Dolphin browser or Dolphin Beta. This has only been possible due to the recently introduced Garage API for Dolphin - until about three months ago, this was still only possible for apps created and owned by Dolphin. Some points to bear in mind, though:
    • This is currently only one-way. So any changes made in the integrated folders in Dolphin will be overwritten/lost when you sync. As normal, though, to create a new Chrome bookmark just "share" it into CMarks instead of your browser.
    • There are still some restrictions from Dolphin - primarily an integration can only occur from you clicking on a button or doing something inside of Dolphin. I can't start the integration from CMarks as Dolphin doesn't allow it - so no integration each time you perform a CMarks sync. It's annoying, but nothing I can do about it - direct requests to Dolphin developers, please.
    • To integrate your bookmarks, open the Add-Ons pane inside Dolphin (swipe inwards from the right hand edge or use the menus), then simply click on the CMarks Add-On and your bookmarks will be integrated there and then.
    • The access Dolphin allows is still very limited. As such, I have no way of telling apart a bookmark that CMarks has integrated or a bookmark the user has created. So to avoid me deleting *all* the user's bookmarks rather than just the integrated ones, I've chosen to integrate them into a new root folder called "CMarks". Yes, it's an extra folder to click into but it keeps your existing bookmarks safe. But if users would like an option to be able to use the Dolphin root folders ("Bookmark bar", "Other bookmarks") and accept that they will be completely emptied each time you integrate, then let me know!
  2. Prompted by another whingey comment on the Play Store, I've added a new popup to tell you if you have a significant proportion of duplicated bookmarks within the same folder. These sort of duplicates can only be caused by one of the many bugs in Chrome. Annoyingly, users who only have one copy of Chrome on their desktop machine will never see these duplicates until (a) their machine dies and they first sign into Chrome on a new machine or (b) install another Chrome client - of which CMarks is an example. So I still get people complaining that CMarks has duplicated their bookmarks when it clearly hasn't - they've been duplicated for days, weeks, months already! So a new popup might appear after a sync. You can disable it if you genuinely want to ignore it when you first see it. It might introduce a mild delay at the end of each sync, but it provides a quick warning that your Chrome browser has suddenly hit a bug.
  3. Update the Swedish translations - thanks again Kjell! Looks like Swedish is now at almost 100% translated (or it was when Kjell finished - sorry, I've added a couple more since!)
Until next time!

Sunday 19 August 2012

CMarks Update 19.08.2012

Well, I'm still here, so I guess I'm okay to keep developing this app.

As such, some updates:
  1. Finally managed to get Themes to work 3.x and above devices. Some changes Google made with 3.x caused some issues that I hadn't managed to work around previously. With a smidge of extra effort, I've found enough workarounds to re-enable Themes for all devices now.
  2. Fixed a bug that had been annoying me - if you set the home folder to a folder that was empty, the app would give you the initial "no bookmarks were found" message. This might also have been triggered if the first folder the app opened to was empty as well.
  3. Fixed a bug with the 2.x sync to a Chrome folder if the user had more than 20 bookmarks to send to Google. Since Google only accepts data in batches of 20, there might be entries in a second batch that refer back to entries in the first batch. But the temporary ids sent with the first batch are only temporary and if they are used on the second batch, Google doesn't like it. I found a cunning way around it.
  4. Fixed another couple of bugs with the 2.x sync to a Chrome folder that were coming out with some freaky scenarios.
  5. Fixed another crash with ICS users when they first installed the app. According to android bug 35466, it looks like on ICS there is a tender spot when rendering text that has styling applied to sections of it and that section wraps around the edge of the screen. It's affecting a large number of apps out there, but it's part of the core, so we have to live with it. I've put in a fudge that should gracefully downgrade any styling that ICS dislikes.
What's next on the horizon..?

Well, Dolphin have their Garage API and I've finally managed to get a key to access it. We'll see what can be done - though it's a limited doorway between apps, so it might be a bit clunky and there's nothing I can do about that.

Also thinking about adding password syncing into the app. But there are lots of issues with a potential implementation - if anyone would like to help me thrash out some ideas of how this affects the end user, please contact me by email!

Laters.

Friday 10 August 2012

Cmarks!

So, some big changes to the app today.

Google changed their Play Store Policies recently. One of the changes was that apps must not impersonate other apps or system apps and that users should be not jump to the wrong conclusion and assume an app is officially supported by someone else by virtue of it's name, icon or content. Well, that's what I understand from the policy documents - to someone who isn't a lawyer, they might as well say: "look, just don't do this sort of thing or something that might be a bit like that".

So, vagueness aside, Google sent me a warning saying that my app violates someone's intellectual rights. Not too hard to guess that it's Google.

I'm assuming therefore that the icon and the name as for too "Chrome"y for Google's liking and things need to change.

So "CMarks" is here now. The logo was actually one of the runner-up logos when we had the online vote that found the previous chrome-y logo.

Unfortunately, Bug G doesn't provide any communication, so I can't be sure that the logo and name were the *only* things Big G doesn't like. For all I know, they might not like the idea of something other than their approved software syncing or touching their chromesync service.

So if the app disappears in the next week, it'll be because Big G has suspended the app and my developer account. In which case, it's been a fun ride and thanks for the fish!

Otherwise, if the app is still on the Play Store this time next week, we're probably good to stay! Whcih is good, as I've tons of stuff to add to it!

Sunday 5 August 2012

ChromeMarks update - 2012.08.05

Time for another update!

Firstly, I completed missed the fact that in the middle of June, ChromeMarks Lite reached 500,000 downloads. That's a phenomenal number and I never dreamed of getting so many downloads for a single app! Especially since that app has only been out there for less than two years. Thank you to everyone who's downloaded the app - still many more new features yet to come!

 The usual release notes are below:
  1. The FolderPicker has been completely revamped. The previous version was a custom built widget. It used a webview, so jquery and a lot of crunching via javascript to generate the content. Unfortunately that expects some quite tight coupling between the webview and my code. Looks like ICS devices seem to have some issues with this and a few users are reporting a blank white screen. The folder picker used to look like this:

    The new version now looks like this:

    The new widget no longer uses a WebView or any of the clunky javascript. Although it's still a custom built widget, it's using more of the "standard" components. Ok, it may not have as much colour to it, but it should be more compatible with all devices. It should also open quicker since it doesn't need the WebView overheads. Another bonus with the rewrite is that the folders are now shown in the same order as they are displayed in the rest of the app - so if you order by Chrome order, last modified or alphabetical - they should show the same in the FolderPicker.
  2. A short while ago, Google made some changes to the way they tag bookmarks in the chromesync service.This meant the tags I'd been using for the 2.x "copy stock bookmarks into a chrome folder" function had changed fundamentally. Previously, they'd been unique and this meant I could sync nicely between both browsers as I had a unique tag. However Google changed the value of the tag to become more of a transaction timestamp which meant that many bookmarks would now have the same tag. This really broke ChromeMarks when syncing as it kept getting the same tag back when it wasn't expecting it. Or actually, ChromeMarks didn't complain, but Google did when the changes were sent to them. And Big G's response - "Error 500".
    So some changes to ChromeMarks to change the tags being used. Unfortunately the bookmarks in the stock browser still have the non-unique tags on them which means that the next sync has to make some tough choices. You might find the first sync will generate some duplicates either in the Stock Browser and/or in the special folder in Chrome. This will be a one-off event as part of the first sync after this upgrade. After that, you can safely delete any duplicates - though obviously delete them from the Stock Browser OR from Chrome but NOT from both at the same time!
    I have already raised a Chrome bug about this. But since Google has made this change on their server and millions of people must already have the changed tags in their desktop already, it's highly unlikely that Google would ever revert it.
  3. Some of the usual bug fixes. The new auto-backup function used a piece of code that unfortunately didn't exist in the Android core on the 2.1 and some 2.2 devices. I've simply copied the code into my app and that should fix it.
That's about it for now.

First thing I've got on the list is some well overdue upgrades - sdk, compatibility library, admob, viewtitlepager. Unfortunately whenever I start making these upgrades, problems always take a while to fix...

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... :-)

    Monday 2 January 2012

    2011 / 2012

    Thought it was time for an update on some of the key points over the last year with regards to ChromeMarks and what's on the horizon this new year.

    2011's highlights.
    • In July, Google turned something off on the Chrome servers and the app started failing. 24 hours later, a fixed version was released. Honeycomb users are *still* waiting for their fix.. :-)
    • In Autumn, Chrome 14 arrived and with it's encryption, I had to frantically make updates to keep up with it as suddenly a load of people were being encrypted when they didn't even know about it (probably a bug in chrome enabled it for them).
    • Also during the autumn period, I was contacted by someone from Google who works on the syncing stuff. He let me know about impending changes. This was the first time anyone at Google has actually acknowledged the existence of this app and it was a very friendly exchange!
    • At the end of November, ICS was released with the fanfare that it can handle chrome bookmarks natively. However the number of purchases and users on ICS is steadily increasing. I've also had several mails from ICS users who can't get any bookmarks synced natively. Plus there are a couple of bugs raised on the android tracker from ICS users about this (hint: 23116, 22407)
    • In December, the lite app passed 250,000 downloads. It's been on the android market since 28th November '2010 - so in a year it has amassed this huge footprint.


    2012.

    The release of ICS gives me a new direction.

    Since *some* users can now enjoy native bookmark syncing and many devices will be upgraded over the coming year to ICS, I need to change direction and start adding new functionality that ICS doesn't yet do. This has previously been stuff that I wanted to avoid - I hate those apps that bloat out with lots of functionality you don't need or care about (hint, hint, Nero Burning Rom, hint, hint). If I start adding more stuff to this app then I could start suffering with similar bloat. So I have to be careful in what I pick.

    Below, I've listed - in no particular order - some of my hopes for the coming year. There's no guarantee they will all come to fruition, but I hope some will!

    Honeycomb/ICS local syncing.

    So Google released the source code for ICS near the end of the year. I was hoping to see the details of how they do the native sync (and see if I could supplementally fix some of it's issues and/or make mine better). However Google have implemented it within their closed source GoogleServicesFramework. This means the source is not available. And for ICS users with problems, this cannot be upgraded via the Market so requires a firmware upgrade to correct.

    If I can get the app to work with Honeycomb/ICS stock browser then that allows the users with broken native syncing to have a fallback. Plus, I'm guessing that since Honeycomb/ICS has folder support built in, then Samsung will hopefully stop tarting about with Android and leave it as it is and I can finally support Samsung devices properly.

    The number of 3.x and 4.x users is coming close to 10% of users for my full app. Ordinarily I wouldn't want to spend a large effort for something that 90% of users can't benefit from.

    But I've also got a 3.x tablet, so I'd like to play and get this working for my own benefit as well... :-)

    Password syncing.

    There are some big hurdles to overcome here first.
    1. The Android Browser won't allow me to pass in a password. Or more succinctly, the browser will accept requests to start browsing and will read off the url only. Any other info I send with it is ignored. So the first hurdle is that even if I did have the username and password for a site, I can't "fire up" a new browser window and either autofill or autologin the user. Once the browser receives the request to navigate to a new web page, it's running under a different userid on the device and I can not communicate with it either.
    2. Since number one above screws things up a lot, another thought I had was to simply fire up the web address in a webview internal to my app. So Chromemarks would effectively become a web browser. Since it would be running in my own app, I now have control to autofill the fields. However don't underestimate the amount of work this would entail! There would be no tabs - unless I built them. There would be no long click menu - until I built it. There would be no zoom - until I built it. The list goes on. Suffice to say that the stock Android browser is a load of code wrapped around a webview - it's basically the same thing that I would need. The standard Eclair browser has 13,117 lines of code in it. The ICS browser has 39,400 lines of code. So users would expect at least the most basic of functionality, which would be a large amount of extra code. Just for auto-filling and using your passwords. That would take months just to badly copy it from Eclair - is that worth my time?
    3. For a while now in Android (I think from honeycomb onwards?), if you navigate to a webpage and enter an id and password, sometimes the browser will ask if you want it to remember it. So I wondered if I could simply sync your chrome passwords into that same repository so your browser automagically has remembered a whole load of new passwords. Unfortunately the database that holds these passwords is kept internal to the WebView - it is not exposed for *any* kind of data access from any other app. So I can't mass import/export.
    4. Another option I'm thinking about is to cheat and use a bookmarklet. An intriguing post I spotted on StackOverflow mentioned that a bookmarklet could have access to the content:// schema where normally a browser has tight security over what content can be used in a page. If this is true, a bookmarklet could dynamically retrieve a script from my content provider and load it into the current page. The content provider would be able to receive the incoming url, search the database, find the username and password and return them in a custom bit of javascript. Back in the browser, that bit of javascript is invoked which fills in the appropriate username and password fields. It sounds so simple - I'll bet it isn't! But if it works, this option would allow you to keep using your stock browser (and possibly any other browser that can run a bookmarklet?)
    Real-time updates.

    Chrome has a constant connection back to Google. It uses XMPP to push/pull notifications quickly. It's possible I could retro-fit this for my app, but I think it would be problematic at best. So I was thinking about writing some kind of chrome extension that could use C2D to send a signal to your device to tell it to perform a sync. This wouldn't be exactly real time, but within a few seconds, which is good enough! But I'm not sure if there is a way in Chrome to get notification that something has changed. Plus, a chrome extension is a whole new world! I'm proud that this app requires no third party extensions or software at all, so I'm a bit conflicted already..

    Lite app.

    Since ICS brings native bookmark syncing, I'm already bracing myself for the comments on the Lite app ("what's the point of this when my device can do this anyway - 1 star", "Google already does this - 1 star", etc, etc). Since I'm relying on the income from the full app, I'm thinking that the Lite app will probably continue as it is but without much more new functionality.

    If I add new functionality in, then it will have to be stuff that ICS doesn't do to attract the users. And then I don't get the sales as the free app is doing it anyway. Sure I can move some of the advanced stuff to the full app, but it's starting to look tighter and tighter. And for those who whinge and say "just put ads in it", then you clearly aren't a normal developer. Yes if you built Angry birds then ads bring in a huge payback. But for normal developers, it's pathetic (hint: it wasn't even $100 for last month). Plus, the number of people out there who use Adfree or custom hosts files are increasing so the ad paybacks are always falling.

    Suffice to say that the majority of the development for next year will be in new features and functionality for the full app. Yes, bug fixes and routine maint will go into the Lite app. But the number of automated bug reports has reduced to a very slow trickle now.

    Chrome for Android

    I keep an eye on all commits for Chrome so I can see if anything regarding the syncing is being updated. I see the old commit for Android usage. Although it still looks like a very long way to go before a decent Android build is available, I still have to remember that once that arrives, this app will likely die shortly afterwards. There won't be much more that I can do that a native Chrome won't already do - and for free.

    But it's still a way off yet - I think they will probably have to go the same way as Fennec did recently: It tried to use the exact same codebase for the desktop version but the UI was slow, bloaty and intensely memory hungry. They changed to use native android widgets (instead of their xul), but it's a huge rewrite for a lot of code they never thought they would need to rewrite (as it's worked on all the previous operating systems Firefox has run on). I think Chrome will likely have to do similar - although I wouldn't put it past Google to implement some craftily helpful UI widgets in the next release of Android that Chrome could use very quickly and help get upto speed faster.

    Everything else already on the list

    • Scheduler for the backup functionality. Backup before a sync, after each sync, multiple backups, etc, etc. Maybe even different formats - are there any other browsers out there that might become compatible if I provide an export for them?
    • First start tutorial. A user mailed me recently to say he had never pressed the "sync" button as he didn't know what it would do - he'd always used the auto-sync to keep his bookmarks updated. I really do need a first start tutorial with some screen shots to hint to new users what they can do! I've already sketched them up, just need the time.
    • Search engine integration with the Android Search widget.
    • A bookmarks widget. Regular request, but again quite a hard one to actually do. I've recently had a play with writing a widget, so I've got some ideas. I thought I could pinch the stock android bookmarks widget from ICS (the only version that currently handles folders) and use my database instead. However that relies heavily on new features from Honeycomb and ICS so won't work in Gingerbread which is easily the most used version. Plus, native scrollable widgets aren't possible unless you are using Honeycomb or a third party launcher, which further complicates matters.

    That's it for now. Hope you have a happy new year!