Presence Scenarios: Best Practices
Below are some best practices to use when creating applications using Unified Communications.
After signing in, immediately publish device
Publishing a device category instance immediately after signing in allows other client applications to know about the device’s communication capabilities. Client applications can then enable or disable communication features such as text message, voice, and video. For more information, see the Device section in OC Presence: Category Instances.
If your device has Office Communicator running on it, the device is already published by Office Communicator. If you try to republish it, an error is thrown on publication. You only need to publish the device category instance if you are running your custom application on a device that does not have Office Communicator running.
To publish a device instance, use a category instance ID that is unique to the device. You only need to publish the device to the Aggregation 1 container (ID = 2). This, in turn, publishes to containers Public, Company, Team, and Personal (IDs 100, 200, 300, and 400 respectively.)
To subscribe to your own publication of the device instance, use the Aggregation 1 container (ID = 2).
Publish machine state when publishing anything else
Office Communicator monitors activity and publishes machine states indicating user activity. However, if you are running your application on a device that does not have Office Communicator running on it, your application is responsible for publishing these states. A good practice is that whenever an application publishes a category instance, it also publishes a machine state indicating that the device that is doing the publishing is active. This information is used by the Aggregation script when determining availability. You should first subscribe to the device category instance and store the instance that you receive from the category instance added event. Then, to publish the machine state, follow these steps:
How to publish a machine state
Create a category instance with a category name of state.
Take the device categories instance’s ID and use the
System.Security.Cryptography.MD5CryptoServiceProvider.ComputerHashmethod to convert it to a byte array.
Set the category instance ID to 0x30000000 |
hash30is the 30 least significant bits of the byte array above.
Set the expiration type to device.
Set the Availability property or attribute to 3500 (to indicate active).
Publish to containers 2 and 3 (both Aggregate containers).
Establish publication rules for levels of access and follow them consistently
Unified Communications gives you the ability to publish whatever categories to whatever containers you want so that it is theoretically possible to publish different information to the Public, Company, Team, and Personal containers. For example, you can choose to publish a different note to each of these access levels. However, in general, this is not a good practice. Subscribers can be members of several containers, and it is too easy to get into a situation where a subscriber is not receiving the category instance that you intended and it is difficult to debug why that is happening.
A better practice is to decide for each category instance what level of the container you want to be able to see that information and then to publish one instance to that container and instances with the same information to those with higher container IDs. For the notes example, you choose a container level to which you want to have notes published (for example, 300 and higher, which covers Team and Personal, but not Company and Public), and then publish the same note to the Team and Personal containers, but not publish any note to the Company and Public containers. This simplifies your code so that you do not need to keep track of which note is published to which container.