Pull to refresh

Comments 38

Щелкал по окнам и кнопкам и сломал плеер: слайдер громкости оторвался.
зы Firefox 15.0.1


Проигрыватель там первый, который попался под руку. А демо сделано для показа функционала, описанного в топике)
Как все просто, оказывается. А я голову ломал, как у них это реализовано. Спасибо.
На самом деле да, пробегала мысль глянуть, «а как же работает», но я думал, что сложнее. Спасибо за пост
О! Благодарствую, вы настолько в тему!
Как раз сегодня стала задача организовать коммуникацию между вкладками, как раз в эти минуты прикручивал веб-сокеты, а тут на тебе! :)

Пойду надкушу яблоко
Спасибо. Чисто ради интереса, в чем смысл конструкции
var notifier = {};
notifier = new Notifier();
Судя по всему, запара) Перед публикацией подчищал код)
А, ок. Я думал — вдруг мега-хитрая оптимизация :)
Подозреваю, что ни в чем, она аналогична var notifier = new Notifier();
Подёргал регулятор громкости, перестало работать как следует — музыка играла на обоих вкладках. Потом открыл четыре вкладки — даже без дёрганья регулятора играло на всех четырёх одновременно.
Спасибо. Жаль что что многие — promodj и даже soundcloud — не пользуются этой возможностью.

После ВК можно много статей написать :-) Следующая — как это они выводят уведомления из фоновой вкладки.
>>как это они выводят уведомления из фоновой вкладки.
Точно так же.
Я о тех уведомлениях которые выводятся поверх совершенно не-ВК-шных табов.
Всё равно не понятно. Если вы об уведомлениях в Google Chrome — то это отдельная фича браузера, и только.
Писал когда то нечто подобное через кукисы, собственно всегда думал что и VK юзал именно их. А иначе как быть с старыми браузерами?
а какие преимущества оно дает перед теми же кукисами? Хранить данных надо не много, но в кукисах это куда более кроссбраузерно.
А как отслеживать изменение кук в реальном времени без дополнительных запросов к серверу? Я лично на вскидку не могу дать ответ, а Local Storage выполняет это без каких-либо проблем.
а зачем делать запрос к серверу? куки хранятся в браузере, мы их в него пишем с одной вкладки, и периодически чекаем с другой
В том то и дело что чекать надо, а тут мы можем через ивенты трекать.
ну тут надо смотреть, можно ли ради этого жертвовать кроссбраузерностью
А жертв и нет. У олдфагов будет диджейский микс играться, как они и привыкли. Все счастливы.
Ну как бы, можно и полифил прикрутить, и тогда все будет ок. Правда чекать насколько я помню все-равно нужно будет вручную.
Спасибо, интересно. Думал, они вебсокеты используют.
да и я думал что через веб-сокеты. Когда-то искал метод копирования неких локальных данных между вкладками, так вот тут как раз local storage и помог. (записываем в одной вкладке в local storage — json, а во второй проверяем нет ли что то в буфере)
Омг, так вот как они сделали.
А я знаете, как написал у себя — каждая страница имеет соединение по вебсокету, и при новом событии на сервере все эти соединения там перебираются, и выбираются по одному для каждого пользователя, и уже в выбранные соединения шлются сообщения.
Реализуем подобную схему, но только с шаред воркерами для разгрузки сервера, поэтому интересны некоторые вопросы:
Каким сервером для сокетов пользуетесь и не разрывает ли его от постоянных реконектов? А так же не используете ли вместе с ними шаред воркерами?
Не знаю, что такое shared worker'ы.

Сервер — node.js + socket.io.
Библиотеке этой не особо доверяю, потому что не доверяю вообще любым новым фреймворкам, и не смотрел её исходный код.

При разрыве соединения сама реконнектится.
Когда реконнектит — второй раз происходит событие 'connect'. Если это засекается — нужно вручную тянуть с сервера «пропущенные сообщения».
Реконнекты происходят только при перезагрузке сервера. Если не перезагружать — всё вроде как стабильно.
Воркеры появились в HTML5 API, они мол позволяют какой-то конкретный скрипт выполнять фоном, с возможностью обмена сообщениями между друг другом (для синхронизации) и основным скриптом. Такая вот аналогия с обычными потоками.
Ну для сайта с контентом, обновление которого требует перезагрузки страницы нагрузка будет ненужной. Каждый переход по ссылке будет сопровождаться реконнектом. Так же, каждый таб и окно будут иметь по своему коннекту, поэтому мы грузим шаред воркер, который открывает одно соединение в фоне и все вкладки подключаются к нему как к посреднику. Получается одно постоянное подключение, которое на зависит от переходов.
А, круто.
Мб себе такое прикручу.
Почитал про эти shared worker'ы.
В целом кое-как понял, как они работают, но не нашёл, есть ли способ «заинклудить» что-нибудь в код worker'а.
Скажем, нужно мне какую-нибудь библиотеку вызывать при создании worker'а — для этого, как я понял, нужно засунуть этот вызов в файл worker'а.
И вот есть ли какая-нибудь директива «include», чтобы подцепить мою стороннюю библиотеку и использовать её код в этом worker'е?
Да, importScripts() называется. Единственное но — в шаред воркерах можно использовать только нативные вебсокеты, так что не получится использовать деградацию до флеша. А это, по сути, ознает то, что такая связка будет работать только в хроме. В опере вебсокеты отключены по умолчанию, а ФФ не поддерживает воркеры вовсе.
м, спасибо.
напишу тогда пока решение и отложу на будущее.
Помню раньше они для этого использовали кроссбраузерный postMessage без localStorage.
Только что как раз читал про это в гугле.
Заинтересованным — ссылка: robertnyman.com/2010/03/18/postmessage-in-html5-to-send-messages-between-windows-and-iframes/

Если поменяли на localStorage, то мб. у postMessage есть какой-то недостаток.
Или не поменяли, а до сих пор используют postMessage.
Я сам не смотрел их исходники.
Only those users with full accounts are able to leave comments. Log in, please.