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.

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.

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.

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!

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!

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

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!