Tips on Porting your Code to 3.0

Networks, Nodes, Edges

• Most methods in the old CyNetwork should have corresponding methods in the new CyNetwork.

• The new CyNetwork is found in the org.cytoscape.model package.

• The getIdentifier() methods are gone. While there is a getSUID() method, this is not necessarily a replacement. The getIdentifier() was frequently used for accessing attributes, which you now do through the attrs() or getCyRow(ns) methods.

• Likewise, the concept of a rootGraphIndex is also gone. Again, while there is a getIndex() method, this is not necessarily a replacement. In general, you should probably be using CyNode or CyEdge references instead of integers. You should only resort to getIndex() if you really need to keep an array of nodes and need an index into it.

• Node names, selected state, and other methods that used to exist are now columns in the default CyDataTable.

Attributes

• CyAttrbibutes has been replaces by the concept of CyDataTable.

• Instead of just one, global CyAttributes object, each network has a collection of CyDataTables: for the network, for the nodes, and for the edges.

• For network, nodes, and edges, instead of just one CyDataTable each, we now provide a Map of CyDataTables. The key to the map is a String, or the namespace. For almost all core work, the namespace is defined as CyNetwork.DEFAULT_ATTRS.

• Whereas you used to get an "attribute" using the attribute name, now you get a CyRow in the CyDataTable with a column name. Column name is effectively the same as attribute name.

• To access a row you can call getCyRow(namespace) to get a CyRow object and then call the get(columnName,classType) method.

• The get method includes a Class argument to simplify the interface.

• Since developers will frequently need to get the CyRow for a GraphObject with the default namespace, we've provided a convenience method called attrs(). attrs() is the same as calling getCyRow(CyNetwork.DEFAULT_ATTRS).

• To get the "attribute" named attributeName of a node:

  • Old: CyAttributes.getNodeAttibutes().getStringAttribute(node.getIdentifier(), attributeName);

  • New: node.attrs().get(attributeName,String.class));

Views

• CyNetworkView replaces CyNetworkView.

• View<CyNode> replaces NodeView.

• View<CyEdge> replaces EdgeView.

• Instead of networkView.getNetwork() or getGraphPerspective(), use networkView.getSource().

• A view no longer contains its VisualStyle. The VisualMappingManager keeps track of this instead.

• VisualMappingMangaer is a service.

Misc

• CytoscapeInit is gone. If you need to get a properties object, then get the service CyProperty<Properties> injected into your constructor.

• Read the javadocs of Task and TaskMontior for a good explanation of how those methods change. Essentially, just rethrow any exceptions that get caught (you don't need to set the exception any more) and only use the status messages for status (e.g. load file... creating network... etc.).

• Cytoscape.java is gone. Most methods have been moved into singleton services elsewhere.

  • getCurrentNetwork() and getCurrentNetworkView() are now part of the CyNetworkManager interface.

Spring

• The Spring config files is where all object initialization occurs.
• There are two spring config files:

  • src/main/resources/META-INF/spring/bundle-context.xml

    • This file constructs all "beans" (objects) for this bundle.
    • This file uses references created in bundle-context-osgi.xml to outside services.
    • This file instantiates the "beans" (objects) that are then used to declare services for other bundles to use.

  • src/main/resources/META-INF/spring/bundle-context-osgi.xml

    • This file connects this bundle to the OSGi world which means two things:
    • it creates references that can be used by this bundle from Services provided by other bundles
    • it declares services itself.

• The rule is to keep bundle-context.xml free of any OSGi semantics so that it can be used in a normal spring context and then put all OSGi related XML in bundle-context-osgi.xml.

OSGi

• OSGi impacts the design of Cytoscape, but its APIs are totally hidden through the use of Spring-DM. You should never reference OSGi APIs in your java code. This should all be handled in the Spring XML config files.

• The central concept in OSGi to be aware of is that of a Service.

  • A Service is defined by a java interface. Any valid java interface can be a service.

  • An implementation of this service is simply and implementation of its interface.
  • Access to the service is provided through a service registry.

  • In practice, however, this is all handled by Spring. You do not need to worry about the service registry in your java code!

• From the perspective of the Java developer, a Service is provided in one of two ways:
  1. As an argument to your object's constructor (i.e. it is injected).

  2. Mulitple instances of a service can also be injected into methods in a class. You simply define two methods, an add and a remove method with a signature that includes the interface and a Map of properties:

     • addService( MyServiceInterface s, Map props );

     • removeService( MyServiceInterface s, Map props );

     • These are normal methods in all respects.
     • The Spring xml is configured so that these methods get called when new services are registered or when old services are removed.