Development of Metro-application Evernote for Windows 8
About a year ago we started working on Evernote for Windows Phone 7 . Then our first priority was to get our SDK using C # to work with Silverlight to access the Evernote API. Our API is built on Apache Thrift , and the Thrift code generator for C # uses a synchronous HTTP stack on .NET. Silverlight, meanwhile, only supports an asynchronous network model. Therefore, Damian Meyers, our main client developer for Windows Phone 7, had some time to think about how to make it all work. As a result, he made changes (describing them in detail in his blog ), which allowed the C # and Thrift code generator to support both network models. This code can be found in our SDK for C # .
And a year later, we are again working on JavaScript applications for Windows 8 Metro, which need to provide access to the Evernote API from C # managed code. Again we face the incompatibility of Thrift with, this time, the .NET API for Metro applications. Today we decided to share with you a way to solve this problem.
In order to fix compilation errors, we started by creating a Metro class library in Visual Studio for the Evernote API and Thrift wrappers classes. First, our code used asynchronous network models if SILVERLIGHT was detected during the compilation process. For Metro we added NETFX_CORE:
')
Then it turned out that the I / O classes in the .NET API for Metro applications are no longer defined by the Close () methods. Microsoft explained to us in detail how to act in this case:
We were also advised by Microsoft to replace our two-step network operations (Begin * and End *) with new ReadAsync and the waiting operator, but we decided not to complicate anything and not change anything, since the old models seem to be working.
When forming requests to the API, all Evernote clients send HTTP headers with a given User-Agent - this allows us to easily identify the applications making requests in server logs. The HttpWebRequest.UserAgent property that we used to install the User-Agent for Silverlight was removed in the .NET API for Metro applications. The new HttpClient API allows us to install a specific User-Agent, but using the HttpClient requires us to move to a new model of waiting for a response, and, as mentioned above, we are not yet ready for such significant changes. At the moment we have left the User-Agent alone and put up with the lost ability to determine who makes requests to the API. Due to the fact that the model of expectations is likely to be used in the future, we will most likely develop a third model of network interaction that will support it, and will return support to the User-Agent.
Thanks to these three changes, we were able to compile the class library. However, class libraries can only be used by Metro applications developed in a managed language. Our API is used by a JavaScript application, which means we need to pack the libraries into a WinMD file. But try switching the code generation format of your project from Class Library to WinMD , and you will find that WinMD files introduce some serious limitations:
Fortunately, the limitations of WinMD files apply only to the interface that they represent in their code. Instead of trying to use our full client API in the application, we simply added a wrapper — a project that compiles as WinMD, supports the logic of individual operations with the API, and provides the application with a simpler API.
With the model of the wrapper library for the application, we got (with minimal changes in the existing code) a working Metro application that can fully work with the Evernote API. We are glad that users accept Windows 8 and Metro, and we hope that in the future “Metro-applications” will become so ubiquitous that this term will be replaced by the usual term “applications”.
A solution for Visual Studio 11 with our modified SDK and a trial application is available on GitHub . Try it and be sure to tell us about what you got.
And a year later, we are again working on JavaScript applications for Windows 8 Metro, which need to provide access to the Evernote API from C # managed code. Again we face the incompatibility of Thrift with, this time, the .NET API for Metro applications. Today we decided to share with you a way to solve this problem.
In order to fix compilation errors, we started by creating a Metro class library in Visual Studio for the Evernote API and Thrift wrappers classes. First, our code used asynchronous network models if SILVERLIGHT was detected during the compilation process. For Metro we added NETFX_CORE:
')
Then it turned out that the I / O classes in the .NET API for Metro applications are no longer defined by the Close () methods. Microsoft explained to us in detail how to act in this case:
We were also advised by Microsoft to replace our two-step network operations (Begin * and End *) with new ReadAsync and the waiting operator, but we decided not to complicate anything and not change anything, since the old models seem to be working.
When forming requests to the API, all Evernote clients send HTTP headers with a given User-Agent - this allows us to easily identify the applications making requests in server logs. The HttpWebRequest.UserAgent property that we used to install the User-Agent for Silverlight was removed in the .NET API for Metro applications. The new HttpClient API allows us to install a specific User-Agent, but using the HttpClient requires us to move to a new model of waiting for a response, and, as mentioned above, we are not yet ready for such significant changes. At the moment we have left the User-Agent alone and put up with the lost ability to determine who makes requests to the API. Due to the fact that the model of expectations is likely to be used in the future, we will most likely develop a third model of network interaction that will support it, and will return support to the User-Agent.
Thanks to these three changes, we were able to compile the class library. However, class libraries can only be used by Metro applications developed in a managed language. Our API is used by a JavaScript application, which means we need to pack the libraries into a WinMD file. But try switching the code generation format of your project from Class Library to WinMD , and you will find that WinMD files introduce some serious limitations:
Fortunately, the limitations of WinMD files apply only to the interface that they represent in their code. Instead of trying to use our full client API in the application, we simply added a wrapper — a project that compiles as WinMD, supports the logic of individual operations with the API, and provides the application with a simpler API.
With the model of the wrapper library for the application, we got (with minimal changes in the existing code) a working Metro application that can fully work with the Evernote API. We are glad that users accept Windows 8 and Metro, and we hope that in the future “Metro-applications” will become so ubiquitous that this term will be replaced by the usual term “applications”.
A solution for Visual Studio 11 with our modified SDK and a trial application is available on GitHub . Try it and be sure to tell us about what you got.
Source: https://habr.com/ru/post/145322/
All Articles