web messages emptyorder что значит
Google запускает веб-версию Android Messages. Как ей пользоваться?
Сотрудники Google анонсировали версию Android Messages для браузеров. Платформу уже запустили, однако для всех пользователей она будет доступна в течение недели. Рассказываем, как начать пользоваться мессенджером.
Веб-версия Android Messages доступна здесь, сообщает Android Authority. Инструкция по использованию появится на главной странице.
В целом, принцип простой. Для начала открываем на смартфоне приложение Android Сообщения, которое доступно по ссылке. Затем нажимаем на иконку меню в правом верхнем углу и выбираем «Веб-версия Сообщений». Последний шаг — сканирование QR-кода. Тот же принцип работает в WhatsApp и Viber, поэтому трудности возникнуть не должны.
Обновление Android Messages
Релиз прокомментировали представители компании в блоге. Платформа позволяет прикреплять к тексту изображения, эмодзи и стикеры. Нужные GIF-файлы можно искать, тогда как англоязычные пользователи оценят функцию быстрых ответов Smart Reply.
Также мессенджер научится показывать превью ссылок и автоматически копировать одноразовые пароли одним нажатием.
Пока платформа находится в роли догоняющей. Мнением о её будущем по традиции делимся в Телеграм-чате AndroidInsider.
Новости, статьи и анонсы публикаций
Свободное общение и обсуждение материалов
Приложения и сервисы Google являются такой же неотъемлемой частью Android, как системные обновления. Не будь их, и операционка не была бы и вполовину такой удобной и функциональной. Ведь большая часть всех нововведений, которые появляются в Android, добираются до неё не с системными обновлениями, а в составе апдейтов сервисов Google. Они даже необязательно должны быть большими. Иногда мелкий и невзрачный на первый взгляд патч несёт в себе знаковые нововведения, облегчающие использование смартфона. Совсем как в случае с приложением «Сообщения».
Как использовать SMS-мессенджер Google на компьютере
Компания Google запустила веб-версию «Сообщений». Она синхронизируется со смартфоном, и позволяет получать и отправлять SMS-сообщения с гифками, фотографиями и стикерами.
Веб-версия «Сообщений» доступна по адресу messages.android.com, но для того, чтобы воспользоваться ею, необходимо обновить приложение «Сообщения» на смартфоне до версии 3.3.043, которая только начала появляться в Google Play Маркете. Апдейт доберётся до всех пользователей Android в течение недели.
Если вы обновили приложение до нужной версии, откройте его, нажмите на меню в правом верхнем углу и выберите «Сообщения в вебе». Откроется камера, с помощью которой нужно отсканировать QR-код, который показан на странице messages.android.com. Если согласиться с предложением «запомнить этот компьютер», в мессенджер не придётся залогиниваться повторно.
«Сообщения» работают в Chrome, Firefox, Opera и большинстве других популярных браузеров. Помимо работы с текстом, они позволяют отправлять заготовленные ответы, просматривать содержимое ссылок внутри беседы, копировать одноразовые коды одним кликом, а также обмениваться гифками, стикерами, эмодзи и изображениями.
Для полноценного использования веб-версии мессенджера Google необходимо назначить «Сообщения» дефолтным приложением для работы с SMS на смартфоне. Это можно сделать через «Настройки» > «Приложения» > «Приложения по умолчанию».
Как обмениваться сообщениями SMS и MMS в Android Messages в вебе (инструкция)
Google 19 июня открыла возможность обмениваться сообщениями SMS и MMS в вебе с помощью своего мессенджера для смартфонов Android Messages. Эта функция позволяет отправлять и читать входящие сообщения, которые приходят на Android-смартфон пользователя, прямо в браузере на компьютере или планшете. Помимо текста, она также позволяет обмениваться эмодзи, изображениями и стикерами в вебе. С Android Messages работают браузеры Chrome, Firefox, Microsoft Edge, Safari.
Чтобы воспользоваться Android Messages в вебе, нужно установить Android Messages как главное приложение для текстинга на вашем смартфоне. Понятное дело, у Google на него большие планы. Так что если вам больше нравится, скажем, родное приложение Samsung для обмена текстовыми сообщениями, имейте ввиду — Android Messages не будет работать параллельно с ним.
Если отбросить это ограничение, весь остальной процесс установки и настройки прост. The Verge написал пошаговую инструкцию для пользователей, которые хотят испытать на себе общение с Android Messages.
Чтобы не проходить процедуру сканирования QR-кода из раза в раз, поставьте галочку в пункте меню настроек «Remember this computer» (запомнить этот компьютер). Вы можете найти это меню в веб-версии Android Messages, нажав на иконку с такими же тремя вертикально расположенными точками справа от «Сообщений». Не стоит включат эту функцию, если вы используете чужой ПК, доступ к которому могут легко получить посторонние люди.
Вы можете в любой момент разорвать синхронизацию с компьютером из вашего приложения на смартфоне. Вернитесь в меню «Messages for web» в Android Messages и выберите, на каком компьютере вы хотите осуществить выход из веб-версии. Также можно одним кликом отписаться от всех альтернативных устройств.
В Android Messages для смартфонов нет ночного режима, но Google реализовала его в веб-версии, ведь на ПК слишком светлый интерфейс может ослепить вас в ночное время. Чтобы активировать ночной режим, в меню настроек в веб-версии найдите пункт «Enable dark theme» (включить темную тему) — он находится сразу над пунктом «Запомнить этот компьютер», который мы упомянули выше.
Чтобы послать фотографию через веб-версию Android Messages, можно нажать на специальную иконку справа от иконок для эмодзи и стикеров или просто перетащить файл в окно диалога, чтобы послать MMS.
Обратите внимание: веб-версия Android Messages не работает, если выключен ваш смартфон. Поэтому когда у него садится батарея или он по какой-то причине выключается, вы не сможете ничего написать и отправить с вашего ПК.
Google Cloud Messaging: «Сова, открывай! Пуш пришел!»
Всем известный сервис Google Cloud Messaging (GCM) нужен для того, чтобы ваше приложение всегда показывало актуальные данные пользователю. Схема работы сервиса включает в себя три компоненты.
Непосредственно сервер GCM, ваш пуш-сервер и устройство с установленным приложением. Алгоритм работы простой: устройство регистрируется в GCM, получает registrationId – некий токен, который используется в дальнейшем, – сохраняет его у себя локально и передает серверу. Далее пуш-сервер использует этот registrationId для отправки сообщений вашему приложению на устройстве.
В этом материале будут рассмотрены проблемы на двух участках, который обозначены на схеме: пуш-сервер – GCM и GCM – устройство.
Обработка ошибок от сервера GCM
В случае успешной отправки сообщения ваш пуш-сервер получит ответ от GCM со статус кодом 200 и ненулевой message_id.
Ошибки приходят в теле ответа со статус-кодом 200. Поэтому полагаться только на статус-код 200 недостаточно. Здесь я приведу пример одной из самых важных ошибок, это NotRegistered, другие менее интересные. В большинстве случаев она означает, что приложение, в которое ваш пуш-сервер отправляет сообщение, было удалено, либо приложение уже использует другой registrationId, а ваш пуш-сервер почему-то об этом не знает. Получив такой ответ от GCM, пуш-сервер должен незамедлительно удалить данный registrationId из своего хранилища.
Для мониторинга ошибок подключайте GCM статистику в консоли разработчика.
Синхронизация registrationId на клиенте и пуш-сервере
RegistrationId является одной из самых важных частей инфраструктуры GCM. Рассинхронизация registrationId между клиентом и пуш-сервером приведет к печальным последствиям. Есть все шансы, что пользователи останутся без пуш-уведомлений навечно. GCM отслеживает ситуацию, когда на устройстве по каким-то причинам обновляется registrationId, и сообщает об этом пуш-серверу посредством параметра canonical_ids.
Получив такой ответ, пуш-сервер просто обязан обновить registrationId на значение из ответа. Если этого не сделать, то еще какое-то время сообщения будут доходить до клиента и старый registrationId будет валиден, но рано или поздно GCM ответит ошибкой NotRegistered, после чего пуш-сервер удалит registrationId, и пользователи навсегда забудут о пуш-уведомлениях в вашем приложении. Поэтому обрабатывайте параметр canonical_ids и не доводите до греха.
Два основных подхода в работе с GCM
Первый — это Messages with Payload. Суть его в том, чтобы в самом сообщении передавать какую-то полезную информацию. Например, в мессенджере это может быть текст сообщения, в новостном приложении — сама новость. Второй механизм — это Send-to-Sync. Он более оптимизирован по расходу трафика, т.к. в само сообщение не упаковывается много данных. Сообщение выступает в роли сигнала о том, что приложению следует забрать свежие данные с сервера. Второй подход напрямую связан с параметром collapse_key.
Messages with Payload
Идеальная ситуация, когда ваше устройство держит соединение с сервером GCM, сообщения отправляются и успешно доставляются на устройство. Если же соединения нет (например, вы застряли в лифе или зашли в метро), а вам в это время идут сообщения, то они начинают складываться в некую очередь в GCM-хранилище. Эта очередь не бесконечна, лимит составляет 100 сообщений. Как только придет 101 сообщение, то все они удаляются и больше не накапливаются. Когда устройство поймает сеть и установит соединение с GCM, в приложение придет intent с информацией о том, что было удалено, например, 345 сообщений.
Получив такой intent, нужно не полениться и сходить на сервер за свежими данными. Иначе пользователь увидит их только когда придет очередное пуш-уведомление, а когда оно придет – никому неизвестно. Это очень важный момент, о котором нужно помнить при реализации подхода «Messages with Payload».
Send-to-Sync
Допустим, мы используем collapse_key. Это некая константа, которых может быть не более четырех для одного registrationId, т.е. для одного инстанса приложения. Например, новостное приложение собирает какие-то данные с разных сервисов. Пусть один сервер отдает спортивные новости, другой — культуру, третий — политику, четвертый — авто. Возникнет проблема, конечно, когда появится пятый сервис, но сейчас ни в этом суть. В отправке сообщения для соответствующей рубрики можно использовать свой collapse_key: sport, culture, policy, auto.
При приходе очередного сообщения с одним и тем же collapse_key GCM заменяет старое сообщение вновь пришедшим. В принципе, логично, т.к. мы помним, что сообщение в подходе «Send-to-Sync» является всего лишь сигналом нашему приложению о том, что следует сходить на сервер за свежими данными. Но тут нас подстерег один неприятный момент, из-за которого нам пришлось отказаться от подхода «Send-to-Sync» — тротлинг. Тротлинг заключается в том, что GCM сервер может некоторое время ждать, чтобы собрать как можно больше сообщений с одинаковым collapse_key. Все бы хорошо, но это вносит задержку в доставку сообщения до клиента (стабильно замечал задержку в полминуты-минуту), что недопустимо для некоторых типов приложений, например, мессенджера.
Из-за этой задержки мы перестали использовать collapse_key. Если в вашем приложении некритична небольшая задержка в доставке сообщений, то подход «Send-to-Sync» — хороший выбор.
Со временем мы учли все вышеописанные детали в имплементации нашего пуш-сервера. Но по-прежнему оставалось большое кол-во отзывов с примерно таким содержимым: «Я вижу новые сообщения, только когда захожу в приложение. Когда оно не запущено, до меня сообщения не доходят. ». Сначала основной гипотезой была рассинхронизация registrationId, хранящихся на устройстве и на пуш-сервере. Для ее подтверждения мы вкрутили на устройстве проверку, суть которой в том, чтобы приложение периодически спрашивало пуш-сервер: «У тебя есть мой registratioinId?». Ответ «да» гарантирует нам с большой долей вероятности, что registrationId актуальный.
И согласно статистике, ответов «да» 99,7%. Что позволило нам сделать вывод, что с синхронизацией registrationId все нормально. Начали искать проблему на участке между устройством и GCM. Неоднократно был свидетелем ситуации, когда на Samsung S4, да простит меня Samsung, выключаешь экран, и сообщения начинают приходить с большой задержкой (порядка 10 – 15 минут). С помощью наших коллег сетевых администраторов было выяснено, что TCP-соединение между устройством и GCM становилось неактивным (idle), и пакеты переставали ходить. Причиной всему этому так называемый «heartbeat». «Heartbeat» — это пакетик (ping), посылаемый системой раз в определенный интервал времени, чтобы «оживить» TCP-соединение между устройством и GCM (почитать более подробно об этом можно здесь).
И интервал, через который посылается heartbeat, довольно велик. Вроде, в августе 2014 года его сократили до 8 минут, но информация, возможно, неточная. В интернете предлагается решение, которое применяется в так называемых «пуш-фиксирах». Суть его в том, чтобы инициировать посылку heartbeat-пакета вручную. Но к сожалению, это решение работает только для root-устройств.
Десять минут взято из головы. Если дельта больше порогового значения, то переключаем приложение на режим работы с собственным соединением.
В экспериментальных целях собственное соединение было реализовано путем http лонг-поллинг соединения, т.к. это был самый быстрый путь для «попробовать». Такая сборка была выслана нескольким нашим бета-пользователям с просьбой понаблюдать за доставкой сообщений и расходом батареи. В целом, как ни странно, не было резкого всплеска увеличения расхода батареи, а пользователи были довольны скоростью доставки сообщений. Тема реализации собственного соединения с бэкенд-сервером заслуживает отдельной статьи, а над самой реализацией мы продолжаем еще думать.
Надеюсь, статья будет полезной и позволит сократить ваше время при использовании сервиса GCM, а также буду рад, если поделитесь своим опытом решения проблемы скорости доставки сообщения до клиента в своих приложениях.
Обходим запрет messages API Вконтакте через Python
Статья и весь написанный код создавались только в образовательных и исследовательских целях и никогда не использовались для незаконной деятельности. Автор не призывает вас повторять какие либо описанные здесь действия и не несёт за них никакой ответственности.
Но не все люди знакомы c javascript и node.js, поэтому я и решил написать свою библиотеку на python, которым сейчас пользуются многие, позволяющую через «тестовые запросы» документации предоставить полный функционал messages API. Сразу прошу не злиться на меня в местах, где я буду повторять аспекты прошлого «выступления», потому что я хочу оформить эту статью в виде независимой документации.
Как этим пользоваться?
Теперь мы можем импортировать из этого пакета главный класс и создать его экземпляр, указав логин, пароль, какой вид авторизации использует данный аккаунт, а также директорию, куда мы хотим сохранить куки-авторизации пользователя. Это необходимо, чтобы пользователям с двухфакторной авторизацией не пришлось при каждом запуске скрипта постоянном вводить код из сообщения.
И по сути, на этом всё. Теперь нам остаётся лишь открыть документацию и использовать интересующие нас методы. Хочу сразу отметить, что такой подход позволяет нам использовать практически любой метод из документации, даже не относящийся к разделу messages:
Также мы можем комбинировать данную библиотеку с другими, к примеру, через vk_api мы можем загрузить фотографии с компьютера (код для этого действия приводится у них в разделе examples), а через vk_messages прикрепить эти вложения к сообщению:
Из любопытства я реализовал классическую функцию, которая в заданной папке создаёт подпапки людей, с которыми общался человек, и пытается выкачать последние сообщения и абсолютные url-ы фотографий. К моему счастью, всё работало как часы, и лишних ошибок не было:
Теперь же я хочу перейти к одной из самых интересных частей этой библиотеки: имея куки авторизации, мы можем выполнять абсолютно любые действия. Приведу свой личный пример, когда для постов группы, в которой я состою, мне нужно было составить таблицу, состоящую из ID поста и его автора. Но в чём была загвоздка: официальный api возвращает только человека, который опубликовал статью. Воспользовавшись сниффером, я увидел, что при наведении на дату публикации поста эти данные подгружаются с сервера. И после этого я написал обёртку, которая позволяла отправлять сколько угодно подобных запросов, используя лишь ссылку поста и куки авторизации, чтобы получать авторов. В примере ниже останется лишь избавиться от ненужных тегов:
Но что доказывает нам верхний кусок кода? Правильно, даже если ВК закроет тестовые запросы на своей документации, мы всегда сможем симулировать действия пользователя и получать нужную информацию. В качестве эксперимента я сделал небольшую функцию, которая через запросы «пролистывания» страницы может получать ссылки на фотографии без использования официального API.
Выглядит ли это громоздко? Да. Работает ли это намного медленнее, чем официальный api? Да. Но если ВК отнимут последнюю возможность доступа к сообщениям, мы всегда сможем найти выход.
Также отмечу, что я постарался добавить во все места библиотеки, где возможны ошибки, исключения с пояснениями, но если вы найдёте какие-то события, к которым не отображается пояснение, то прошу сообщить мне об этом.
Думаю, это довольно очевидно, но я всё-таки должен вас предупредить, что нужно быть осторожнее с сохранением куки, так как они по умолчанию сохраняются в той же папке, откуда был запущен скрипт, так что не бросайте их где попало, ведь именно для этого есть возможность выбрать их место сохранения. Кончено, через некоторое время эти куки сами по себе станут невалидными, но до этого момента они могут являться серьёзной угрозой безопасности вашего аккаунта.
Как это работает?
Для тех, кто интересуется, что происходит под капотом данного скрипта, вкратце пройдусь по основным пунктам. При авторизации делаются простые request запросы, симулирующие вход пользователя, которые лишь слегка меняются в зависимости от вида авторизации, а после успешного входа куки сохраняются в pickle файл. При запросе к api через документацию, ко всем настраиваемым параметрам прибавляется «param_», то есть значение offset превратится в param_offset. Также в запросе передаётся hash-код, который содержится в атрибуте data-hash тэга кнопки «Выполнить». Насколько я заметил, это значение для каждого метода постоянно.
Так же отмечу один важный момент: пароль отправляется в кодировке ANSI, где символы русского алфавита разделяются знаком «%», и данного кода достаточно для реализации такого декодирования. Это может стать проблемой для некоторых линукс пользователей, ведь, насколько я помню, эта кодировка не входит по умолчанию в python на этой операционной системе.
Также одной из проблем для меня стало странное поведение некоторых методов. К примеру, если я менял местами параметры, то скрипт мог вернуть ответ в 10 раз меньше запрашиваемого или вообще ничего не вернуть. Для решения этой проблемы я просто решил распарсивать и отправлять параметры в строгом порядке, как они указаны в документации. Возможно это простое совпадение, но после этого проблем подобного рода у меня не возникало: