I was lucky enough to attend the Progressive Web App Summit hosted by Google at the Theatre Amsterdam with two of my SitePen Colleagues. I was blown away by the quality of the talks, the speakers, the content and of course the venue and hospitality.
Progressive Web Applications take advantage of new technologies to bring the best of mobile sites and native applications to users. They are instant loading, offline capable, installable, secure, responsive and addable to the home screen. More information is available on the Progressive Web Apps website.
Modern browsers have powerful new database capabilities that enable applications to store data locally, and perform advanced indexed queries without a network connection. Applications can be built with offline support without any disruption to data interaction, including searching. However, these database capabilities have traditionally been difficult to use across browsers since Safari only supports WebSQL (although version 8 is slated to include IndexedDB support), and Firefox and Internet Explorer only support the W3C’s IndexedDB API (Chrome supports both). And these two interfaces couldn’t be more different, making it very problematic to write applications that work offline on all the major browsers.
But, it is now much easier to access these database capabilities. By taking advantage of the consistency of the Dojo object store implementation, in version Dojo toolkit version 1.10,
dojox/store now includes object store implementations for IndexedDB and WebSQL, along with a wrapper that will automatically delegate to the appropriate store implementation based on browser support. With a single common interface, you can retrieve, update, add, and delete objects, and even perform sophisticated queries in exactly the same way with the different underlying storage implementations.
It was recently reported that Google Dumps Gears for HTML5. If true, with the investment Google has made in HTML5, Chrome, Chrome OS, and Chrome Frame, this is not surprising, but it does leave a potential short-term gap for offline application development.
In their post, Read-Write Web asks if offline access is even necessary any longer. I guess they don’t spend enough time on airplanes or at hotels and conferences with poor internet connectivity! It’s certainly necessary, and while other browsers have developed significant offline capabilities, older browsers still need a plug-in like Gears.
In the interim, what should you do if you want an offline application? Do you develop for Gears and HTML 5 features? Do you wait for Chrome Frame to integrate offline capabilities? Do you use a toolkit like Dojo which will wrap the various possibilities? Or do you rely on something else like AIR, Titanium, Prism, or Fluid? The answer really depends on your application. If it is live now, you plan for the future but you keep going with Gears and/or Dojo Offline. If you won’t be launching for some time, you may want to talk to us about your offline app options.
At the end of the day, Gears is open source. If there’s a long-term need for its existence, the community can pick it up and run with it! Thankfully end-of-life isn’t the certain death-knell that it is with closed-source software.
Dojo is a very flexible toolkit; it doesn’t dictate how you organize your code or create your widgets. It simply provides tools, and it’s up to you to decide how you want to fit them together. Developing with AIR puts you squarely in the browser-based application model, but aside from that it mostly stays out of your way as well. As part of our series on the Queued development process, I’m going to take a look at the decisions we made and the philosophies we adopted for the project. It should provide some insight into our process.
SitePen’s new Queued application works very well with the Netflix API, but the smoothness of this functionality was the result of a lot of research, and trial and error. In fact, this experience led me to propose that future project timelines should budget extra time when working with an unfamiliar API—and even more time when that API is brand new and untested. Netflix released one of the more exciting APIs in recent months and SitePen began to work with it right away. The Netflix team did great work on their API and they were also very helpful with us when we had questions or there was a bug on their end. I can imagine the challenges of setting up a (Netflix) REST API with an existing system and a large and complex library of items was not simple. Integration with the Netflix API presented its own set of challenges to us.
Sometimes building an application from scratch is easier than building on an already existing interaction model. For Queued, our goal was to take the Netflix user experience and port it to a lightweight desktop application, while adding some modest enhancements.
Creating an alternate interface for an already well-known web site carries some unique responsibilities. First, unless there is something seriously wrong with the original site, straying too far from the established model can be counterproductive. Second, innovating on existing features becomes more important than replacing them. And third, adding new interface functionality without obstructing existing interactions remains a crucial consideration.
For the Queued project, SitePen faced the additional challenge of showing off features of Adobe AIR that might not necessarily lead to the most fluid interaction, but which were powerful enough to merit inclusion as a demonstration of AIR’s powerful capabilities. We’ll discuss a few of our interaction changes here, though these aren’t the only modifications that we decided to implement.
Last month, we announced Queued, an open-source application for managing your Netflix Queue. Queued is a desktop application created with web technologies and techniques including the Dojo Toolkit, and it is distributed as an Adobe AIR application to provide several performance boosting benefits from living on the desktop.
At SitePen, we help our clients build great web applications. Most are not available for public consumption as they live behind company firewalls and/or require licensing. On the other hand, Queued is free and open-source software, BSD-licensed, and hosted on Google Code.
The AIR platform defines distinct sandboxes for trusted and untrusted code, and provides a way to talk securely between each sandbox via sandbox “bridges”. This is a lynch-pin in the web-meets-desktop strategy that AIR embodies, but it can also present some of the trickier development challenges, with plenty of head-banging opportunity. I’ll share a few tips to help you avoid those head/keyboard collisions.
There was a lot of activity in the Dojo Toolkit community this week, including an update for Dojo Storage plus articles on productivity and writing DRYer code.
Mobile application development has many challenges. The announcement of Google Gears on Mobile Devices will help solve the problems of network connectivity, network latency, and limited bandwidth. On the desktop, a lot of the focus on Gears was its ability to allow applications to function when your computer was not connected to the network. In addition to building mobile web apps here at SitePen, we released Dojo Offline, which integrates the Dojo Toolkit with Gears to make building disconnected web applications even easier. As we all know, mobile devices lose connectivity with the network on a regular basis. Gears’ ability to keep the data that users need stored on the phone will be key to keeping mobile applications running even when networks fail to keep phones connected.