DSDP/MTJ/Discussion/New APIs/post 1.0/DeviceManagement

SDK Categories

The proposal on the table will result in two different categories of SDK's and associated devices. The categories are:

• Manual Device Importer
• SDK-provided Devices

Manual Device Importer

This category is the original mechanism provided by EclipseME and MTJ 1.0. Some properties of this mechanism:

• Import must be launched explicitly by the user.
• Devices are implicitly persisted by the DeviceRegistry
• The current device importer extension point remains the same

SDK Provider

This category is the newly proposed functionality. Some properties of this mechanism:

• Devices need not be explicitly imported or managed by the user.
• Devices are managed and persisted (as necessary) by the SDK provider
• DeviceRegistry provides a facade for access of the SDK provider devices, but otherwise does not manage those devices.

User Interaction

Device Management Dialog

The device management dialog will be altered to provide finer-grained control over what is visible to the user. Because devices may be managed implicitly by SDK providers, the user must be allowed to “hide” devices from view. This is done via the device management dialog. In this mock-up, the available SDK's and associated devices are shown in the tree. Devices that have a check mark will be visible for use in the rest of MTJ. The device shown with the “*” is the current default device. (Would it be better to use Bold and/or italic text for the current default?)

Because certain devices are implicitly managed by SDK providers, certain operations may not be enabled for all devices. For example, Edit, Duplicate and Delete are all operations which may be disabled for SDK provider devices.

Manual Device Installation

For devices that are based on the device importer extension point, the device import operation is renamed Manual Install. The device import dialog is similarly renamed, but otherwise remains the same in functionality as current MTJ.

Implementation Notes

The following are some ideas related to the implementation.

SDK Provider Extension Point

The following extension point would be added to MTJ.

<?xml version='1.0' encoding='UTF-8'?> <schema targetNamespace="org.eclipse.mtj.core" xmlns="http://www.w3.org/2001/XMLSchema">

<annotation>

     <appInfo>
        <meta.schema plugin="org.eclipse.mtj.core" id="sdkprovider" name="SDK Provider"/>
     </appInfo>
     <documentation>
        Extensions of this extension point provide instances of the class org.eclipse.mtj.sdk.ISDKProvider interface.  These providers are queried by the system for their org.eclipse.mtj.sdk.ISDK instances.  ISDK instances provide access to IDevice instances.
     </documentation>
  </annotation>
  <element name="extension">
     <annotation>
        <appInfo>
           <meta.element />
        </appInfo>
     </annotation>
     <complexType>
        <attribute name="point" type="string" use="required">
           <annotation>
              <documentation>                  
              </documentation>
           </annotation>
        </attribute>
        <attribute name="id" type="string">
           <annotation>
              <documentation>                  
              </documentation>
           </annotation>
        </attribute>
        <attribute name="name" type="string">
           <annotation>
              <documentation>                  
              </documentation>
              <appInfo>
                 <meta.attribute translatable="true"/>
              </appInfo>
           </annotation>
        </attribute>
     </complexType>
  </element>
  <element name="sdkProvider">
     <complexType>
        <attribute name="id" type="string" use="required">
           <annotation>
              <documentation>
                 a required fully-qualified identifier for this particular device importer extension
              </documentation>
           </annotation>
        </attribute>
        <attribute name="name" type="string">
           <annotation>
              <documentation>
                 an optional displayable name for this particular device importer extension
              </documentation>
           </annotation>
        </attribute>
        <attribute name="class" type="string" use="required">
           <annotation>
              <documentation>
                 the required implementation class for the <code>org.eclipse.mtj.core.sdk.ISDKProvider</code> interface
              </documentation>
              <appInfo>
                 <meta.attribute kind="java" basedOn=":org.eclipse.mtj.core.sdk.ISDKProvider"/>
              </appInfo>
           </annotation>
        </attribute>
     </complexType>
  </element>
  <annotation>
     <appInfo>
        <meta.section type="since"/>
     </appInfo>
     <documentation>
        1.0
     </documentation>
  </annotation>
  <annotation>
     <appInfo>
        <meta.section type="examples"/>
     </appInfo>
     <documentation>
        [Enter extension point usage example here.]
     </documentation>
  </annotation>
  <annotation>
     <appInfo>
        <meta.section type="apiinfo"/>
     </appInfo>
     <documentation>
        [Enter API information here.]
     </documentation>
  </annotation>
  <annotation>
     <appInfo>
        <meta.section type="implementation"/>
     </appInfo>
     <documentation>
        [Enter information about supplied implementation of this extension point.]
     </documentation>
  </annotation>

</schema>

New ManagedDevice Interface

SDK providers will likely need more control over the devices that they provide to the DeviceRegistry. A new IManagedDevice interface should be introduced as a subclass of the IDevice interface. This interface would provide the following new methods:

• boolean allowsDelete()

Whether the SDK allows this device to be deleted.

• boolean allowsDuplicate()

Whether the SDK allows this device to be duplicated.

• boolean allowsEdit()

Whether the SDK allows this device to be edited.

• boolean delete()

The device is being deleted. Returns a boolean indicating whether the deletion was successful.

• IManagedDevice duplicate()

Duplicate the managed device and return the new instance.

• void edit()

Edit the specified device. Does this make sense? The edit function is going to be in the UI somewhere rather than in the core.

DeviceRegistry

The DeviceRegistry class is the central location from which available devices are discovered. For manually installed devices, the DeviceRegistry will continue to provide persistence for those devices. For auto-installed devices from SDK providers, the DeviceRegistry will query those providers for available SDK's and devices as necessary. The DeviceRegistry will not provide persistence for auto-installed devices. It is assumed that SDK providers will provide any necessary persistence. In certain cases, it may be unnecessary for an SDK provider to do any persistence and we should stay out of this. The DeviceRegistry will implement the getAllDevices method by querying all SDK providers for available devices and adding those devices to those that have been manually installed by the user. From an external perspective, the DeviceRegistry provides a view into all available devices in the system. Note: We may need to consider a callback method to allow the SDK provider to signal that the managed devices have changed.