As part of our series on how we built Queued, today we’re going to talk about theming the Queued application, and touch on a few examples of what made putting the skin on Queued so much fun.
The foundation for the beautiful theme for Queued was laid down by colleagues Damon Dimmick and Torrey Rice, and their amazing wireframe and mockup work (respectively) provided the building blocks for laying down Queued’s skin.
SitePen is excited to announce Stocker, which demonstrates some of the more advanced capabilities of Dojo, including the newly released DataChart, the DataGrid, Data Store, Comet, Persevere, and BorderContainer. SitePen is also offering a one-day workshop where you will learn how to create Stocker yourself, but I’m here to give you a sneak peak of what Stocker is and how it works.
Stocker uses these technologies to emulate a stock monitoring application. We’re using made up data, but that’s actually more interesting. The Persevere server generates new stock items at certain intervals, and then pushes them to the browser with Comet. Then the Data Store updates its items and triggers an
onSet notification. The DataGrid and DataChart are both connected to the same store, and are listening to that event. They then update their displays and show the stock items and their latest data.
At SitePen, we work very hard to to provide our customers and fellow developers with useful web app development services. We’re currently deconstructing the development of Queued, our Netflix Queue management application built with Dojo and Adobe AIR. Having presented on dojo.deferred and related topics at the Ajax Experience, and having heard that the Queued team ran into a few problems with them, I thought it would be interesting to review problems that are sometimes encountered when using Deferreds. What is the source of these problems, are these problems related to bugs or because there are misunderstandings, and how should we address this going forward?
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.
The latest addition in the Dojo 1.3 release is the new dojox.charting class, DataChart. Its primary purpose is to make connecting a chart to a Data Store a simple process. There are also other benefits with DataChart: less parameters are needed to create a basic chart, and more defaults and convenience methods get you up and running quickly with Dojox Charting.
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.
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.
dojox.rpc.Client was introduced in Dojo Toolkit version 1.2, providing extra request headers on XMLHttpRequests to facilitate implementing deterministic request handling on servers. Browsers typically use two or more TCP connections to send HTTP requests to a server, while subsequent requests are often routed on separate TCP connections. This means there is no guarantee that the request that is sent first will arrive at the server first. With sophisticated web applications, non-determinism can lead to bugs that are very difficult to track down.
If a web application sends multiple requests to a server and assumes that the server will handle them in the order they were sent, this non-determinism can be problematic. Furthermore, messages that arrive out of order can be rare, and therefore problems can be hard to reproduce. On old modem connections, packets were sequenced over a slow PPP connection that made out of order messages almost non-existent. With modern broadband connections, the race becomes more interesting. HTTP pipelining adds another mechanism that can lead to messages arriving out of order and with browsers beginning to support and use pipelining, messages arriving out of order will become even more likely in the future.
Dijit has a tremendous wealth of high quality and feature-rich form elements providing key functionality including validation, time calculation, spinner controls, calendars, and much more. Furthermore, Dijit gives you a set of themes to choose from: Tundra, Soria, Noir, and Nihilo.