Does Dart support enumerations?

Beginning 1.8, you can use enums like this:

enum Fruit {
  apple, banana
}

main() {
  var a = Fruit.apple;
  switch (a) {
    case Fruit.apple:
      print('it is an apple');
      break;
  }

  // get all the values of the enums
  for (List<Fruit> value in Fruit.values) {
    print(value);
  }

  // get the second value
  print(Fruit.values[1]);
}

The old approach before 1.8:

class Fruit {
  static const APPLE = const Fruit._(0);
  static const BANANA = const Fruit._(1);

  static get values => [APPLE, BANANA];

  final int value;

  const Fruit._(this.value);
}

Those static constants within the class are compile time constants, and this class can now be used in, for example, switch statements:

var a = Fruit.APPLE;
switch (a) {
  case Fruit.APPLE:
    print('Yes!');
    break;
}

With r41815 Dart got native Enum support see http://dartbug.com/21416 and can be used like

enum Status {
  none,
  running,
  stopped,
  paused
}

void main() {
  print(Status.values);
  Status.values.forEach((v) => print('value: $v, index: ${v.index}'));
  print('running: ${Status.running}, ${Status.running.index}');
  print('running index: ${Status.values[1]}');
}

[Status.none, Status.running, Status.stopped, Status.paused]
value: Status.none, index: 0
value: Status.running, index: 1
value: Status.stopped, index: 2
value: Status.paused, index: 3
running: Status.running, 1
running index: Status.running

A limitation is that it is not possibly to set custom values for an enum item, they are automatically numbered.

More details at in this draft https://www.dartlang.org/docs/spec/EnumsTC52draft.pdf

Enumeration should be available in the future. But until Enum has landed you can do something like :

class Fruit {
  static final APPLE = new Fruit._();
  static final BANANA = new Fruit._();

  static get values => [APPLE, BANANA];

  Fruit._();
}

This and this may be the answers on your question:

... for the technology preview it was decided to leave it out and just 
use static final fields for now. It may be added later.

You can still do something like this:

interface ConnectionState { }
class Connected implements ConnectionState { }
class Connecting implements ConnectionState { }
class Disconnected implements ConnectionState { }

//later
ConnectionState connectionState;
if (connectionState is Connecting) { ... }

wich is in my opinion more clear for use. It's a bit more difficult for programming the application structure, but in some cases, it's better and clear.