All of the Studio Apps provided by CoreMedia (the Content App, Workflow App and Campaign App) are singleton apps. There is always only one instance of an app running in a browser window. However, the framework also provides support for multi-instance apps where an app can run in multiple instances in multiple browser windows in parallel.

A straightforward utility are so called launch handlers for apps and their shortcuts. The mechanism follows the Launch Handler API. A launch handler controls how an app is launched, for example if it uses an existing window or creates a new one. The default is the singleton mode that the built-in apps use: Only if an app is not yet running, a new window is opened. Otherwise, the existing window is focused. But it is possible to add a launch handler for the app itself or for one of its shortcuts in the app manifest. These launch handlers are currently taken into account for the studioApps._.runApp() method and the RunAppEntry#run() methods for entries returned from studioApps._.observeRunAppSections().

For example, this entry at the top level of the My-Edited-Contents App manifest would open a new instance of the app each time the app is run with one of the two methods.

launch_handler: {
  client_mode: "navigate-new"
}

A more sophisticated utility to support multi-instance apps is using entries in the cmServices list of the app manifest with regular expressions. Suppose a multi-instance app is to offer a MultiInstanceService but that service is different from instance to instance, in this example depending on an id parameter of the service descriptor. In that case, the cmService entry can look like this:

{
  name: "multiInstanceService",
  id: {
    type: "RegExp",
    value: ".*",
  },
}

The id parameter is dynamic. Because the Service Agent API can also deal with regular expressions in service descriptors, the Studio Apps framework can set up a dynamic service runner for this service. So for example, another app requests this service in the usual way:

getServiceAgent().getService({name: "multiInstanceService", id: 123}).fetch()

Initially no app is running that offers this service with this id. But because of the manifest entry from above, it is a "runnable" service and the concrete id "123" matches the regular expression ".*". Consequently, the app is launched in a new browser window. This app can now set up the service with this exact id because it can access the requested service via studioApps._.getAppStartupParameters() and StartupParameters#requestedServiceDescriptors.

If the same service request from above (with id "123") is made again, the app is already running and can just be focused. But if the service is requested with a different id, a new instance of the app is launched.