Cytoscape Wiki|
← Revision 12 as of 2015-01-29 23:47:50
Size: 6619
Comment:
|
← Revision 13 as of 2015-01-30 23:11:36 →
Size: 912
Comment: reorganized this material around slide deck
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| This step is designed to introduce you to Cytoscape App Development concepts and technology. | This step is designed to introduce you to Cytoscape App Development concepts and technology, and to write a series of tutorial apps. ''This is a BIG step!'' |
| Line 6: | Line 6: |
| ---- |
== Process == We have prepared a series of slides that walkthrough all you need to know to write ''and fully understand the inner workings of'' some basic Cytoscape apps. If you've followed the Ladder up to this point, you can skip ahead to '''slide 13''' which begins with the concepts behind the first tutorial app you'll be writing, Step 1. Proceed to learn additional concepts and the implement them in each of Steps 2-6, incrementally making a more and more complex app. The slides conclude with an API Tour and some final tips. These are the same slides we use in our live app development training workshops! |
| Line 8: | Line 9: |
|
=== Cytoscape and OSGi === '''Cytoscape 3 design goals''': * Scalability * Performance * Stability * Application stability * API stability * Modularity (Enforced by OSGi) '''Definition of OSGi from Wikipedia:''' "The OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments. Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot; management of Java packages/ classes is specified in great detail. Application life cycle management (start, stop, install, etc.) is done via APIs that allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly." '''Important definitions:''' * OSGi is service-oriented * A '''bundle''' is the unit of access * Bundles can be started and stopped independently * Bundles implement services * Can be registered and unregistered * Generally, inter-bundle access is through a service * Enforced separation of API and Implementation – Rules are that you can depend on API bundles, but not implementation bundles ==== Anatomy of a Bundle ==== A bundle is a JAR with extra metadata: * Imports: The Java packages used by the bundle * Exports: Java packages in the bundle that other bundles are allowed to use (usually just API) * Activator: Triggered when bundle is started/stopped {{attachment:anatomyofabundle.png}} ---- === Cytoscape 3 Architecture === * Service-oriented microkernel * OSGi core * Dynamically loads and unloads modules, a.k.a. bundles * Each subsystem in Cy3 has separate OSGi bundle(s) * Apps can also be packaged as bundles {{attachment:cyarchitecture.png}} ==== Example: HelloWorld ==== * pom.xml! * Maven project descriptor * Maven identifier * Group id * Artifact id * Version * OSGi identifier * Bundle-!SymbolicName * Describes imports/ exports * Activator.java! - Bundle activator ==== Maven Project Layout ==== * pom.xml! * Project descriptor * src/main/java! - Bundle code * src/test/java! * Test code * Not included in bundle JAR * src/main/resources! - Non-code files that should be included in bundle JAR ==== Core Bundles ==== * app * application * command-executor * core-task * custom-graphics * datasource * equations * event * group * io * layout * model * presentation * property * service * session * swing-u/l * viewmodel * vizmap * vizmap-gui * webservice * work {{attachment:corebundles.png}} Core Bundles usually come in sets: * API (optional) - No activator * Implementation * At least one per API bundle * No exports * Separate API so we can keep implementation modular * Desktop application * Console application, for scripts * Nothing should import implementation bundles, unless it’s for unit testing Task bundles * work-api * work-swing-api * work-impl * work-swing-impl * work-headless-impl !VizMapper bundles * vizmap-api * vizmap-gui-api * vizmap-gui-core-impl * vizmap-gui-impl * vizmap-impl ==== OSGi Services ==== * Service: An instance of a Java interface * The glue behind API and implementation bundles * Usually registered by a !BundleActivator * In Cytoscape 3: * Defined by an API bundle * Registered by an implementation bundle * Interface: interface !MyService { ... }! * Implementation: class !MyServiceImpl implements !MyService { ... }! * Properties: (“title”, “My Service”)! (“preferredMenu”, “Apps”)! * Arbitrary key-value pairs ---- === Cytoscape API === Available as OSGi services. Two main types: * API: Applica/on Programming Interface * Just fetch and use: MyService service = getService(context, MyService.class);! * SPI: Service Provider Interface * Implement/extend and register: registerService(context, new !MyServiceImpl(),!MyService.class, properties);! ==== OSGi Services ==== Most common types of services: * Factories: Create new instances * Managers: Track, provide access to, or operate on collections of objects * Utilities: Collections of utility functions ---- === Cytoscape TaskFactories === TO-DO: Insert graphic for Tasks '''!TaskFactories:''' * Main unit of work in Cytoscape is a “Task” * Tasks are created by !TaskFactories {{attachment:tasks.png}} * !TaskFactories are OSGi services * Can be registered in your !CyActivator: !TaskFactory factory = registerService(bc, myFactory, !TaskFactory.class, properties); where myFactory is the task factory you want to register * properties provide meta-data about the factory * Java Properties '''Cytoscape !TaskFactory Properties:''' * Properties have special meaning in Cytoscape * Defined in org.cytoscape.work.!ServiceProperties * Key properties * TITLE – If used as a menu, this is the menu title * PREFERRED_MENU – Where this will be added * ENABLE_FOR – When this menu is active * IN_TOOL_BAR – is it in the tool bar? * IN_MENU_BAR – is it in the top-level menus? * MENU_GRAVITY – The specific gravity of this item. ==== Example ==== import org.cytoscape.work.!AbstractTaskFactory; import org.cytoscape.work.!TaskIterator; class !MyTaskFactory extends !AbstractTaskFactory { public !MyTaskFactory() { super(); } public !TaskIterator !createTaskIterator() { return null; // Fill in } public boolean isReady() { return true; } } '''in !CyActivator''' !MyTaskFactory myFactory = new !MyTaskFactory(); Properties props= new Properties(); // Note the “.” notation for cascading menus props.setProperty(PREFERRED_MENU, "Apps.cddApp"); props.setProperty(TITLE, "Load CDD Domains for Node"); // Not all task factories will be commands props.setProperty(COMMAND, "loadCDDDomains4node"); props.setProperty(COMMAND_NAMESPACE, "cddApp"); props.setProperty(IN_MENU_BAR, "true"); // Usually means the second menu item props.setProperty(MENU_GRAVITY, "2.0"); registerService(bc, loadCDDDomainNodeView, !NodeViewTaskFactory.class, nodeViewProps); |
http://www.cgl.ucsf.edu/home/scooter/Cytoscape3DevTut/slides.pdf |
Introduction to Cytoscape App Development
Overview
This step is designed to introduce you to Cytoscape App Development concepts and technology, and to write a series of tutorial apps. This is a BIG step!
Process
We have prepared a series of slides that walkthrough all you need to know to write and fully understand the inner workings of some basic Cytoscape apps. If you've followed the Ladder up to this point, you can skip ahead to slide 13 which begins with the concepts behind the first tutorial app you'll be writing, Step 1. Proceed to learn additional concepts and the implement them in each of Steps 2-6, incrementally making a more and more complex app. The slides conclude with an API Tour and some final tips. These are the same slides we use in our live app development training workshops!
http://www.cgl.ucsf.edu/home/scooter/Cytoscape3DevTut/slides.pdf