Live Typing vs. Evernote: how we lay on an elephant

The purpose of this article is to convince all doubters that with close work with the client, even bureaucratic structures can be shifted and to greatly increase their self-esteem. It's about Evernote.

Outset

In 2015, Live Typing started the development of a project for our friends from Australia. The project worked in the employee performance monitoring niche. For a year of work, we have gone through several stages with the client to change the concept and to work hard on each new change that the client made already at the design stage. The final stage of the project involved deep integration with Google Drive, Evernote and Toggl services. In essence, the project copied some of the functionality of these services and created new mechanics.

With Google Drive, everything went smoothly. With Evernote - no. About what went wrong and how we managed to overcome it, read under the cut.
')


The task was simple:

1. The client is authorized in Evernote using our mobile application.
2. Creates a notebook with notes inside our application.
3. Finds a list of users with whom he wants to share this notebook.
4. Press the "Share" button and users receive an email inviting them to use this notebook.
5. Users confirm the invitation and a client's notepad appears in the interface of their native Evernote application.

The problem appeared at step 4. I will make a reservation that it was difficult to find it at the design stage, since the Evernote documentation looked complete. After implementing all the necessary requests to the Evernote API, the sharing method we needed did not work. We asked about this at StackOverflow and one of the Evernote representatives replied that:

1. there is a method and documentation, but you cannot use it, but you can only by representatives of Evernote.
2. Evernote official documentation is not relevant and this method will not work at all, since there is already a new shareNotebook method that needs to be addressed after updating the SDK. In other words, the SDK exists in open access, but it is irrelevant.

All Evernote mobile and web SDKs use the Thrift framework. It allows you to interpret your code in almost any language. I noticed that with non-updated SDKs, Evernote almost immediately updates its Thrift code on GitHub. And in the new Thrift code, of course, there was the shareNotebook method. We decided to update the current code ourselves and even made a pull request . Unfortunately, even so, the method only worked in half: the user who shared the notebook sees that the notebook is shared, but the users with whom it was shared cannot see it.

After trying this, we decided to pause the development and wait a couple of months with the hope that in a couple of months a company as big as Evernote could update its mobile SDK. Unfortunately, the company Evernote, one of the leaders of note applications with an annual income of about $ 120 million, in two months did not make the official SDK for the new version of the API with the implementation of the method described above. Why this happened, we can only guess.

How we made API changes

Here begins the story of our little victory. We had two options:

1. Retreat by telling the client that we cannot do nothing, because we cannot move a machine like Evernote.
2. Act and obtain updates to all SDKs, as well as API updates.

We decided not to retreat and to achieve a solution from Evernote by all means. There were three ways:

1. Find people who make decisions through LinkedIn. The fact is that to some extent this is due to the reputation of Evernote and we made a bet that their managers will try to quickly hush up the problem.
2. Contact Evernote support directly, periodically connecting a client.
3. Take everything into your own hands and find an engineer who is engaged in the release of the SDK in Evernote, find out plans for a new release and, perhaps, offer him some kind of help.

LinkedIn gave almost no results. Contacting the support of Evernote, we also could not achieve much. They dutifully accepted our comments on their obvious mistakes, listened to our position, said they would keep us informed and buried our proposal somewhere within their cozy offices.

Of course, the client after such an attitude was furious and had already begun to give up. But we really supported this project and did not want to leave it at the final stage in this state.

There was only one way out - to find the open data of the engineer from Evernote, who contacted us, and find out how we can help him. From the open information about him, I found only his Twitter. And for the first time in five years, I used the functionality of his chat! After a small correspondence, he shared with me his pain from the legacy that was currently on the backend.

As I said above, we, as application developers, could not take advantage of this functionality. The reason is that the keys of third-party developers and the keys that are used in official Evernote applications (web client, mobile applications, etc.) are made differently. This is obvious from a security point of view and, of course, Evernote could not provide us with the same master keys for our application. Also, these master keys were able to generate the so-called sharedKey, which was the connecting agent between the SharedNotebook client and the LinkedNotebook user, to whom this notebook was shared. I think the main problem was that open sharedKey could allow attackers to gain access to other people's notebooks and this functionality was not a priority.

The result of our communication was the official response that in the open documentation this method exists, but only Evernote employees can use it, and also the reasons why this is so have become clear. But, unlike support engineers, Amar (that was the name of the developer) was able to tell us the timeline for implementing this functionality, explain why it is not a priority at the moment, and was able to safely coordinate the release of this part of the API.



A week later, I received another letter stating that the functionality was rolled out to production and we can use it in the application. It was a victory!

Conclusion

In working on this project, team members dropped their hands several times for various reasons. However, it is important that we always believed in the project and that we are able to bring the client closer to success. This little story showed that the desire to help the client, faith in the project and personal communication between developers can lead to successful results.