Buxfer has a few interesting features that differentiate it from the others. While it offers auto-syncing of transaction information with your banks and credit cards, budgeting, and expense analysis, Buxfer also has three key characteristics:
Shared Finances - Buxfer allows you to create groups and assign specific finances to those groups to monitor who owes or receives money. For example, you could create a “Cable Bill” group and assign yourself and your roommates to the group to track who has forked over the cash for the Super Deluxe Sports Package.
Google Gears - By using Buxfer’s Google Gears support, you can keep all of your private financial data on your own computer, instead of Buxfer’s servers. The other personal finance sites store your information on their servers, thus out of your control.
Mobile Access - Buxfer has a mobile phone interface and an iPhone-specific interface for accessing your account remotely. You can also use Twitter or SMS to get account balances or to be notified of low balances, large withdrawals, etc.
Buxfer uses a perverted Prototype, and looks fairly Gmail-y with the top right red ‘Loading…’ and such. It looks nice.
Over on my personal blog I kicked off a series of articles on some future APIs that are on the table for Gears, and how in my opinion, Gears is mistakenly seen to be about "offline", when that is just the surface.
I started off by discussing the Image Manipulation API, "is a module to give Javascript a way to resize, crop and compose images together on the client side. This will allow, for example, images to be resized into a web-friendly format before being uploaded to a photo album. Another use is for composition of images together as an efficient alternative to server-side composition or CSS layering. Yet another use is for basic photo editing - a user can edit a photo with instantly applied changes before uploading it to the server."
The Location API provides a means to fetch the location of a device running a Web browser with Gears:
The Location API is an abstraction for the various LBS APIs that currently exist on mobile platforms (GPS-based, network/cellid-based). The API consists of the Location class, which encapsulates various location attributes (latitude, longitude, etc), and also provides the means to query the platform for a location fix. This API also adds a new event type that is fired every time the location changes. Location implementations can be straightforward mappings to native LBS APIs (e.g the S60 Location Acquisition API) or have a more complex design that combines several location providers (e.g a GPS-based provider and a cell id-based provider) and returns the location from the most accurate provider at any given time.
To finish off we have the issue of developer tools. We need to make sure developers have the tools they need to enable successful app development using the APIs, so we want to first add:
Database
List databases per origin
Create new
Delete
Interactive DB command line (can just use existing /sdk/tools/dbquery.html)
LocalServer
List ResourceStores (and ManagedResourceStores) per origin
ResourceStore and ManagedResourceStore status (last error, update history, etc)
command line (like db command line, but pointed at localserver DBs)
I had the pleasure of finally meeting Didier Girard. I seem to run across Didier's work every week or so, but for some reason we haven't had a chance to meet face to face, until JavaPolis.
Zoho Writer was quick to release offline support using Gears, which allows you to carry read-only views of your data around when you were offline.
This was just the first step in their offline support, and now they have announced the next step. This new version allows you to edit on the road with a synchronization system that keeps you sane:
Working on the Gears team we also run across applications that we would love to take offline. A lot of these applications aren't Google's so we thought it would be nice to be able to take third party apps offline. This also makes sense since Aaron Boodman (Mr. Greasemonkey) is co-tech lead on Gears itself!
Ben Lisbakken has written up his work taking Gears and Greasemonkey to make this happen. He details the real example of taking Wikipedia offline which has once piece of narly code to do with iframe injection to be able to store data on third party sites (e.g. media site vs. wikipedia main site):
Initialize Gears on page
Check if site has been allowed, if not, trigger allow dialog
Insert iFrame
Initialize Gears on iFrame
Check if site has been allowed, if not, trigger allow dialog
If Gears is initialized on both, insert Cache Page link (unless page is cached)
When user clicks Cache Page:
Capture the HTML and CSS of the Main Page
Store the URLs of all links to HTML, CSS, and media files in the Gears database (so we can remove them from the ResourceStore later, if needed)
Create an iFrame whose src is in the domain of upload.wikimedia.org. Pass all media file URLs to the iFrame in the src URL after the hash, e.g. src="http://upload.wikimedia.org/#thisimgloc.jpg||anotherimgloc.jpg||lastimgloc.jpg"
Initialize Gears in iFrame
Capture all URLs from the iFrame's href hash.
When user clicks [x] to remove an article from cache:
Grab all URLs from the Gears database that correspond to that article
Remove all URLs from the ResourceStore of the Main Page that contain the string "en.wikipedia.org"
Remove all URLs from the Gears database that correspond to that article
Create an iFrame whose src is in the domain of upload.wikimedia.org. Pass all media file URLs to the iFrame in the src URL after the hash, e.g. src="http://upload.wikimedia.org/#thisimgloc.jpg||anotherimgloc.jpg||lastimgloc.jpg||remove||"
Initialize Gears in iFrame
Remove all URLs from the ResourceStore that are listed in the iFrame's href hash.
Here's the script in action as I save pages away. This is just the beginning. Ideally we would have the code automatically save content that you have been too, and do smart spidering to get more on the subject too. We will also work on making GearsMonkey scripts even easier to write.
The tool itself is a nice Ruby on Rails application (includes pink fade effects! yellow is so 2006) that gives you a visual canvas to play with your mind.
Their approach to offline is similar to Google Reader in that the user has to say "hey, take me offline". The interface to that is a nice little slider widget. At the point your maps are sync'd down to the local store.
I would love to see it auto sync, and I noticed a couple of issues when I actually went offline but didn't tell the tool first (would be nice to have the tool grok that) but the mind map tool in general is a nice app to use. It feels like Geni.
Julien Lecomte has written up the pattern where you use setTimeout() to keep yielding control back to the main thread so that it can handle browser events.
function doSomething (progressFn [, additional arguments]){
// Initialize a few things here...
(function(){
// Do a little bit of work here...
if(continuation condition){
// Inform the application of the progress
progressFn(value, total);
// Process next chunk
setTimeout(arguments.callee, 0);
}
})();
}
Of course, the Gears Workerpool does this the right way, giving you the ability to pass messages to another process to get the work done in a secure sandbox.
As a band-aid it could be nice to have an abstraction library that uses WorkerPool if Gears is installed, if not, try to use setTimeout (which is harder to do as you need to cut up the work differently).
The major note here is that the current draft HTML 5 spec has the SQL API as an asynchronous one, whereas Gears has a synchronous API. In my experience, people prefer synchronous here, and Adobe AIR has a new synchronous API that they just released with the latest beta. I would love to see the HTML 5 spec contain a synchronous version too.
A tool that takes your upcoming Calendar entries and creates blog posts of the events
A code snippet that you can add to your website that enables visitors to your site to click on a link to comment on your content on their own blog
Code that allows you to search blogs on various topics, find entries, and again allow users to comment on their own blog
And finally, Blog.gears, an offline blog editor:
I tend to write a fair share of blog posts, and whenever I am writing them while offline I tend to open up Textmate to do the write-up. Wouldn't it be nice if I could open up my blog editor and do it all while I am offline?
The architecture behind the editor follows the pattern of:
The UI looks to the local DB for data
When an event happens it gets queued
When an event happens the UI tries to send it to the cloud
Events have status flags to let the system know what is happening
We interviewed Pamela Fox about the application, and she went through the architecture at a high level, and also did a screencast of the application itself.
Eric Abouaf has released Gears in Motion, a tool that allows you to quickly and easily look at your local SQLite database, and make edits on the fly.
You can make schema changes, data chances, and see the entire flow of relationships. It even groks URLs so if you put a JPG in the database, it will just show it to you as you look at the data.
Brian Dunnington liked what he saw with the Dojo Offline Toolkit, and wanted to abstract it out so you could use functionality with any JavaScript library.
He ended up with a new library called Vortex, a 10k JavaScript file that features:
Ability to automatically detect referenced resources such as images, scripts, and stylesheets (including nested @imported stylesheets)
Automatic detection of network state with corresponding UI/feature changes (also implements .isOnline() and .isOffline() methods)
Auto syncing of events. it essentially records any user-defined actions and automatically plays them back when the network comes back online
A generic storage provider to quickly and easily save javascript objects (JSON-encoded)
Graceful fallback if no offline support is available (google gears not installed or not allowed to run)
Library-independent (does not require dojo, prototype, Ext, YUI, etc) and cross-browser compatible
He has a simple RSS demo that shows the library at work.
I took it for a spin and went online and offline to see how it automatically detects. Also in the video below I take a peek at the code and we see what the definition of "online" means (able to XHR a particular file).
Brian Shaler noticed that almost a year ago, Digg removed the "search your own
Diggs" feature, to the dismay of thousands of Digg users. To explain
why the feature had not yet returned, they cited hardware and software
solutions as being very complicated and expensive.
Brian decided to re-implement the feature himself using the Digg APIs, and we end up with The Digg Oracle:
Because the dataset is relatively small and user-specific, performing
tasks like searching/filtering and sorting can easily be done on the
client, using Google Gears. The tool downloads the selected user's
entire voting history, indexes the stories in the local DB, then does
all the sorting/searching without connecting to Digg's servers.
Here we see an original query, and the application starts to download the users usage data:
When the data is loaded, searching and filtering the data is extremely fast, even if you use Kevin Rose as your sample :) This is a great non-offline example of using the database and workerpool components.
Eric Farrar of Sybase iAnywhere has been developing a prototype that allows direct database-to-database synchronization of a Gears application to Oracle, SQL Server, DB2 and Sybase databases. We asked Eric about his work and he told us:
At Sybase iAnywhere we provide a data sync infrastructure for mobile and remote apps. The Background Sync architecture mentioned on the Gears site is a lot like mobile application architectures we see all the time. As a result, it seems as though the same mobile sync technology can be used to solve the offline sync problem for Google Gears.
This prototype uses a local lightweight database (based on the iAnywhere UltraLite database) with built-in synchronization
capabilities, meaning:
Built in change tracking, so that changes (including deletes and updates) can be sent to the server,
Built in state tracking, so that the local database knows when synchronizations succeed and can take appropriate clean-up operations automatically,
Built in synchronization over TCP/IP or HTTP.
Optional encryption of the data store and of the sync stream
Somewhat stricter data management model than SQLite.
The other piece is the sync server that manages synchronization to Oracle, SQL Server, IBM DB2 and Sybase databases. The sync technology is fully transactional, meaning data does not get partially changed at either end. It also has automatic mechanisms to detect conflicts and hooks that allow users to programmatically handle the conflicts using SQL, .NET, or Java.
As far as scalability, these technologies are currently being used in projects that involve nearly half a million mobile devices.
Eric also recorded some videos show this all in action:
The article moves past an introduction to delve into the design decisions around an offline-capable architecture, and user messaging and presentation of state. We learn why Omar decided to go with the explicit offline mode, and then the five steps to offline conversion:
Ensuring resources are available offline
Decoupling the application from the network
Persisting data on the client
Re-creating application state from persisted data
Developing a synchronization strategy.
There is a lot to learn here.
From their architecture considerations:
RTM was designed as a client-side application from inception. The server-side portion of RTM is mainly used as a "dumb" data store, and the application periodically synchronizes with the server. In this case, using Gears to provide offline access was a natural fit, and was relatively quick to implement as we had some prior experience with data synchronization protocols.
There were some features of the online experience that could not be carried over to the offline mode. One of these was the Google Maps integration, in which users can geolocate their tasks and quickly visualize where their tasks are occurring in the real world. As Google Maps requires access to Google servers to fetch map tiles and data, and such a data set is quite large and thus hard to cache, this functionality is disabled once the user enters offline mode.
The undo feature of RTM is also unavailable in the offline version as this is a complex server-side operation (due to the multi-user nature of RTM and the ability to share tasks and lists). Instead, the user is presented with a dialog box asking for confirmation if they execute a destructive action such as delete. Undo functionality in offline mode is on the RTM roadmap, however.
To the decisions they made on showing the user information on whether they are online or offline:
A fundamental design decision is whether to implement offline support as "modal" or "modeless." Choosing which style to implement will, in most cases, be dictated by the type of data the application works with and how much of that data will be available offline. One style is not necessarily superior to the other, and, for example, it's much easier to implement a modeless style for tasks (in RTM) than it is for feed items (in Google Reader) based on the size of data items and the total data set alone.
Finally, we learn some tips and caveats from the RTM Gears implementation, including dealing with the LocalServer, the different types of offline, defensive coding, debugging, and coding with upgrades in mind.
Omar Kilani wraps it up in his conclusion:
By now, you should be itching to add offline support to your web application (we hope!). If you should take anything away from this article, it's that taking your application offline isn't as hard or complex as it may first seem, and that Gears is a joy to work with (and it'll become even easier and more fun as the project matures and is used by more applications).
As for us at RTM, we couldn't be happier with Gears. The speed at which we were able to provide offline functionality (four days from reading the documentation to a launchable implementation) is a testament to the quality, ease of use, and production-readiness of Gears. Many thanks to the Google Gears engineers for their foresight and for making this an open source project to which members of the Internet community can contribute.
Thanks to the Remember The Milk team for taking their application offline in record speed, and for taking the time to share their experience.
Junction is an all JavaScript framework that closely models the Ruby on Rails model-view-controller design pattern and implementation. And with the help of the Helma JavaScript web server, it runs the same code both on the client and on the server. Exactly the same code, in fact.
The framework not only handles the basics of rendering pages (using JavaScript templating), but it also handles data and code synchronization with the server, local client caching using Google Gears, model versioning, and much more. It's an amazingly complete solution for an entirely new model of web development.
The article walks through the building of a very simple contact management system, and shows that ONLamp doesn't believe in Long Pages ;)
The Gears team has rev'd a new version aimed at developers. This release isn't going to propagate to end-user machines yet, as we want to time to hear from the community on the new features and APIs. Speaking of which...
Until now, there was no way to talk past the strict same-origin security model (same protocol, same exact domain, same port). Sometimes in the real world you need to mashup data, or even talk from www.foo.com to static.foo.com. Now you can do this with a simple API that adds to WorkerPool:
Workers live in their own world (by design) but what if you need a worker to grab some content. You don't have access to XHR, but now you can use the new HttpRequest module that mimics XHR with a couple of differences.
The Timer module implements the WhatWG Timer specification, and makes it available in both workers and the main HTML page. This is the same timer API that is traditionally available in browsers on the window object.
, Prototype
