services.md

Services

• Generate service static getInstance() method
• Light Services visualized in plugin.xml

Official Plugin SDK documentation: Light Services

Related JetBrains YT tickets:

• Devkit: Light Services inspection
• Class, that registered as extension, must be not registered as service or component

Generate service static getInstance() method

It is common practice, and is mentioned by the Retrieving a Service section as well, that a static getInstance() convenience method may be added to (light) service classes to wrap service retrieval logic.

This action is available from the Alt+Insert Generate menu when the following conditions are met:

• the class is not anonymous
• the class is not an enum
• the class doesn't have any static getInstance() method defined

The generation logic happens as follows:

• If Service.Level#PROJECT is specified, then project-level getter is generated.
• If Service.Level#APP is specified, then application-level getter is generated.
• If no Service.Level is specified but the class name ends with
  • ProjectService, ProjectSettings, or ProjectState, then project-level getter is generated,
  • ApplicationService, ApplicationSettings or ApplicationState, then application-level getter is generated.

In every other case, users can choose from a popup list the service level to generated the method for.

Project-level example...

From:

@Service(Service.Level.PROJECT)
public final class SomeService {
}

To:

@Service(Service.Level.PROJECT)
public final class SomeService {
  public static SomeService getInstance(Project project) {
      return project.getService(SomeService.class);
  }
}

Application-level example...

From:

@Service(Service.Level.APP)
public final class SomeService {
}

To:

@Service(Service.Level.APP)
public final class SomeService {
  public static SomeService getInstance() {
      return ApplicationManager.getApplication().getService(SomeService.class);
  }
}

Light Services visualized in plugin.xml

According to the Light Services Plugin SDK docs:

A service not going to be overridden does not need to be registered in plugin.xml... Instead, annotate service class with @Service.

Thus, light services may or may not be visible in the plugin.xml unlike the rest of the plugin components. This inlay hint aims to improve this situation by adding inlay hints to the starting tag of the <extensions> tag.

There are the following two display modes:

List of light services

In this mode, it shows the names of light service classes in the project - grouped by the service level, and limited to a user-defined max number of items.

Upon clicking on a class name, it navigates to the corresponding class definition.

The number of displayed class items can be configured in Settings > Editor > Inlay Hints > XML > Plugin light services, and allows a value between 1 and 50. Although displaying too many hints can be counter-productive, 50 as the max threshold provides enough flexibility for those who might need it (and who might wanna feel like a badass).

Note: the settings values are stored on application-level based on IntelliJ's default behaviour.

If the number of light services in the project is greater than the max number of items to display, an additional View all light services... hint is also added. Clicking on it, a popup list of all light service classes is displayed.

In this mode, hints are displayed for light service classes regardless of they are registered in plugin.xml or not.

(The examples are from one of my other plugins called Gherkin Overview).

View all

This mode shows only the View all light services... hint, which behaves the same as the hint with the same name in the previous display mode.

Notes

As for the popup list (see LightServicesHintPresentationAware):

• there is no speed search implemented yet,
• the popup height is not yet limited to make the list scrollable