Welcome to the Receiver Plug-in SDK
Use this SDK to develop your Receiver for Windows integrated plug-ins.
Summary of Receiver Integration
There are 3 levels of integration: Ideally full integration will be achieved but consider which of these is most appropriate for your plug-in
- Install: metadata is prepared that describes the install process and install time configuration for the plug-in to Receiver. See the Metadata Files section for more details.
- Registration: when the plug-in executes, it Registers its presence with Receiver and keeps basic state up to date.
- Full GUI Orchestration: the plug-in devolves the control of its systray menu and user notifications to Receiver.
Registration - Check for Receiver Environment
The plug-in needs to check whether Receiver is active and able to provide SDK services. If Receiver is not present, a plug-in should work standalone as before. To detect Receiver, the ARRegister() function is used. The return value from this function will indicate whether Receiver is active in which case the plug-in should use the remaining functions to pass activities on. If Receiver is not active then the plug-in should function as before. The ARRegister() function can be passed callbacks that help monitor ongoing Receiver state but there are also ancilliary functions to help this; Checks for Receiver being installed, running & whether a plug-in is already registered. Once registered, a plug-in should keep Receiver updated on any changes in its state via the ARUpdateStatus() call. See the Registration API section for more details.
User Notifications
The Receiver User Experience module tries to bring consistency to the feedback a user will receive from the plug-ins. To that end, Receiver provides a series of Notification functions for the plug-ins to call. See the Notifications API section for more details. Note: It is not expected that Receiver will draw the complex controls required for say Property Pages & plug-ins should continue to draw these as before.
Systray Menu Integration
In general Receiver will own the only systray (notification area) menu that the user will use to interact with the plug-ins. The exception to this is where a plug-in mostly operates as an application rather than a piece of infrastructure (an example of this is the Citrix Communications plug-in). In this case, where a user may drive that application via the systray menu, the plug-in should maintain its own systray identity (though it can also have a presence within the Receiver environment for more advanced functions if this seems appropriate).
Non-App plug-ins will devolve their menu entries to Receiver via the Client SDK. The active Receiver User Experience modules will determine how to present that menu functionality to the users. As a general rule Receiver will choose to take functionality that an average user would not use unless talking to the helpdesk and relocate it away from immediate systray menu access. The plug-in team should examine their menu entries and consider carefully what is relevant for the ordinary user before marking it for display. It is also useful to consider that such menu entries will be displayed out of context to the plug-in and it may be useful to reword them to be more generally descriptive. For example: 'Disconnect' on a Secure Access plug-in menu may make sense in context but if exposed by itself on an Receiver menu, rewording to something like 'Release Secure Connection' may be more appropriate (and wouldn't be out of place in the original menu). Some menu entries may be only suitable for Advanced users. From Receiver 1.1, these entries can be marked for optional inclusion on the systray menu, with the actual visibility controlled by user or administrative configuration.
See the Systray API Integration section for more details.
