- Direct Known Subclasses:
public abstract class SynchronizationContext extends PlatformObject implements ISynchronizationContextAbstract implementation of the
ISynchronizationContextinterface. This class can be subclassed by clients.
- See Also:
All Methods Instance Methods Concrete Methods Modifier and Type Method Description
dispose()Dispose of the synchronization context and the cache of the context.
getCache()Return the cache associated with this synchronization context.
getDiffTree()Return a tree that contains
IDiffentries for resources that are out-of-sync.
getScope()Return the input that defined the scope of this synchronization context.
getScopeManager()Return the scope manager for the scope of this context.
getType()Return the synchronization type.
refresh(ResourceMapping mappings, IProgressMonitor monitor)Refresh the portion of the context related to the given resource mappings.
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
protected SynchronizationContext(ISynchronizationScopeManager manager, int type, IResourceDiffTree diffTree)Create a synchronization context.
manager- the manager that defines the scope of the synchronization
type- the type of synchronization (ONE_WAY or TWO_WAY)
diffTree- the sync info tree that contains all out-of-sync resources
public ISynchronizationScope getScope()Return the input that defined the scope of this synchronization context. The input determines the set of resources to which the context applies. Changes in the input may result in changes to the sync-info available in the tree of this context.
public ISynchronizationScopeManager getScopeManager()Return the scope manager for the scope of this context.
- the scope manager for the scope of this context
public int getType()Return the synchronization type. A type of
TWO_WAYindicates that the synchronization information associated with the context will also be two-way
IDiffinstances (i.e. there is only a remote but no base involved in the comparison used to determine the synchronization state of resources. A type of
THREE_WAYindicates that the synchronization information will be three-way
public void dispose()Dispose of the synchronization context and the cache of the context. This method should be invoked by clients when the context is no longer needed.
public ICache getCache()Return the cache associated with this synchronization context. The cache is maintained for the lifetime of this context and is disposed when the the context is disposed. It can be used by clients to cache model state related to the context so that it can be maintained for the life of the operation to which the context applies.
public IResourceDiffTree getDiffTree()Return a tree that contains
IDiffentries for resources that are out-of-sync. The tree will contain entries for any out-of-sync resources that are within the scope of this context. The tree may include entries for additional resources, which should be ignored by the client. Clients can test for inclusion using the method
IResourceDiffTreewill be homogeneous and contain either
IThreeWayDiffcontained in the returned tree will contain
IResourceDiffinstances as the local and remote changes. This interface also has several helper methods for handling entries contained in the returned diff tree.
public void refresh(ResourceMapping mappings, IProgressMonitor monitor) throws CoreExceptionRefresh the portion of the context related to the given resource mappings. The provided mappings must be within the scope of this context. Refreshing mappings may result in additional resources being added to the scope of this context. If new resources are included in the scope, a property change event will be fired from the scope. If the synchronization state of any of the resources covered by the mapping change, a change event will be fired from the diff tree of this context.
Changes to the diff tree may be triggered by a call to this method or by a refresh triggered by some other source. Hence, the callback from the diff tree to report changes may occur in the same thread as the refresh or asynchronously in a separate thread, regardless of who triggered the refresh.