Create unified interfaces across dart:io and dart:html

Dart runs on the client, thanks to dart:html, and on the command line, thanks to dart:io. However, like oil and water, those two libraries just don't mix. Your web apps can't use dart:io, and your server apps can't use dart:html. Normally, this isn't a problem, because the two different targets are oh so very different. However, some concepts are common, such as Web sockets or HTTP requests. Wouldn't it be nice to have a unified interface to Web sockets that works with either dart:io or dart:html? I'll spare you the suspense: Yes!

This post shows you one strategy to design a high-level interface for functionality that exists in both dart:io and dart:html. While the Dart team has the concept of configurability on their radar, not much concrete action has happened. In the meantime, try this strategy and you too can experiment with unifying interfaces and APIs. Code reuse FTW!

(This post was inspired by Mark Bennett's original question who is trying to build a more unified Web Socket interface.)

Step 1: Create a library and an interface

Design the interface that unifies something from dart:html and dart:io.

library shared; abstract class BaseFoo { common(); }

Step 2: Implement the interface for dart:html

In another library, implement the interface with dart:html:

library html_thing; import 'dart:html'; import 'shared_interface.dart'; class Foo extends BaseFoo { common() { print('from html'); } }

Step 3: Implement the interface for dart:io

In another library, implement the interface with dart:io.

library io_thing; import 'dart:io'; import 'shared_interface.dart'; class Foo extends BaseFoo { common() { print('from io'); } }

Step 4: Package it up

All of the previous code can go into the same pub package.

Pick a library to use

The consumer of your pub package must decide which library to import. For example, a dart:io app might look like this:

import 'dart:io'; import 'package:sharedinterfacetest/io_version.dart'; main() { var foo = new Foo(); foo.common(); }

Hope that helps! All the code for this example is found at Github.
Post a Comment

Popular posts from this blog

  • Sponsor:  Register today for  New Game, the conference for HTML5 game developers . Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco.  Register now ! This is the second article in a Box2D series, following the Box2D Orientation article. The Box2DWeb port of Box2D contains a nice example to show off the basics of integrating physics simulations into your web app. This post will provide a walkthrough of the example, explaining the high level concepts and code. First, let's see the example in action. The code for the above is open source and available on GitHub. It was adapted from Box2DWeb's example . Animating Before we look at Box2D, it's important to understand how the above simulation is animated. You might think setInterval or setTimeout is
    Keep reading
  • In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F
    Keep reading
  • Angular and Polymer, sitting in a DOM tree, B-i-n-d-i-n-g. First comes components, Then comes elements, Then comes the interop with the node dot bind. Angular , a super heroic MVC framework, and Polymer , polyfills and enhancements for custom elements built on top of Web Components, can live harmoniously in the same app. This post shows you how to connect Angular-controlled components to Polymer-controlled elements via data binding. And we do it all in Dart . Angular and Polymer I get asked "Should I use Angular or Polymer?" a lot. My answer is, "Yes". That is, both libraries have distinct strengths, and you can use both in the same app. Polymer excels at creating encapsulated custom elements. You can use those custom elements in any web app or web page, regardless if that app is built with Angular, Ember, etc. Angular excels at application engineering, with dependency injection, end-to-end testability, routing, and services. Here are som
    Keep reading