Hi, everybody, I’m Scott. I lead the Cooliris engineering group. Many of us have been thinking lately that since there’s so much cool stuff going on at Cooliris that it’s a shame that we haven’t spent much time on the blog talking about what we’re up to on the technology side of things. This blog series aims to give you a sneak peek into some of the neat projects we’re working on.
As we mentioned previously, we’ve been working very hard to streamline the way we build the sorts of beautiful, fluid application experiences that you’ve come to expect out of Cooliris. I want to kick off this blog series by sharing some of the challenges that we have encountered during the course of application construction, and what we’re doing with the Cooliris Platform to resolve those difficulties.
For starters, we at Cooliris write applications targeting two broad categories of platform experiences that exist today: 1) web applications that run in any standards-compliant web browser, and 2) native applications that directly target various OSes with tailored user experiences (Windows, Mac, iOS, Android, etc.).
With the ongoing growth in deployment and adoption of HTML5 and related technologies, the web is becoming increasingly attractive to us and others as the target platform for developing application experiences due to the speed and simplicity of the programming model, but boundary-pushing experiences such as the Cooliris wall demand performance and capabilities that only native platforms provide. And while it’s true that the web platform is currently undergoing revolutionary advancements toward matching the native development experience, native platforms such as iOS and Android, at least for now, are still innovating out in front of the rate of web standardization. (Rule of thumb: web standards usually aren’t very useful for application developers until the standard and at least two compatible implementations have shipped–which takes time.)
The bottom line is that there are good reasons to target both the web and native platforms, at least for the foreseeable future. Despite the differences between the two development models, most contemporary applications, whether web or native, share several important architectural features: 1) one or more cloud-based sources of data, 2) a network client stack, 3) control logic that drives the behavior of the application given input from the user and from the network, and 4) a user interface layer that presents data and enables user interaction.
Most of the details of each of the four layers are nearly identitcal across all platforms. Unfortunately, aside from the cloud data source (which is usually implemented using an entirely separate platform), the various application platforms each come with vastly differing implementation requirements at each layer. For example, in a web browser you might use an XMLHttpRequest for network requests, write your control logic in Javascript, and build your user interface in HTML5 or possibly WebGL. On the other hand, in iOS for example, you would use NSURLRequest for network requests, write your control logic in Objective-C, and build your user interface using the Cocoa Touch framework.
In each of these examples, the platform forces your adoption of its particular well-designed and tightly integrated stack of technologies. This gives companies like Cooliris very little choice but to hire an array of developers specialized in the technologies required for each full stack.
The Cooliris Platform was designed to address these development pains. Its primary goals are: 1) to blend the ease of web development with the power of native application development, 2) to build in a straightforward migration path for our applications to run directly in-browser as web browsers become increasingly capable, and 3) to consolidate the implementations at each of the aforementioned layers across each platform that an application wishes to target.
In my next post, we’ll dig in and begin to discuss what we’re doing at each of the four layers to address these goals.
Don’t hesitate to leave us comments below if you have feedback or questions about what we’re thinking about here, or if you have things that you’d like us to expand on in future articles.
