Time for action – injecting subtypes

Although creating a POJO can be an efficient way of creating simple classes, it can be limiting to have a concrete class definition scattered through the class definitions. It is a better design to use either an abstract class or an interface as the service type.

  1. Create a new interface in the com.packtpub.e4.application package, called IStringService. Define the process method as abstract:
    public interface IStringService {
  public abstract String process(String string);
}
  2. Modify the existing StringService so that it implements the IStringService interface:
    public class StringService implements IStringService {
  ...
}
  3. Modify the reference in the Rainbow class to refer to the IStringService interface instead of the StringService class:
    @Inject
private IStringService stringService;
  4. Run the application, switch to the Rainbow tab, and a dependency injection fault will be shown in the host Eclipse instance's Console view:
    org.eclipse.e4.core.di.InjectionException:
  Unable to process "Rainbow.stringService":
   no actual value was found for the argument "IStringService".
  5. Although the runtime knows that the StringService is a @Creatable instance, it doesn't look for subtypes of an interface by default. To inject an alternative type, modify the Activator and add a binding as follows:
    public class Activator implements BundleActivator {
  public void start(BundleContext bundleContext) throws Exception {
    Activator.context = bundleContext;
    InjectorFactory.getDefault().
     addBinding(IStringService.class).
      implementedBy(StringService.class);
  }
}
  6. Run the application and the part should be created correctly.

What just happened?

Using an interface for the service type is best practice, since it further decouples the use of the service with its implementation. In order for the dependency injection framework to provide an instance of an abstract type (whether an interface or abstract class, or even a concrete class without a @Creatable annotation), a binding needs to be created for the injector.

The binding just created tells the InjectorFactory to create an instance of StringService when an IStringService is required.

Have a go hero – using the tools bridge

Although Eclipse 3.x parts can run in an Eclipse 4 IDE, to take advantage of the E4 model, the code has to be implemented as a POJO such that it can be registered with a model. To fit an E4 POJO into an Eclipse 3.x IDE, the E4 bridge has to be used. Install the Eclipse E4 Tools Bridge for 3.x from the E4 update site, which provides the compatibility views.

Now create a class called HelloView which extends DIViewPart<Hello> and passes the instance of the Hello class to the super-class' constructor. Register the HelloView in the plugin.xml as would be the case with Eclipse 3.x views, and the part is now visible either as a standalone part in Eclipse 4 or as a wrapped view in Eclipse 3.x.

Pop quiz – understanding E4

Q1. What is the application model and what is it used for?

Q2. What is the difference between a part and a view?

Q3. Are extension points still used in Eclipse 4?

Q4. What is the Eclipse 4 context?

Q5. What annotations are used by Eclipse 4, and what is their purpose?

Q6. How can messages be sent and received on the event bus?

Q7. How is the selection accessed in Eclipse 4?

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.223.107.149