Электронный маршрутник в бою (впечатления)

[Михаил]

Вообще странно конечно, что плохой Интернет так влияет на передачу текстовых символов, для которых нужно чуть больше, чем его полное отсутствие.

[Malamut]

achekh,
Да я ж не против автосохранения. Мне надо лишь, чтоб бы возможность явного сохранения с подтверждением. И я лишь утверждаю, что синхронизацию работоспособной сделать невозможно. Я могу привести пример.

I: Допустим, двое приехали на КП с плохим интернетом. Вбили ответ A в телефон 1. Заметили, что инета ну совсем нет, взяли телефон 2 и тут поняли, что ответ A неверный. В телефон 2 вбили ответ B, и телефон 2 рисовал уверенный H+, хотя реально интернета не было вообще. Но на самом деле ответ А ушёл на сервер (это важно дальше). А у телефона 2 и правда нет интернета и появится он ещё через полчаса, скажем. Но поскольку ответ B более поздний - то он должен сохраниться, так ведь? Это же явно всеми ожидается и так и должно работать? По крайней мере все будут этого ожидать. Но.

II: Другие двое приехали на это же КП. Вбили ответ А в телефон 1. Он ушёл на сервер, но они заранее, видя, что интернет плохой, договорились, что вбивать будут оба. Так что в телефон 2 вбили ответ тоже, но с ошибкой или вообще не тот (B), причём по времени после ответа A, а интернета на телефоне 2 вообще нет. На следующем КП, не доверяя системе автосохранения и потому, что вбивали на два телефона, решили проверить, что же реально сохранилось. Ну и вообще, КП брали в спешке, мало ли (и таки да, участник с телефоном 2 ошибся и вписал неверный ответ B). У телефона 1 уже стабильный интернет, прошло куча времени. Обновили страничку, увидели ответ A, возрадовались, что молодцы, и забыли. И тут в сеть вышел телефон 2 и записал более поздний и неправильный ответ B. Но никто про это так и не узнал.

С точки зрения сервера варианты I и II выглядят абсолютно одинаково. И кто, скажите, из этих двух команд поступил неправильно, а главное почему и как, черт возьми, они должны были понять, что поступили неправильно?

Я абсолютно уверен, что невозможно сделать работающую автосинхронизацию как основной метод определения ответа, данного командой. Эта задача не имеет решения в принципе. Даже вон, с двумя телефонами. А что можно придумать с 4мя! Автосохранение - пожалуйста, отличная штука. Но фиксация конкретного ответа на сервере - это маст хев функционал для команды и его ни в коем случае нельзя полностью отдавать на откуп автоматической системе. Реализуется он, как я уже многократно писал, элементарно. Никаких проблем с конфликтами там не будет и быть при правильной реализации не может. Могу описать или накидать прототип, для работы которого будет достаточно любой производительной базы ключ-значение, даже не персистентной. Отключать автосохранение и вообще текущую систему не надо - можно просто добавить кнопочку к каждому полю. Можно не галочку, можно замочек - чтоб было явно видно, что на самом деле нажатие на кнопку не обязательное и это лишь для блокирования ответа, а не для сдачи. Но кнопка быть должна, иначе система гарантированно при абсолютно любой реализации будет неработоспособна. Либо вам придётся делать какие-то попапы при проблемах синхронизации, причём не просто, а с кнопками выбора правильного ответа. Но это вот как раз интерфейсная жесть и какой-то бред. И там всё равно придётся разруливать конфликты, всё те же и всё так же. Никуда никогда вы от этого не денетесь. Ну, либо получите заведомо не работающую систему.

[achekh]

Malamut
Замечательно рассписываете
Но вы так и не ответили на мой вопрос:
Что делать если в ваших случаях, пользователи оба нажали сейв и замочек.
В этом случае вы получаете все тебе проблемы.
Ели интернета нет то выходит кто первый появится тот с сохранит.
А если интернет есть то чей первый запрос придет на сервер тот и сохранится.
Поэтому вашим замочком проблемы в сложном кейсе не решить. А вот усугубить легко. А в простом кейсе проблем нет вообще

[Malamut]

