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!