Lync SDK 2013. Rethinking the experience of developing your own Lync-based instant messenger (Skype for Business)
We continue to make products based on (and for) Skype for Business. This is not an easy task - you have to face many obstacles that need to be creatively overcome. Today I will talk about how the development of one of our most recent applications was going on, where the idea came from and what technological problems we solved.
In our company, Lync server and Skype for Business clients are used as corporate communications for employee communication. They have their advantages and disadvantages (for example, problems with the preservation of the history of correspondence), but today is not about that.
We already had the idea of ​​creating a native client based on the Lync SDK , which would completely replace the Skype for Business client. We spent a lot of time and effort, created our own messenger, which covers all inconveniences and complements the functionality of Lync, but several ShowStoppers could not be overcome. Also, optimism did not add a considerable number of bugs in the Lync SDK itself.
')
The main thing that we got in the process of creating our own client is a great experience in using technology and knowledge, which are, in fact, unique. Therefore, we decided not to stop and create several separate applications for Skype for Business, each of which should solve only one large task, unlike the previous project, which was an “all in one” application.
So two ideas were born - this is an application for managing contacts, which will be discussed in this article, and an application for saving message history, which we will tell about separately.
The application was developed using the .NET Framework 4.6.1 technology, Unity Framework, Prism.
One of the flaws in the development of the previous application was the use of the Lync SDK throughout the code, which greatly hindered the introduction of new features and modularity of the application. Therefore, the main conclusion that we made is independence from third-party decisions. All integration dependencies must be abstracted, and our solution should use abstractions instead of specific libraries and frameworks.
If you look at the component diagram of the architectural solution, you can distinguish three groups of components.
- Third-party components that do not belong to us (Lync Client SDK);
- service components that implement the logic of connecting and decoupling layers (MSConnector, IConnector, CommonDTO, AppModel);
- application components, which are client applications.
If everything is more or less clear with the first and third groups, then the second should be discussed in more detail.
AppModel - domain model. It is a pure object model that describes a given domain. Its main feature is that it does not contain any links to third-party libraries (for example, Lync and Outlook).
For communication with the underlying level, the model uses the IConnector interface, which closes the concrete implementation and all the draft work on the connection with transport and service libraries. This interface is conveniently regarded as common, - during development it was divided into functional parts (ICommunication, ICalendar, ITask, etc.)
One of the options for implementing this interface is the MSConnector , which is able to communicate to the Lync Client SDK and Outlook, as well as to handle requests coming within the interface.
In order for the model and the connector to support effective interaction, the CommonDTO component is selected in the system, which describes all the common classes necessary for data exchange.
Client applications interact with the domain model directly, calling its objects and subscribing to its events. In fact, in this architecture, the model is a caching proxy for external services.
Thus, we provided a solution to the application from Lync (Skype for Business) and Outlook, and came to the conclusion that within the framework of this architecture, we can potentially switch to other services. For example, use Telegram or regular Skype as a messenger and Google Apps as an email application and calendar.
Based on this solution, we created a layer library between Lync and our application and started developing the client side itself.
The essence of the application lies in the advanced management of your Lync contacts. Of the main features are the following:
• creating contacts (single or multiple);
• creating groups;
• Search by Lync and Outlook Address Book;
• view your own calendar.
In addition, each contact has an extended list of features:
• Opening a dialogue with a contact (with the possibility of sending short messages);
• Call to Lync, to any phone from the contact phone list, video call;
• View contact calendar;
• Notifications about changes in contact status to “Online” with memorization of the message;
• Changing the default action when you click on a contact (call, video call, or open chat);
• Sending an e-mail with an empty or predefined header;
• Planning a meeting with a contact;
• Search all emails from the contact;
• View contact card (with the display of the entire calendar of the user).
Additional features of the application include:
• Drag & Drop contacts between groups from the search box;
• Scaling contacts of all groups at once, and groups of contacts separately;
• Adding shortcuts to files or applications on the program's taskbar;
• Change your own status in Skype for Business.
It was decided that the application should be distributed in two forms - a regular installer (exe or msi, through the site) and through the Microsoft store as an appx package.
Having the experience of converting classic applications to the appx package on the past application, in this case we went the same way, but moved much faster.
The only thing that we added compared to the publication of the previous application - it is multilingual. Now the application is available to users in three languages ​​- Russian, English and German. To see the list of languages ​​supported by the application in the Microsoft store, you need to fix AppxManifest.xml a bit, in our case it looks like this:
As a result, we have now received, as well as the contact management application itself, which does not repeat the functionality of Lync, but expands it and works with it in pairs, as well as a set of necessary libraries for the “quick” implementation of our further ideas.
I would appreciate feedback in the comments, grateful for the ideas.
Vyacheslav Nesterov
Idea
In our company, Lync server and Skype for Business clients are used as corporate communications for employee communication. They have their advantages and disadvantages (for example, problems with the preservation of the history of correspondence), but today is not about that.
We already had the idea of ​​creating a native client based on the Lync SDK , which would completely replace the Skype for Business client. We spent a lot of time and effort, created our own messenger, which covers all inconveniences and complements the functionality of Lync, but several ShowStoppers could not be overcome. Also, optimism did not add a considerable number of bugs in the Lync SDK itself.
')
The main thing that we got in the process of creating our own client is a great experience in using technology and knowledge, which are, in fact, unique. Therefore, we decided not to stop and create several separate applications for Skype for Business, each of which should solve only one large task, unlike the previous project, which was an “all in one” application.
So two ideas were born - this is an application for managing contacts, which will be discussed in this article, and an application for saving message history, which we will tell about separately.
Technology stack, architecture, development
The application was developed using the .NET Framework 4.6.1 technology, Unity Framework, Prism.
One of the flaws in the development of the previous application was the use of the Lync SDK throughout the code, which greatly hindered the introduction of new features and modularity of the application. Therefore, the main conclusion that we made is independence from third-party decisions. All integration dependencies must be abstracted, and our solution should use abstractions instead of specific libraries and frameworks.
If you look at the component diagram of the architectural solution, you can distinguish three groups of components.
- Third-party components that do not belong to us (Lync Client SDK);
- service components that implement the logic of connecting and decoupling layers (MSConnector, IConnector, CommonDTO, AppModel);
- application components, which are client applications.
If everything is more or less clear with the first and third groups, then the second should be discussed in more detail.
AppModel - domain model. It is a pure object model that describes a given domain. Its main feature is that it does not contain any links to third-party libraries (for example, Lync and Outlook).
For communication with the underlying level, the model uses the IConnector interface, which closes the concrete implementation and all the draft work on the connection with transport and service libraries. This interface is conveniently regarded as common, - during development it was divided into functional parts (ICommunication, ICalendar, ITask, etc.)
One of the options for implementing this interface is the MSConnector , which is able to communicate to the Lync Client SDK and Outlook, as well as to handle requests coming within the interface.
In order for the model and the connector to support effective interaction, the CommonDTO component is selected in the system, which describes all the common classes necessary for data exchange.
Client applications interact with the domain model directly, calling its objects and subscribing to its events. In fact, in this architecture, the model is a caching proxy for external services.
Thus, we provided a solution to the application from Lync (Skype for Business) and Outlook, and came to the conclusion that within the framework of this architecture, we can potentially switch to other services. For example, use Telegram or regular Skype as a messenger and Google Apps as an email application and calendar.
Based on this solution, we created a layer library between Lync and our application and started developing the client side itself.
The essence of the application lies in the advanced management of your Lync contacts. Of the main features are the following:
• creating contacts (single or multiple);
• creating groups;
• Search by Lync and Outlook Address Book;
• view your own calendar.
In addition, each contact has an extended list of features:
• Opening a dialogue with a contact (with the possibility of sending short messages);
• Call to Lync, to any phone from the contact phone list, video call;
• View contact calendar;
• Notifications about changes in contact status to “Online” with memorization of the message;
• Changing the default action when you click on a contact (call, video call, or open chat);
• Sending an e-mail with an empty or predefined header;
• Planning a meeting with a contact;
• Search all emails from the contact;
• View contact card (with the display of the entire calendar of the user).
Additional features of the application include:
• Drag & Drop contacts between groups from the search box;
• Scaling contacts of all groups at once, and groups of contacts separately;
• Adding shortcuts to files or applications on the program's taskbar;
• Change your own status in Skype for Business.
Windows Store Publishing
It was decided that the application should be distributed in two forms - a regular installer (exe or msi, through the site) and through the Microsoft store as an appx package.
Having the experience of converting classic applications to the appx package on the past application, in this case we went the same way, but moved much faster.
The only thing that we added compared to the publication of the previous application - it is multilingual. Now the application is available to users in three languages ​​- Russian, English and German. To see the list of languages ​​supported by the application in the Microsoft store, you need to fix AppxManifest.xml a bit, in our case it looks like this:
<Resources> <Resource Language="de-DE" /> <Resource Language="ru-RU" /> <Resource Language="en-us" /> <Resource uap:Scale="100" /> <Resource uap:Scale="125" /> <Resource uap:Scale="150" /> <Resource uap:Scale="200" /> <Resource uap:Scale="400" /> </Resources> Conclusion
As a result, we have now received, as well as the contact management application itself, which does not repeat the functionality of Lync, but expands it and works with it in pairs, as well as a set of necessary libraries for the “quick” implementation of our further ideas.
I would appreciate feedback in the comments, grateful for the ideas.
Vyacheslav Nesterov
Source: https://habr.com/ru/post/326732/
All Articles