Что делать если в ваших случаях, пользователи оба нажали сейв и замочек.

В плане? Сейв - операция синхронная, в этом и смысл. Поэтому либо вы получите ошибку (перед сейв надо бы делать короткий ping запрос на сервер - если нет ответа - писать ошибку соединения с сервером, если ответ есть - посылать данные и ждать подтверждения. Если подтверждение не пришло - ошибка сохранения данных. Если пришло - всё ок).

Поскольку операция синхронная, то если вы пытаетесь сохранить отличные от сохранённых данные, то сервер вам вернёт ошибку что данные уже сохранены и с другим значением. никаких состояний гонки при правильном использовании блокировок на сервере быть не может, любой пользователь в любой момент времени будет получать наиболее релевантную ошибку при абсолютно любых проблемах с интернетом и пресловутой автосинхронизацией, которая сейчас запилена.

[achekh]

Ок, те если интернета нет то вы получите ошибку.
Если интернет есть?
Вы отправили два запроса с разных устройств.
Никто в мире не сможет гарантировать какой из них придет первый.
Как быть?
Те в вашем случае скажем второй ответ (неверный) может дойти раньше. И заблокирует ввод.

[Malamut]

И да, безусловно все операции с замочком - исключительно синхронные. Надеюсь, вы понимаете, что имеется ввиду. Поэтому никаких отложенных конфликтов быть не может, как и конфликтов синхронизации, потому что нет никакой синхронизации. Единственное верное значение - у сервера, он его изменяет явно по валидируемому явному запросу и ни с кем не синхронизирует. Если есть проблема синхронизации клиентов - то это в худшем случае приведёт к тому, что на попытку нажать кнопку save клиенту вернётся ошибка - и это совершенно нормально. Ну и если у какого-то клиента до конца игры так и не появится интернет, то в нём могут быть недостоверные данные. Но это и сейчас так.

[Malamut]

Те в вашем случае скажем второй ответ (неверный) может прийти раньше. И заблокирует ввод.

что за бред? Один из участников гарантированно получит ошибку с русским описанием того, что у вас, ребята, конфликт ответов. И дальше, стоя рядом у КП, можно его сразу пофиксить. Заблокированный ответ можно ж разблокировать! В любом случае никакие неявные для команды операции с замочком by design невозможны. При правильно срабатывании замочка, к тому же, моментально блокируется поле ввода и всех участников с сохранённым ответом внутри. То есть при рабочем интернете надо очень умудриться нажать одновременно. И это в любом случае приведёт к явной и понятной ошибке на одном из клиентов.

[Malamut]

Справедливости ради у описанного мной механизма есть явный изъян, про который я не упомянул, но который элементарно устраним. Попробуйте догадаться)

[Malamut]

В качестве подсказки: цель заключается в том, что если вы заблокировали поле без ошибок и видите в нём правильный ответ - то это гарантированно сохранённый ответ на момент срабатывания блокировки. Дальше кто угодно может его разблокировать (и поменять), но при этом он тоже будет видеть текущий сохранённый ответ и кнопку разблокировать. То есть любой участник всегда сможет сделать только явно разумную операцию (сохранить конкретный ответ и увидеть, что именно он сохранён и заблокирован; снять блокировку с конкретного гарантированно сохранённого ответа, чтоб его поменять).

[achekh]

мне все больше кажется, что вы пытаетесь решить одну проблему другой. Кнопка блокировки ответа это совсем другая задача никак не связанная с синхронизацией, которую можно и нужно решить.

Ответ введенные позже онозначно должен считаться главным.
Т.е. если вы через час после сохранения ввели что-то новое то вы хотели это ввести и это однозначно надо сохранить.
Если вы поменяли по приколу или случайно - сами себе злобные буратины.

Проблема с синхронзацией двух ответов примерно в один момент - тут да, потециальная проблема может быть.
Но она будет даже в случае с замочком и явным сохранением.
Т.е. если два пользователя ввели ответ примерно в одно время - то вы хотите увидеть что-то и принять.
Если рассмотреть этот кейс то можно показать варнинг, если разница между введенными ответами скажем 10-20 секунд, то выдать предупреждение для потдверждения.
Это решит кейс с неточной синхронизацией времени.
 
