Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

saveNewNoteToEvernoteApp does not save my note if Evernote app is not running #104

Open
ewanmellor opened this issue Dec 1, 2014 · 0 comments

Comments

@ewanmellor
Copy link

https://discussion.evernote.com/topic/71474-ios-sdk-savenewnotetoevernoteapp-does-not-save-my-note-if-evernote-app-is-not-running/

From Denis Dorokhov:

I would like to report an issue that I think is a bug in Evernote iOS application. In our iOS app we use Evernote SDK for iOS version 1.3.1 for saving notes to Evernote app (using "[[EvernoteNoteStore noteStore] saveNewNoteToEvernoteApp:note withType:@"text/html"];"). We started using it in April 2014 and everything was great, but last week we've discovered that notes don't appear in Evernote after calling "saveNewNoteToEvernoteApp:withType:" method when Evernote app is not running. When Evernote app is running, then notes are successfully saved. We use the latest Evernote version for iOS.

I believe it worked before, because I tested exactly the same behavior several months ago. It can be reproduced easily if you terminate Evernote application and try to save a note within your app.

From me:

Yes, this is affecting us too.

I can't be 100% sure, but I think that this used to work. It definitely doesn't work now (when the Evernote app is closed). It works fine if the Evernote app is running at the time of the saveNewNoteToEvernoteApp call.

iOS 8.1.1.
Evernote SDK 1.3.1.
Evernote for iOS 7.6.2.313133.

joaquinmoreira pushed a commit to joaquinmoreira/evernote-sdk-ios that referenced this issue Aug 9, 2022
Added the "SendToEvernoteActivity" directory to the header search
paths. Including it with the directory worked for CocoaPods with
Objective-C, but not for Swift.

This may cause an error for those including it via a framework, but
since CocoaPods can't deal with this consistently, flattening the
heirarchy will be a better long term fix

Also, bumped to 2.0.6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant