Comments 20
Честно говоря ожидал обсуждение, хотя бы небольшое. Тема вообще интересна? Писать ещё подобные статьи?
Тема интересна, но сегодня первый из 4 выходных. Обсуждения могут быть в среду.
Тема интересна, но вот вы писали что привели бы конкретные примеры. Хотя уже из описанных ситуаций, многие, думаю вспомнят как сталкивались с подобным. Возможно, более правильно было бы рассмотреть подобную проблему в некоторых приложениях или на каких то сайтах. Вот в мобильной версии ВК, бывает не открывается меню при плохом соединении.
И кстати, какой технологией лучше это реализовывать. Тот же ВК, ужасно работает при плохом соединении. Зачастую приходится обновлять страницу. И на других сайтах бывало подобное. То что-то не загрузиться и все.
Но в ВК бывает необходимость просмотра сообщений, в целом все норм сделано в приложении и вопрос можно опустить.
А как насчет сохранения данных формы через клиент или сервер в случае неудачи. Если вы работали с IPB форумами, то думаю, поймете о чем я.
И кстати, какой технологией лучше это реализовывать. Тот же ВК, ужасно работает при плохом соединении. Зачастую приходится обновлять страницу. И на других сайтах бывало подобное. То что-то не загрузиться и все.
Но в ВК бывает необходимость просмотра сообщений, в целом все норм сделано в приложении и вопрос можно опустить.
А как насчет сохранения данных формы через клиент или сервер в случае неудачи. Если вы работали с IPB форумами, то думаю, поймете о чем я.
На самом деле это живые кейсы, которые я реализовывал в прошлом, т.е. вполне конкретные примеры, вот как описал.
К сожалению магазин и плеер сейчас не существуют, а доступ к внутренностям кинотеатра я дать не могу.
Про технологию тут зависит от задач. В случае с контактом там хватит только грамотного использования шаблонизации на клиенте + отлов «дисконнектов» + хранения некоторых данных в localStorage. Не уходит за пределы данной статьи.
Сохранять данные формы в LocalStorage — довольно бесхитростно, и восстанавливать при открытии страницы.
С IPB форумами, и вообще какими либо форумами работать не приходилось.
Если задашь более менее конкретный вопрос, отвечу как реализовать это в твоем случае с конкретными технологиями.
К сожалению магазин и плеер сейчас не существуют, а доступ к внутренностям кинотеатра я дать не могу.
Про технологию тут зависит от задач. В случае с контактом там хватит только грамотного использования шаблонизации на клиенте + отлов «дисконнектов» + хранения некоторых данных в localStorage. Не уходит за пределы данной статьи.
Сохранять данные формы в LocalStorage — довольно бесхитростно, и восстанавливать при открытии страницы.
С IPB форумами, и вообще какими либо форумами работать не приходилось.
Если задашь более менее конкретный вопрос, отвечу как реализовать это в твоем случае с конкретными технологиями.
Мне Ваша статья понравилась. Интересно. Пишите еще.
Больше подробностей реализации…
Больше подробностей реализации…
Вполне интересно.Даже познавательно, пишите, конечно и дальше
А в чём собственно проблема? Если разработчик дорос до того что бы делать SPA то на слой общения клиент-сервер накладывается ещё одна абстракция — локальный кэш. И дальше всё уже через него.
В случае с заказами то варианта два — либо специальный код для корзины(6-8 символов) который можно продиктовать или например отсканировать по QR, либо отправка каждого заказа на сервер и сохранение в базе.
В случае с треками вообще нет проблем — каналы у многих позволяют спокойно забуферизировать в память несколько треков наперёд и краткосрочной отключки интернета даже не заметят.
Вообще не понимаю чего ожидал автор и каких обсуждений — это тривиальные и очевидные вещи, благо технологии сейчас позволяют это делать по всякому.
В случае с заказами то варианта два — либо специальный код для корзины(6-8 символов) который можно продиктовать или например отсканировать по QR, либо отправка каждого заказа на сервер и сохранение в базе.
В случае с треками вообще нет проблем — каналы у многих позволяют спокойно забуферизировать в память несколько треков наперёд и краткосрочной отключки интернета даже не заметят.
Вообще не понимаю чего ожидал автор и каких обсуждений — это тривиальные и очевидные вещи, благо технологии сейчас позволяют это делать по всякому.
По крайней мере, пусть больше разработчиков помнят, что сданный заказчику продукт при соединении 100 Мбит/с и пинге <10 мс это ещё не всё. Теоретически проблем нет, а реально, не так мало сайтов просто начинают странно себя вести при большом пинге и/или частично пропадающих пакетах. Даже если они не думают: «Все кто не на оптике или витухе — нищеброды, деревенщина и не наш клиент», получается некрасиво. Тем более, слишком много недоросших и до оффлайн-ситуаций.
(С ужасом вспоминая об одном известном 4g-провайдере).
(С ужасом вспоминая об одном известном 4g-провайдере).
Проблем никаких нет как раз :-) Всё решаемо.
Не думаю что стоит говорить «если дорос, то...» — все решают разные классы задач, и не всегда есть время даже задуматься о чем то интересном.
Да нет, я, в данном случае, говорил о кеше, хотя бы, в сотню треков. А это не так круто каждый раз гонять пол гигабайта трафика. Особенно если это какой-нибудь 3-4g.
Жаль лишь что подобных живых решений решений я видел единицы. Даже крупные порталы типа того же контакта не позволяют пользоваться частичным функционалом оффлайн.
Ну и ещё момент, что реализация подобных фитч, по сути, разделяет функционал на 2 части — работающий только онлайн и который может работать и оффлайн. Соответственно код надо поддерживать. Внедрение этого всего стоит денег, которые не всегда есть.
Не думаю что стоит говорить «если дорос, то...» — все решают разные классы задач, и не всегда есть время даже задуматься о чем то интересном.
В случае с треками вообще нет проблем
Да нет, я, в данном случае, говорил о кеше, хотя бы, в сотню треков. А это не так круто каждый раз гонять пол гигабайта трафика. Особенно если это какой-нибудь 3-4g.
Вообще не понимаю чего ожидал автор и каких обсуждений — это тривиальные и очевидные вещи
Жаль лишь что подобных живых решений решений я видел единицы. Даже крупные порталы типа того же контакта не позволяют пользоваться частичным функционалом оффлайн.
Ну и ещё момент, что реализация подобных фитч, по сути, разделяет функционал на 2 части — работающий только онлайн и который может работать и оффлайн. Соответственно код надо поддерживать. Внедрение этого всего стоит денег, которые не всегда есть.
Да нет, я, в данном случае, говорил о кеше, хотя бы, в сотню треков. А это не так круто каждый раз гонять пол гигабайта трафика. Особенно если это какой-нибудь 3-4g.
Тут вопрос в том как попросить у пользователя большее количество места на сохранение и доступ в локаль. Пока не копал, но вроде как 5/50 метров это лимит. Ну, и всегда есть флэш )
Так что с такого рода вещами должна быть соотвествующая постановка. Если изначально внедрить абстракцию на общение клиент-сервер и кэшировать ответы то это почти ничего не стоит, а вот связность локальной и сетевой БД уже прилично усложняет приложение.
Жаль лишь что подобных живых решений решений я видел единицы.
Потому что % такого рода пользователей КРАЙНЕ МАЛ(с). Да и пенять пользователь скорее всего будет на себя.
Хотя я вот сейчас занимаюсь подобным проектом — SPA + API на бэкэнде. Теоретически возможно сделать «толстый клиент», но пока посчитали что трудозатратно и не выгодно.
Тут вопрос в том как попросить у пользователя большее количество места на сохранение и доступ в локаль. Пока не копал, но вроде как 5/50 метров это лимит. Ну, и всегда есть флэш )
Ну я как бы это в статье описал от части :-) 5мб это лимит на LocalStorage, для других хранилищ лимиты больше. Там при достижении порога пользователю вопрос приходит на разрешение хранения оффлайн инфы.
Т.е. я подобное уже делал — работает хорошо.
Если изначально внедрить абстракцию на общение клиент-сервер и кэшировать ответы то это почти ничего не стоит, а вот связность локальной и сетевой БД уже прилично усложняет приложение.
Нет, при нормальной организации моделей эта работа абсолютно незаметна
Потому что % такого рода пользователей КРАЙНЕ МАЛ(с).
У меня за год было минимум 4 подобных случая с доставкой еды :-) А это -4 тысячи рублей продавцу.
У друзей знакомых бывали подобные ситуации. Они случаются, причем довольно регулярно.
Да, может это и не такой большой процент, но тем не менее это не только прибыль, но + к лояльности.
Да и пенять пользователь скорее всего будет на себя.
Будет на провайдера, да. Но тут ты решил его проблему — клиент доволен. В следующий раз будет знать у кого стоит брать, кто дает крутой сервис.
Теоретически возможно сделать «толстый клиент», но пока посчитали что трудозатратно и не выгодно.
Это всё от случая к случаю. Всё индивидуально. По моему опыту «толстый клиент» обходится дешевле в разработке и дешевле в поддержке. Бонусом ещё и более гибок. Но, как я и писал, это всё зависит от конкретной ситуации. Они все индивидуальны.
Спасибо за статью.
Тема интересна, но выходные дают о себе знать :)
А вообще, как мне кажется, это всё вопросы бизнеса, а не разработчика. Как заказчик решит делать, так и следует делать.
Тема интересна, но выходные дают о себе знать :)
А вообще, как мне кажется, это всё вопросы бизнеса, а не разработчика. Как заказчик решит делать, так и следует делать.
Вообще-то классификаця connectivity model выглядит так:
Требования и решения разные для всех случаев.
- connected
- occasionally disconnected
- occasionally connected
- disconnected (не требует подключения для работы)
Требования и решения разные для всех случаев.
UFO just landed and posted this here
Sign up to leave a comment.
Работа веб-проекта в условиях нестабильного подключения