Если у вас нет интрернета, то в этом случае можно так же автоматически попробовать 2-3 раза.
Если нет спросить - то показать ошибку и спросить у пользователя нужно ли сохранить ответ локально для синхронизиции дальнейшенй, когда появится интернет. При этом по умолчанию все должно синхронизироваться без ненужных диалогов, а эту доп опцию вы лично сможете отключить.

Если выбрано синхронизировать, и интернет появился через час - то действуют все те же правила, как будто интренет был и ответ отправлен сразу.
Т.е. если разница между ответами 10-20-30 секунд, то сообщить об этом пользователю (а может и всем). В приложениях (не браузере) можно было бы сообщение выкидывать что синхронизация прошла. Как в мобильном браузере это делать я точно не знаю, но думаю тоже можно.

Т.е. при сохранении на КП вы узнаете что либо все ок, либо не ок и тогда решите что делать.

Вот это UX. и вполне как видите можно обойтись без всяких ненужных доп кнопок, которых в настоящее время становится все меньше и меньше.
 

[Malamut]

Вот это UX. и вполне как видите можно обойтись без всяких ненужных доп кнопок,

Нельзя.

Ответ введенные позже онозначно должен считаться главным.

См. вариант II. Он абсолютно корректен - явный запрос данных с сервера (обновление страницы) всегда должен возвращать текущие данные и после этого они, конечно же, не могут неявно измениться. А вы именно это предлагаете. Задача автосинхронизации, ещё раз, не имеет решения. То, что гугль даже не пытается, как бы намекает. Поверьте, гугл гораздо профессиональнее нас с вами.

Но она будет даже в случае с замочком и явным сохранением.

Видимо, вы всёй таки не знаете, что такое синхронные запросы. Печально)

При автосинхронизации можно, конечно, показывать те же предупреждения. Но когда? Когда телефон лежит в кармане уже?)) Или через час, когда появится интернет, сразу на 10 КП?)) При асинхронных операциях никакие предупреждения по сути невозможны - их просто нереально сделать удобными и информативными.

[achekh]

См. вариант II. Он абсолютно корректен - явный запрос данных с сервера (обновление страницы) всегда должен возвращать текущие данные и после этого они, конечно же, не могут неявно измениться. А вы именно это предлагаете. З

Мн кажется, вы очень невнимательно читаете, что я предлагаю.
1. Если сети нет после 2-3 попыток, то дать возможность увидеть ошибку сети и указать что делать: синхронизировать ли ответ позже или нет.
Если выбрано синхронизировать, то см. пункт 2
2. Если между двумя введенными ответами (время конечно же ввода клиентского) время меньше 10-20-30-60 секунд, то НЕ сохранять ответ и показать окно предупреждения и подтвержения (в приложении это было бы сделать очень легко, в браузере думаю, тоже).
При этом абсолютно если ответ пришел через час (см. пункт 1) то действовать точно так же.

Видимо, вы всёй таки не знаете, что такое синхронные запросы. Печально)

Синхронным может быть только один запрос одного клиента.
Если клиента два то запросы будут в любом случае паралельными.
И никто не гарантирует когда и в каком порядке они придут.
Безусловно на сервере можно все залочить пока обрабатывается один запрос (аля сделать сервер синхронным), но это все равно не гарантирует порядок прихода запросов.

[Malamut]

показать окно предупреждения и подтвержения

Кому? Телефон в кармане.

Если клиента два то запросы будут в любом случае паралельными.

Откройте для себя блокировки) Безусловно всё можно лочить, да. Какая вам разница, в каком порядке приходят запросы, если вы в любом случае не сможете случайно сохранить неправильный ответ? (посылая два ответа - правильный и неправильный, одновременно). Плюс эта ситуация дикая. Накой ляд одновременно пытаться сохранить одно и то же, стоя рядом?

[achekh]

