Java Reference
In-Depth Information
SwingUtils.invokeAndWait(new Runnable() {
public void run() {
...
}
});
}
@Unbind
public void unbindShape(SimpleShape shape, Map attrs) {
final String name = (String) attrs.get(SimpleShape.NAME_PROPERTY);
DefaultShape delegate = null;
synchronized (m_shapes) {
delegate = (DefaultShape) m_shapes.remove(name);
}
}
Here you declare the paint frame's binding methods. Because the paint frame
depends on all available shape services, you use the
aggregate
annotation attribute to
inform the i
POJO
framework. At execution time, i
POJO
injects all discovered shape
services into the component. The service properties of injected services are also
needed to get the service name and icon, so you use the binding method signature
that includes the service properties.
Bind/unbind method pairs
Conceptually, a bind method is paired with an unbind method. You aren't technically
required to have both, but if you do, iPOJO treats them as a logical pair. What does
this mean exactly? In the previous examples, when you use an attribute (for example,
filter
or
aggregate
) on
@Bind
, you don't repeat it on
@Unbind
. This is because
iPOJO creates a union of attributes out of paired bind/unbind methods, so it isn't nec-
essary to repeat the attributes. If you do repeat attributes, they must have the same
value, or iPOJO complains.
iPOJO automatically infers bind and unbind pairs based on method names. If the
method name starts with
bind
or
unbind
, the remaining part of the method name is
used as an identifier to match pairs. For example, iPOJO determines that
bindFoo()
and
unbindFoo()
are a matched pair with an identifier of
Foo
. Sometimes it isn't
possible to name your methods following the bind/unbind naming convention: for ex-
ample, if you're dealing with legacy or third-party components. In these cases, you
can use the
id
annotation attribute to explicitly specify the pair's identifier. For iden-
tifiers, you should repeat the
id
attribute in both the
@Bind
and
@Unbind
annotations
so iPOJO can correctly pair them.
All the component frameworks we've covered provide mechanisms to simplify the task
of accessing
OSG
i services; but accessing services is only one part of the challenge.
Another issue is dealing with the dynamic nature of services. If services can come and
go at any point, you must code a service consumer defensively. Doing so involves one
or more of the following patterns:
