Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Как обстоят дела с отзывчивостью? Заметна ли задержка между звуковым сигналом сканера и откликом приложения?
Если кому интересно могу рассказать про то, как мы создали и поддерживаем несколько одностраничных больших проектов с использованием backbone, как кэшируем всю верстку на стороне клиента.
Если кеширование значительно интереснее, чем простое складывание в localStorage — интересно, рассказывай.
И вопрос по статье: оффлайн работа приложения предусмотрена? Например если есть топ 100 товаров, что бы они при отсутствии подключения отображались. Ну и вообще изначальный запуск без интернета возможен, либо логика приложения такого не предусматривала вообще?
Когда то решал вопрос работы онлайн-плеера при отсутствии интернета. На тот момент лимит в localStorage был что-то около 5гб, а не как сейчас 5мб, так что значительную часть логики и треков можно было хранить в нём, так же запускать и слушать при отсутствии интернета.
Ещё кассу для кинотеатра делал схожим образом. Отсутствие интернета не должно было сказываться на продажу билетов.
Может быть как-нибудь созрею написать статю про работу онлайн проектов, которые должны работать даже без подключения.
По поводу кэширования — средствами самого браузера, то есть так же как кэширование стилей и скриптов.
У нас все заказы хранятся на стороне клиента, поиск тоже работает без участия сервера, так что отсутствие интернета не повлияет на работу.
Кстати, ограничение на размер localStorage тоже можно решить с помощью расширения.
У нас все заказы хранятся на стороне клиента, поиск тоже работает без участия сервера, так что отсутствие интернета не повлияет на работу.
Кстати, ограничение на размер localStorage тоже можно решить с помощью расширения.
Я примерно понял, о чем ты говоришь. Вероятно, схожую схему использовал для кеширования получаемых данных. Там трюк в том, что ajax запрос тянет из кэша, даже не отправляя на сервер запроса были/нет изменения, верно?
Ну с раширением там уж можно и получше хранилище использовать, но это не всегда применимо, и не всегда удобно.
Иногда надо что бы работало без расширений и дополнений — более девайсо/браузеро независимо выходит.
решить с помощью расширения.
Ну с раширением там уж можно и получше хранилище использовать, но это не всегда применимо, и не всегда удобно.
Иногда надо что бы работало без расширений и дополнений — более девайсо/браузеро независимо выходит.
На самом деле с кэшированием всё проще — просто отдаём всю вёрстку запакованную в js файле, распаковываем на клиенте, при обновлении страницы этот файл уже выдернется из кэша.
Для этого можно не паковать в JS, если что :-)
С отдельными файлами можно через зависимости с помощью, например, stealjs. Сами сгрупируются, запакуются и т.п.
Во всяком случае звучит проще, чем отдельно специально паковать вёрстку.
С отдельными файлами можно через зависимости с помощью, например, stealjs. Сами сгрупируются, запакуются и т.п.
Во всяком случае звучит проще, чем отдельно специально паковать вёрстку.
К рассказу еще б неплохо исходнички и демки.
Как и обещал, написал пост Работа веб-проекта в условиях нестабильного подключения
А не думали об установке локального приложения, слушающего некий порт на 127.0.0.1 и работающего с браузером через веб-сокеты? Тоже интересный вариант, как по мне.
Думали, но решение средствами самого браузера проще, на мой взгляд.
Сетевой вариант хорош еще возможностью удаленного доступа.
Я так интерфейсы управления железяками и делаю. Вот, недавно перешел на вебсокеты. Удобно. Можно даже отказаться от механизма CGI, а при желании — даже от установки веб-сервера. Просто при старте компьютера запускается демон, берущий на себя роль сервера и запускающий вебсокет.
Проверял отзывчивость при работе на расстоянии около пяти километров (оптоволокно): паузы незаметны.
Ну и еще один плюс такого подхода: любой браузер. Все-таки, хромой — поделка жуткая…
Я так интерфейсы управления железяками и делаю. Вот, недавно перешел на вебсокеты. Удобно. Можно даже отказаться от механизма CGI, а при желании — даже от установки веб-сервера. Просто при старте компьютера запускается демон, берущий на себя роль сервера и запускающий вебсокет.
Проверял отзывчивость при работе на расстоянии около пяти километров (оптоволокно): паузы незаметны.
Ну и еще один плюс такого подхода: любой браузер. Все-таки, хромой — поделка жуткая…
Дополнительные приложения сложнее поддерживать.
С браузером всё значительно проще — можно попросить обновить страницу, обновить расширение.
Можно наладить автоматическое обновление расширений и т.п.
С браузером всё значительно проще — можно попросить обновить страницу, обновить расширение.
Можно наладить автоматическое обновление расширений и т.п.
Возможно, я невнимательно читал, но ведь в данном случае будет работать только хром. А в случае внешнего приложения и через веб-сокеты будут работать вообще все современные браузеры (и IE10+, если не ошибаюсь). Один браузер — очень жесткое ограничение, мне кажется.
В данном случае, вероятно, да.
Но вообще сейчас есть библиотеки, позволяющие писать плагин сразу под все браузеры (включая IE10), т.е. работать будет сразу во всех.
Я более широкий круг задач подразумевал, а не конкретное решение. Иногда даже плагины не нужны, достаточно просто правильной настройки браузера на конечной машине через about:config или аналог.
Но вообще сейчас есть библиотеки, позволяющие писать плагин сразу под все браузеры (включая IE10), т.е. работать будет сразу во всех.
Я более широкий круг задач подразумевал, а не конкретное решение. Иногда даже плагины не нужны, достаточно просто правильной настройки браузера на конечной машине через about:config или аналог.
Да, будет работать только хром, но, к счастью, хром уже был, к тому же практически все наши пользователи используют хром. Установка внешнего приложения у корпоративного клиента затруднена ограничениями внутренного IT отдела, а поставить хром — пожалуйста.
Это решение прекрасно впишется в ситуацию, когда к сканеру нужно допустить несколько приложений — доступ к COM-порту ведь монопольный.
Есть программы, которые данные с ком-порта преобразуют в имитацию нажатий клавиатуры…
С принтерами всё просто на самом деле.
Браузер сам по себе может печатать на принтер, а на какой уже не важно.
В браузере убираются поля и всё-всё-всё лишнее, подгоняется под нужный формат.
.print() -> пошла печать. Что бы окна не вылазили настраивается silient_print в about:config (или как то так называется).
Всё работает на отлично, проверено. Отправкой данных на сам принтер занимается ось.
Браузер сам по себе может печатать на принтер, а на какой уже не важно.
В браузере убираются поля и всё-всё-всё лишнее, подгоняется под нужный формат.
.print() -> пошла печать. Что бы окна не вылазили настраивается silient_print в about:config (или как то так называется).
Всё работает на отлично, проверено. Отправкой данных на сам принтер занимается ось.
У меня крамольный вопрос назрел — а насколько внятно браузер спрашивает у пользователя разрешение на доступ к порту? Несмотря на то что у многих интернет подключен по Ethernet или Wi-Fi, многие GPRS-модемы для системы выглядят как старый добрый модем на COM-порту, со всеми вытекающими последствиями. История идет на второй виток?
Спасибо за информацию.
Я когда-то решал подобного плана задачу — надо было из веб-приложения (рабочее место оператора по складскому учету/выдаче заказов), работать с принтером наклеек — тогда решил просто — поднял на компьютере подключенном к принтеру наклеек — отдельное небольшое веб-приложение — и уже с ним (на localhost) общался из браузера, с которым работал оператор.
То есть оператор нажимает в веб интерфейсе «напечатать наклейку» — происходит JavaScript-ajax запрос (с параметрами текста для печати) на localhost — где поднят веб-сервер общающийся с принтером наклеек (по сути он просто на LPT посылал текст) — и происходила печать наклейки на рабочем месте оператора.
Я когда-то решал подобного плана задачу — надо было из веб-приложения (рабочее место оператора по складскому учету/выдаче заказов), работать с принтером наклеек — тогда решил просто — поднял на компьютере подключенном к принтеру наклеек — отдельное небольшое веб-приложение — и уже с ним (на localhost) общался из браузера, с которым работал оператор.
То есть оператор нажимает в веб интерфейсе «напечатать наклейку» — происходит JavaScript-ajax запрос (с параметрами текста для печати) на localhost — где поднят веб-сервер общающийся с принтером наклеек (по сути он просто на LPT посылал текст) — и происходила печать наклейки на рабочем месте оператора.
>Если кому интересно могу рассказать про то, как мы создали и поддерживаем несколько одностраничных больших проектов с использованием backbone, как кэшируем всю верстку на стороне клиента.
Насколько я понял из комментариев выше вы используете что-то вроде basket.js?
Насколько я понял из комментариев выше вы используете что-то вроде basket.js?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с COM портом в web-проекте