И еще раз - я хочу донести, что кнопка с синхронизацией (и текущими проблемами) не связаны вообще никак!
Простейшее доказательство:
Счтайте кнопку добавили.
И вы (а также все участники вашей команды) просто жмут эту кнопку всегда (после ввода ответа).
И вы получаете все те же проблемы синхронизации.
Кнопка может помочь ТОЛЬКО если один запрос обработан, второй клиент получит обновление. Но как же он получит обновление если нет интенета?
А если и есть.
Получит.
Ок, вы предлагаете заблочить поле и не давать возможность вводить.
Я предлагаю не блочить. Вместо этого если между ответами прошло 10-20-30-60 секунд то спросить у пользователя подтверждения мол "ваш ответ отличатся от введенного 20 секунд назад. Сохранить?".
При этом если в вашем случае поле заблочилось (т.е. синхронизация клиента произошла), то в моем случае клиент также синхронизируется и получит текущий ответ и время его ввода.

[achekh]

Откройте для себя блокировки) Безусловно всё можно лочить, да. Какая вам разница, в каком порядке приходят запросы, если вы в любом случае не сможете случайно сохранить неправильный ответ? (посылая два ответа - правильный и неправильный, одновременно). Плюс эта ситуация дикая. Накой ляд одновременно пытаться сохранить одно и то же, стоя рядом?

Ваш пример 1 или 2. Интернет плохой. Но н есть. Вы решили 2 раза вбить ответы. Один раз неверный.
Неправильный пришел ранее, значит сохранился и поле (в вашем случае) заблочилось.

Кому? Телефон в кармане.

Вы сами пишите, что будете проверять через час (т.к. неуверены дошло ли вообще что-то до сервера и что именно).
Если вы проверили как в случае 2 все ок и забыли, то когда второй синхронизируется ответ НЕ сохранится (как вы и хотите).
Но будет предупреждение клиенту что раш ответ отличается от введенного 10 секундами ранее.
Если второй пользователь ничего не сделает - то и проблем не будет.
Если он откроет и увидит - он сможет принять решение что делать, например, просто отменить свои изменения.

Опять же никакой кнопки лок для этого не нужно.

Приведите пример где ваша кнопка лока поможет, а мой алгоритм нет (не считая отличия, что можно ответ через час после сохранения явно поменять специально/случайно, как я писал это совсем другая задача)

[achekh]

И кстати еще один важный момент который вы мне кажется не понимаете.
Запрос это понятие двустороннее. (есть запрос, есть ответ, есть реквест таймаут, есть респонс таймаут)
Т.е. запрос может уйти на сервер и начать обрабатываться.
Но при этом соединение с клиентом может потеряться (тупо связь пропадет окончательно).
В этом случае для клиента это будет выглядеть как ошиька сети.
Но на  самом деле ответ нормально дошел до сервера и даже сохранился.
В этом случае вся ваша теория с ошибками, блоками, повторными вводами после ошиок тоже рушится

[Malamut]

И вы получаете все те же проблемы синхронизации.

Нет. Если кнопка успешно сработала, то это гарантирует запись конкретного ответа на сервер. Никаким способом изменить его, явно не разлочив конкретно этот ответ, больше будет невозможно. Вне зависимости от состояния каких либо клиентов, интернета и прочего. Вы пришли на КП, сохранили ответ - всё, это гарантирует, что именно этот ответ сохранён, до тех пор пока вы именно этот ответ не захотите явно поменять. С точки зрения сервера нет никаких проблем синхронизации, потому что нет синхронизации. Есть только операция записи и блокирования/разблокироавния.

то спросить у пользователя

У кармана пользователя, видимо. У вас же всё асинхронное сейчас. Никакие вопросы по сути нереализуемы адекватным способом.

Ваш пример 1 или 2. Интернет плохой. Но н есть. Вы решили 2 раза вбить ответы. Один раз неверный.
Неправильный пришел ранее, значит сохранился и поле (в вашем случае) заблочилось.

