Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Интересно, правда, я пользуюсь Java API.
Скажите, с помощью вашей библиотеки можно у заметки, у которой установлено поле «updated», сделать его пустым, то есть отображаемым в windows-клиенте как «Updated: none» (как бывает после создания заметки через почту)?
Скажите, с помощью вашей библиотеки можно у заметки, у которой установлено поле «updated», сделать его пустым, то есть отображаемым в windows-клиенте как «Updated: none» (как бывает после создания заметки через почту)?
Ха, надо бы попробовать.
Библиотека может то и ровно то, что позволяет Evernote Cloud API. Ни больше, ни меньше. Если через EDAM API теоретически возможно можно «обнулить» updated, то значит и с помощью QEverCloud можно.
Библиотека может то и ровно то, что позволяет Evernote Cloud API. Ни больше, ни меньше. Если через EDAM API теоретически возможно можно «обнулить» updated, то значит и с помощью QEverCloud можно.
Через Java API у таких заметок дата создания и дата редактирования совпадают. И через этот API нельзя установить поле updated в null, так как метод Note.setUpdated принимает long.
Сейчас вот проверил. 0 работает. Т.е. поле Note.updated должно быть передано со значением 0 в updateNote.
По крайней мере, клиент под Windows такую дату не отображает.
Если через Java API передать 0 в setUpdated, то в качестве времени обновления устанавливается текущее.
Вообще, я пытаюсь победить баг в Evernote 5.3 для Windows, когда клиент игнорирует дату обновления, заданную через Java API. В то же время клиент для Android и версия 5.0 дату заметок у себя обновляют. Если же поменять дату редактирования через приложение, то она версией 5.3 синхронизируется нормально.
Вот пытаюсь понять, что мне надо сделать, кроме вызова метода Note.setUpdated, чтобы результат был таким же как изменение даты через клиент.
Пытаюсь добиться, чтобы дата обновления была равна дате создания, чтобы при сортировке по дате редактирования заметки были в нужном мне порядке.
Вообще, я пытаюсь победить баг в Evernote 5.3 для Windows, когда клиент игнорирует дату обновления, заданную через Java API. В то же время клиент для Android и версия 5.0 дату заметок у себя обновляют. Если же поменять дату редактирования через приложение, то она версией 5.3 синхронизируется нормально.
Вот пытаюсь понять, что мне надо сделать, кроме вызова метода Note.setUpdated, чтобы результат был таким же как изменение даты через клиент.
Пытаюсь добиться, чтобы дата обновления была равна дате создания, чтобы при сортировке по дате редактирования заметки были в нужном мне порядке.
На счет хитрого бага несколько раз прочитал, но не уверен, что я понял суть.
Чтобы даты заметки были одинаковыми я бы просто задавал created и updated при создании заметки. В QEverCloud это бы выглядело где-то так:
quint64 time = QDateTime::currentMSecsSinceEpoch();
Note note;
note.created = time;
note.updated = time;
note.title =…
note.content =…
noteStote->createNote(note);
Как это в Java API будет и какие там еще баги подстерегают — этого я уже не скажу…
Чтобы даты заметки были одинаковыми я бы просто задавал created и updated при создании заметки. В QEverCloud это бы выглядело где-то так:
quint64 time = QDateTime::currentMSecsSinceEpoch();
Note note;
note.created = time;
note.updated = time;
note.title =…
note.content =…
noteStote->createNote(note);
Как это в Java API будет и какие там еще баги подстерегают — этого я уже не скажу…
Баг такой:
Я через API устанавливаю дату редактирования равной дате создания. На Java это выглядит так:
После этого выполняю синхронизацию в Evernote for Windows 5.3, а дата обновления у заметки не изменяется, остаётся такой же какой и была. Выполняю синхронизацию в Evernote for Android, там дата обновления становится равной дате создания.
Раньше в Windows всё также работало.
Но я нашёл решение, клиент для Windows обновляет у себя дату редактирования, если она отличается от даты создания минимум на 1 секунду, то есть работающий код такой:
Я через API устанавливаю дату редактирования равной дате создания. На Java это выглядит так:
Note note = noteStore.getNote(authToken, guid, false, false, false, false);
note.setUpdated(note.getCreated());
noteStore.updateNote(authToken, note);
После этого выполняю синхронизацию в Evernote for Windows 5.3, а дата обновления у заметки не изменяется, остаётся такой же какой и была. Выполняю синхронизацию в Evernote for Android, там дата обновления становится равной дате создания.
Раньше в Windows всё также работало.
Но я нашёл решение, клиент для Windows обновляет у себя дату редактирования, если она отличается от даты создания минимум на 1 секунду, то есть работающий код такой:
note.setUpdated(note.getCreated() + 1000);
Выглядит местами, как будто либа C++-ная, а не Qt-шная — например, в месте catch(std::exception ...)
И немного неожиданный конец статьи.
И немного неожиданный конец статьи.
А что, Qt это не С++? ;)
Если вас это беспокоит, то могу уверить, что кроме std::exception из стандартной библиотеки никиких других классов не используется.
Неожиданный конец — это без выводов? Меня за это регулярно пеняют. Не люблю воды, а вроде уже сказал все, что хотел. «Кому интересно, качаем и смотрим» — вроде и так подразумевается.
Если вас это беспокоит, то могу уверить, что кроме std::exception из стандартной библиотеки никиких других классов не используется.
Неожиданный конец — это без выводов? Меня за это регулярно пеняют. Не люблю воды, а вроде уже сказал все, что хотел. «Кому интересно, качаем и смотрим» — вроде и так подразумевается.
Проблема не в std::exception, а в самом факте синхронного API, это делает невозможным использование библиотеки в реальных сложных проектах.
Далее, в EvernoteOAuthDialog переопределен метод ::exec, только из которого стартует процес авторизации, то есть тоже невозможно использовать классический QDialog::open().
В QsrandExecutor вообще бага, связанная с криптографией, из-за нее тот же nonce в EvernoteOAuthWebView::authenticate может принимать только 256 различных значений. Для генерации 64-битных чисел лучше использовать, наверное, std::mt19937_64, за счет использования std::random_device seed будет браться не из текущего времени, а из /dev/(u)random.
В QsrandExecutor вообще бага, связанная с криптографией, из-за нее тот же nonce в EvernoteOAuthWebView::authenticate может принимать только 256 различных значений. Для генерации 64-битных чисел лучше использовать, наверное, std::mt19937_64, за счет использования std::random_device seed будет браться не из текущего времени, а из /dev/(u)random.
Спасибо за то, что дали себе труд глянуть исходники. Я приветсвую любую конструктивную критику.
QDialog::open — да, забыл про него. Видимо потому, что никогда не использую :)
Пофиксю при случае.
По поводу «256 возможных значений» не понял. Можете ткнуть носом в конкретную строку? Я такого бага не вижу.
std::mt19937_64 — это, если я не ошибаюсь, c++11. Библиотека под c++03.
Пожалуй, надо бы фанктор прикрутить в параметры authenticate для генерации nonce.
QDialog::open — да, забыл про него. Видимо потому, что никогда не использую :)
Пофиксю при случае.
По поводу «256 возможных значений» не понял. Можете ткнуть носом в конкретную строку? Я такого бага не вижу.
std::mt19937_64 — это, если я не ошибаюсь, c++11. Библиотека под c++03.
Пожалуй, надо бы фанктор прикрутить в параметры authenticate для генерации nonce.
qsrand(QDateTime::currentMSecsSinceEpoch() % static_cast<quint64>(256)*256*256*256);
Вначале выполнится деление с остатком на 256, а потом результат домножится на 224. Вообще мне кажется плохим тоном инициализировать qsrand из библиотеки — этим должно заниматься приложение.
А есть причины придерживаться c++03? Сейчас все адекватные компиляторы уже умеют c++11 в достаточной степени.
Вначале выполнится деление с остатком на 256, а потом результат домножится на 224. Вообще мне кажется плохим тоном инициализировать qsrand из библиотеки — этим должно заниматься приложение.
Библиотека под c++03.
А есть причины придерживаться c++03? Сейчас все адекватные компиляторы уже умеют c++11 в достаточной степени.
Фейспалм. Фиксю.
«Сейчас все адекватные компиляторы уже умеют c++11 в достаточной степени» — это если не поминать MSVC незлым тихим словом.
«Сейчас все адекватные компиляторы уже умеют c++11 в достаточной степени» — это если не поминать MSVC незлым тихим словом.
«Вообще мне кажется плохим тоном инициализировать qsrand из библиотеки — этим должно заниматься приложение.»
В принципе, я согласен. Лезть исподтишка библиотекой в глобальное состояние — оно действительно некрасиво. Но в данном случае, имхо, это не то чтобы совсем страшно. Если программист вызовет qsrand() где-нибудь в main, то мои закулисые манипуляции потеряют эффект, а если нет — то ему, по видимому, все равно, qrand/rand он не использует и я ему не мешаю.
Гораздо неприятнее будет, если программист забудет вызвать qsrand() и в таком виде отдаст свою программу пользователям. Дыра в безопасности, которую моя библиотека некрасивыми средствами пытается закрыть.
В принципе, я согласен. Лезть исподтишка библиотекой в глобальное состояние — оно действительно некрасиво. Но в данном случае, имхо, это не то чтобы совсем страшно. Если программист вызовет qsrand() где-нибудь в main, то мои закулисые манипуляции потеряют эффект, а если нет — то ему, по видимому, все равно, qrand/rand он не использует и я ему не мешаю.
Гораздо неприятнее будет, если программист забудет вызвать qsrand() и в таком виде отдаст свою программу пользователям. Дыра в безопасности, которую моя библиотека некрасивыми средствами пытается закрыть.
Хм… Видимо, Evernote в принципе не предназначен для реальных сложных проектов. Все SDK им предлагаемые — синхронные.
Кстати, если серьезно: ничто не мешает мне сделать асинхронный вариант API, немного поменяв генератор кода. Единственный вопрос: как оно, это асинхронное API, дожно выглядеть? У вас похоже, есть ответ на этот вопрос. Не поделитесь ответом?
Кстати, если серьезно: ничто не мешает мне сделать асинхронный вариант API, немного поменяв генератор кода. Единственный вопрос: как оно, это асинхронное API, дожно выглядеть? У вас похоже, есть ответ на этот вопрос. Не поделитесь ответом?
Например сделать по аналогии с QNetworkAccessManager или QtDbus — каждая операция возвращает некоторый MyCoolReply, который по завершению операции пошлет сигнал finished(), на который мы уже можем повеситься и обработать результат как только, так сразу. В QtDBus модуле показан пример реализации асинхронной модели в случае, если разные методы возвращают объекты разных типов, но при этом хочется иметь общий API возвращаемых объектов. Такой подход должен быть не сложен для реализации, но при этом достаточно эффективен.
Я думал об этом, но пришел к выводу, что в случае с Thrift вообще и Evernote в частности такая модель не стоит того гембеля, что она привносит. Согласитесь, асинхронность превратит код в лапшу.
Thrift по своей идеологии имитирует вызов локальных функций, и Evernote этой идеологии всецело придерживается. Почти всегда перед тем, как выполнять следующий запрос к Evernote, нужно знать результат предыдущего. Как следствие, основное преимущество асинхронной модели — параллелизируемость на уровне отдельных запросов — сводится практически на нет.
Имхо проще и в целом так же эффективно будет реализовывать логически связанные последовательности запросов (как то же создание заметки) в виде синхронных вызовов, выполняемых в отдельном потоке. Тогда отдельные последовательности параллелизируются, код удобочитаем, и интерфейс = главный поток «замирать» не будет.
Если народ захочет асинхронности, то можно и сделать… но я пока не ощутил в ней насущной необходимости.
Thrift по своей идеологии имитирует вызов локальных функций, и Evernote этой идеологии всецело придерживается. Почти всегда перед тем, как выполнять следующий запрос к Evernote, нужно знать результат предыдущего. Как следствие, основное преимущество асинхронной модели — параллелизируемость на уровне отдельных запросов — сводится практически на нет.
Имхо проще и в целом так же эффективно будет реализовывать логически связанные последовательности запросов (как то же создание заметки) в виде синхронных вызовов, выполняемых в отдельном потоке. Тогда отдельные последовательности параллелизируются, код удобочитаем, и интерфейс = главный поток «замирать» не будет.
Если народ захочет асинхронности, то можно и сделать… но я пока не ощутил в ней насущной необходимости.
Я не понимаю никакого бонуса выноса синхронных методов в отдельный поток, с точки зрения API будет хуже, чем event loop-based API, писать сложнее, использовать тоже сложнее.
Примерно так можно использовать было бы event-loop based API:
При этом API будет не сильно отличаться по духу и стилю от самого Qt.
Примерно так можно использовать было бы event-loop based API:
NoteStore *ns = ...;
Note note = ...;
connect(ns->createNote(note), &CreateNote::finished, [] (const EverCloudException &error) {
if (error)
qWarning() << error.toString();
});
При этом API будет не сильно отличаться по духу и стилю от самого Qt.
«Я не понимаю никакого бонуса выноса синхронных методов в отдельный поток, с точки зрения API будет хуже, чем event loop-based API, писать сложнее, использовать тоже сложнее.»
Это субъективно. Моему субъекту, например, все кажется прямо наоборот.
Вашему примеру для полноты картины не хватает последовательности вызовов Evernote. В качестве гипотетического случая: три раза createNote, строго один за другим. В синхронном API это выглядит проще некуда:
А в асинхронном?
Это субъективно. Моему субъекту, например, все кажется прямо наоборот.
Вашему примеру для полноты картины не хватает последовательности вызовов Evernote. В качестве гипотетического случая: три раза createNote, строго один за другим. В синхронном API это выглядит проще некуда:
ns->createNote(note); ns->createNote(note); ns->createNote(note);
А в асинхронном?
Эксперимент есть эксперимент. Наверное, попробую сделать асинхронный вариант API. Я правда пока сомневаюсь, что сам я найду ему применение, но, может, кому-то и пригодится. Время покажет.
Вот смотрю на код примера… вижу try catch при создании заметки, получается, что данный код синхронный?
Судя по коду библиотеки — да, на каждый запрос создается QEventLoop + ожидание ответа. Не представляю как использовать эту библиотеку в реальных проектах.
С тем же успехом можно было сгенерировать код из Thrift файла. После чего переписать транспорт под Qt.
Не поделитесь, чем конкретно такой подход мешает реализации реальных проектов? Не сочтите за иронию, мне действительно интересно знать ваше мнение.
Представим стандартную ситуацию, у пользователя плохой интернет (например, пинги по сервера по 200-300 мс), тогда каждый запрос к API может породить 200-миллисекундную заморозку интерфейса или части интерфейса (зависит от того, при обработке которого события будет спровоцирован запрос к API). Если же в процессе ожидания некоторого запроса мы пошлем еще один запрос (из QEventLoop'а), то первые запрос не завершится, пока не будет обработан следующий вопрос и т.д…
Все это суммарно приведет к очень плохому пользовательскому опыту.
Все это суммарно приведет к очень плохому пользовательскому опыту.
Т.е. претензии собственно к синхронности, а не к конкретно ее реализации через QEventLoop.
«Заморозку» интерфейса можно решить многопоточностью. Распараллеливание на уровне отдельных обращений к Evernote таким образом не получится, но оно по логике самого API в целом неосуществимо.
Т.е. претензии собственно к синхронности, а не к конкретно ее реализации через QEventLoop.
QEventLoop еще не самый плохой способ, но в больших приложениях даже он становится очень большой проблемой.
«Заморозку» интерфейса можно решить многопоточностью.
Здесь есть ряд проблем:
- Как общаться с тем потоком из гуя? Все равно придется городить асинхронное API, т.е. опять приходим к начальной проблеме
- Многопоточность — это накладные расходы, лишняя память, лишние context switch'и. Асинхронное API, основанное на event loop почти всегда быстрее
Как общаться с тем потоком из гуя? Все равно придется городить асинхронное API, т.е. опять приходим к начальной проблеме
Зато на более высоком уровне, более соответствующем логике конкретной программы. Я не назвал бы это изначальной проблемой. К тому же, общение между потоками в Qt не есть большая проблема. Все готово, сигналы/слоты между потоками работают.
Многопоточность — это накладные расходы, лишняя память, лишние context switch'и. Асинхронное API, основанное на event loop почти всегда быстрее.
Это верно, но, насколько я понимаю, по сравнению с затратами на сетевые вещи все эти расходы теряют значимость.
Хотелось много сказать, но другие пользователи опередили, осталось только:
«Для Ubuntu Phone пишется Evernote Client. Попробуйте найти там пару хороших идей».
«Для Ubuntu Phone пишется Evernote Client. Попробуйте найти там пару хороших идей».
Ссылка на исходники?
Пожалуйста
Ссылка на исходники
Ссылка на исходники
Хотелось много чего сказать, но я ограничусь одним тезисом: полезно читать перед тем как писать.
Прочитайте еще раз мою заметку, гляньте исходники QEverCloud. Надеюсь, вам станет понятно, что целью QEverCloud является заменить предлагаемые Evernote сгенеренные thrift компилятором файлы, которые громко именуются Evernote SDK for C++, а не написать конкретную прикладную программу.
В рамках этой цели предлагаемые вам исходники не представляют интереса — там этот самый Evernote SDK for C++ во всю используется, а не заменяется.
Все дальнейшее в программе по поводу Evernote мало интересно с точки зрения общего SDK, предназначенного для любых программ с самыми разнообразными задачами и архитектурой. QAbstractItemModel в качестве API к Evernote? Даже не смешно. Как решение задач конкретной программы — почему бы и нет, но как SDK к Evernote (а именно это есть тема заметки) — идея явно не очень здравая.
Более того, ваш глубокомысленный тезис о «другие пользователи опередили» имеет неявный подтекст, что предлагаемый мною подход к написанию программ — многопоточность с вынесением обращений к Evernote в отдельные потоки — неверен. Что явно говорит о том, что вы не потрудились ознакомится с темой, перед тем как писать. Ибо в приведенных вами исходниках используется именно этот подход, против которого EuroElessar привел массу разумных и интересных контраргументов, пусть с ними и можно поспорить. Вы уж определитесь, что вы хотите сказать.
Так что я ваш тезис о хороших идеях как-то не понял. В приведенных вами исходниках я их не нашел ничего нового и особого интересного.
Если вам хочется конструктивной дискуссии — пожалуйста, конкретику в студию. Какие хорошие с вашей точки зрения идеи вы хотели бы видеть в QEverCloud, но не видите? Или может вы хотели бы реализовать хорошую идею с помощью QEverCloud, но не можете из-за каких-то ограничений библиотеки?
Прочитайте еще раз мою заметку, гляньте исходники QEverCloud. Надеюсь, вам станет понятно, что целью QEverCloud является заменить предлагаемые Evernote сгенеренные thrift компилятором файлы, которые громко именуются Evernote SDK for C++, а не написать конкретную прикладную программу.
В рамках этой цели предлагаемые вам исходники не представляют интереса — там этот самый Evernote SDK for C++ во всю используется, а не заменяется.
Все дальнейшее в программе по поводу Evernote мало интересно с точки зрения общего SDK, предназначенного для любых программ с самыми разнообразными задачами и архитектурой. QAbstractItemModel в качестве API к Evernote? Даже не смешно. Как решение задач конкретной программы — почему бы и нет, но как SDK к Evernote (а именно это есть тема заметки) — идея явно не очень здравая.
Более того, ваш глубокомысленный тезис о «другие пользователи опередили» имеет неявный подтекст, что предлагаемый мною подход к написанию программ — многопоточность с вынесением обращений к Evernote в отдельные потоки — неверен. Что явно говорит о том, что вы не потрудились ознакомится с темой, перед тем как писать. Ибо в приведенных вами исходниках используется именно этот подход, против которого EuroElessar привел массу разумных и интересных контраргументов, пусть с ними и можно поспорить. Вы уж определитесь, что вы хотите сказать.
Так что я ваш тезис о хороших идеях как-то не понял. В приведенных вами исходниках я их не нашел ничего нового и особого интересного.
Если вам хочется конструктивной дискуссии — пожалуйста, конкретику в студию. Какие хорошие с вашей точки зрения идеи вы хотели бы видеть в QEverCloud, но не видите? Или может вы хотели бы реализовать хорошую идею с помощью QEverCloud, но не можете из-за каких-то ограничений библиотеки?
Это Вы мне говорите «Вы уж определитесь»? Кажется, это у Вас пост начинается с предложения «Хотелось много чего сказать, но я ограничусь одним тезисом: полезно читать перед тем как писать», за которым следует моментальный 6-ти абзацный отказ от своих слов.
А теперь по существу: да, может быть я не совсем внимательно прочитал Ваш пост — температура, знаете ли, мешает сосредоточиться. Но даже в полубессознательном состоянии я способен отличить нормальный продукт от поделки. Я сейчас специально открыл два файла (exceptions.cpp и exceptions.h) и мне хватило. Что я там увидел:
— Микс строк std::string и QString
— Объявления переменных в стиле языка С
— Передачу QString по значению
— Необернутые в QStringLiteral строковые константы
Ну и вообще в целом мне не понравилось использование исключений (Вы либу пишете, которая основывается на Qt'e, и название начинается с «Q», а Вы видели, чтобы в кьюте использовали исключения?) и завязка на виджеты. Это я к тому, что первое впечатление оказалось более или менее правильным. А поскольку оно было не важным, то я и порекомендовал Вам попробовать поискать идеи по реализации в целях улучшения Вашего продукта. Это было искренний и полезный совет, но раз уж Вы так остро реагируете, то и ответ мой получаете в соответствующем стиле.
А теперь по существу: да, может быть я не совсем внимательно прочитал Ваш пост — температура, знаете ли, мешает сосредоточиться. Но даже в полубессознательном состоянии я способен отличить нормальный продукт от поделки. Я сейчас специально открыл два файла (exceptions.cpp и exceptions.h) и мне хватило. Что я там увидел:
— Микс строк std::string и QString
— Объявления переменных в стиле языка С
— Передачу QString по значению
— Необернутые в QStringLiteral строковые константы
Ну и вообще в целом мне не понравилось использование исключений (Вы либу пишете, которая основывается на Qt'e, и название начинается с «Q», а Вы видели, чтобы в кьюте использовали исключения?) и завязка на виджеты. Это я к тому, что первое впечатление оказалось более или менее правильным. А поскольку оно было не важным, то я и порекомендовал Вам попробовать поискать идеи по реализации в целях улучшения Вашего продукта. Это было искренний и полезный совет, но раз уж Вы так остро реагируете, то и ответ мой получаете в соответствующем стиле.
Приделал асинхронное API.
Пример использования на GitHub.
Пример использования на GitHub.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QEverCloud: Evernote SDK для Qt