С кнопкой совершенно другой паттерн использования. Какая разница, какой ответ пришёл первый, если про каждый ответ вы точно знаете, сохранился он или нет? И если вы получили ошибку - вы точно знаете, что потом надо обратить внимание на этот КП и убедиться, что сохранён правильный ответ. Любая ошибка от кнопки прям содержит текст того, что нужно сделать. Ситуация какой либо неопределённости с кнопкой априори невозможна, что бы вы ни делали. С неявным сохранением она не просто возможна, а присутствует просто перманентно - вы тупо не знаете, дошёл ли ваш ответ до сервера в принципе. Крах вкладки/севшая батарейка - и привет КП без ответа. Например. Немного решается локалстораджем, но это всё костыли, не устраняющие основную проблему, которая заключается в невозможности сохранить данные на сервер. Проще говоря: текущий маршрутник не позволяет сохранять данные на сервер. Решений этой проблемы вы не предлагали, заставить пользователя разбираться в тонкостях синхронизации и постоянно помнить про них, высчитывая что же в итоге, когда и куда уйдёт - это не решение, а бред.

[Malamut]

В этом случае вся ваша теория с ошибками, блоками, повторными вводами после ошиок тоже рушится

Вы точно программист?)) Потому что не похоже. Если клиент потерял ответ от сервера - он всего лишь получит ошибку и будет находиться в неактуальном состоянии. Ошибка подскажет пользователю, что надо попробовать ещё раз. Вот и всё. Более того: чтобы отловить ошибки сети, надо перед запросом на сохранение слать пинг. В этом случае вы почти никогда не получите собственно ситуацию, что вам не пришёл ответ от сервера на запрос сохранения. Плюс всё это никак не может привести к тому, что на сервере окажется сохранён ответ, который не ожидается, а цель только в этом.

Сохраняем ответ и нет ошибки - гарантированно он записан.
Сохраняем ответ и ошибка (любая) - надо что-то сделать.

Всё, никакой магии. Просто гарантированное сохранение конкретного ответа, всегда и при любой ситуации.

[achekh]

У кармана пользователя, видимо. У вас же всё асинхронное сейчас. Никакие вопросы по сути нереализуемы адекватным способом.

Да у кого угодно.
Один ответ (первый, который дойдет когда угодно, хоть через час) будет сохранен.
Второй ответ потребует подтверждения.
Если вы проверили что первый ответ сохранен и правильный, но вы можете просто игнорировать это подтверждение, не открывать телефон. Проблем нет.
Это ровно тоже самое что с кнопкой в варианте 2:
Через 2 часа второй телефон очнулся. Отправил запрос. Серевер увидет, что поле заблокировано. И кидает ошибку. Пользователь может эту ошибку увидеть, может игнорить. Если уидит, и считает, что его ответ был верный - пойдет разблочит.
В моем случае - просто подтвердит свой ответ.
Если он не будет открывать телефон - значит первый ответ и останется, как вы и писали.

Еще раз - можете привести кейс, когда ваша кнопка помогает решить хоть какой-то кейс, а мой вариант нет (не считая изменнеия через час)?

[achekh]

Более того: чтобы отловить ошибки сети, надо перед запросом на сохранение слать пинг. В этом случае вы почти никогда не получите собственно ситуацию, что вам не пришёл ответ от сервера на запрос сохранения.

Если  сеть нестабильная пинг может пройти а через 5 секунд запрос уже нет.
Суть в том что вы хотите в частности знать сохранился ли ваш ответ. Если нет - увидеть ошибку и решить что делать.
Так вот я хотел сказать, что если вы увидите ошибку это не значит, что ответ НЕ сохранился.
Ответ может сохраниться, но для клиента это будет выгляеть как будто нет.

[Ирина Федорова]

Знаете, что мне реально непонятно? На самом деле мне конечно непонятна большая половина того, что здесь понаписано, потому как я не программист. Но вот как участнику такому рядовому и стандартному и как организатору мероприятий мне непонятно зачем вообще решать эту задачу, если ее можно не решать. Ее решение противоречит впрямую духу игры и правилам. Подталкивает игроков к нарушению этих правил, ну и параллельно ведет к куче технических сбоев. Зачем участникам команды независимо вводить или править ответы? Мы все находимся на одном КП. Вместе. Если это онлайн игра, то в идеале тоже все команды должны увидеть что там на КП изображено, а не ты решай первые 10, а я вторые 10. В чем беда вводить кому-то одному с одного устройства? И работоспособность устройства тоже задача команды. Если бумажный маршрутник утоплен/потерян - это чья беда? Организаторы новый дадут? Более того на этой же игре пока мы собирали Кобону, что мешало нам отправить местного шлиссельбургского Васю собирать КП. И такой сервис - Вася бы КП мог даже вносить сам. Мы так конечно никогда не сделаем, но все эти сервисы невольно подталкивают к таким вот вариантам.

[Malamut]

Еще раз - можете привести кейс, когда ваша кнопка помогает решить хоть какой-то кейс, а мой вариант нет (не считая изменнеия через час)?

Батарейка села до тех пор, пока не появился интернет. Ответ вы потеряли. Продолжать?) Кнопка не решает кейсы. Кнопка записывает ответ. Кейсы нужно решать вам, но все вы их всё равно не в состоянии решить, потому что это невозможно.

Ответьте на крайне простой вопрос: как мне в вашей системе сохранить конкретный ответ на конкретный КП на сервер? То есть какой мой порядок действий у КП, чтобы точно знать что именно этот ответ сохранён и больше не будет изменён без моего явного желания? Хочу самоочевидную инструкцию, в которой невозможно случайно что-то сломать, и которая гарантированно приводит к сохранённому ответу.

[achekh]

Ирина Федорова
Вот я тоже полностью согласен. Смотреть задания - ОК. Тут же можно и ответы в ридонли смотреть.
Никто же не заполняет маршрутник бумажный паралельно.

[achekh]

Батарейка села до тех пор, пока не появился интернет. Ответ вы потеряли. Продолжать?) Кнопка не решает кейсы. Кнопка записывает ответ. Кейсы нужно решать вам, но все вы их всё равно не в состоянии решить, потому что это невозможно.

Если вы выбрали "синхронизировать" и у вас села батарейка до появления сети то тут ничего не поможет.

Ответьте на крайне простой вопрос: как мне в вашей системе сохранить конкретный ответ на конкретный КП на сервер? То есть какой мой порядок действий у КП, чтобы точно знать что именно этот ответ сохранён и больше не будет изменён без моего явного желания?

Вы даже тут два разных и нехависимых кейса объединяете в один.

1. "чтобы точно знать что именно этот ответ сохранён ".  при вводе и отправке ответа вы видите ОК или не ОК.
Если не ОК, то два варианта:
а) ответ доставлен на севрер, но не приянят по причине того, что ответ отличается от сохраненного и введенного 10-30-60 секундами ранее.
Вы видите предупреждение и решате сохранить или нет
б) ответ не доставлен на сервер вы видите ошибку - ответ не сохранен.
Далее вы решаете что делать - пытаться отправлять дальше (пока не появится сеть) или же отменить.

2. "больше не будет изменён без моего явного желания" если ответ был изменен (именно изменен/введен, а не доставлен) через час после сохранения текущего, то это абсолютно другая задача.
Тут возможны два варианта:
- перезаписать всегда. т.е. считать, что любые изменеия, которые были сильно позже текущего ответа это дейтсивтельно обдуманные изменения, которые нужно принимать
- спросить пользователя типа "Ваш ответ отличается от введенного ранее. Перезаписать?".

При этом эти два варианта я бы делал не замочком у каждого КП а одной глобальной опцией на команду.

[Malamut]

и у вас села батарейка до появления сети то тут ничего не поможет.

Кнопка поможет. Вы будете точно знать, что ответ надо сохранить ещё раз. А сейчас паттерн такой, что если вы ввели ответ на одном устройстве в поле (без всяких конфликтов устройств, играете только с одного) - то дальше система сама обязана обеспечить его сохранение, потому что она берёт на себя такие обязательства, не показывая вам никаких ошибок и прочего. Я без понятия, как вы собираетесь гарантировать сохранение введённого в поле ответа при любых ситуациях, а вы обызаны это сделать, иначе система неработоспособна, потому что основной функционал гарантированно не работает в некотором множестве случаев. Делать заведомо нерабочую систему - это конечно топ. Зато без лишней кнопки.