dollar

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

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

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

Если это Google Chrome, то и спрашивать надо у Google Search Console. Там будет ответ.
А здесь можно лишь гадать.

1591979658
означает:
06/12/2020 @ 4:34pm (UTC)

https://www.epochconverter.com/ (или загуглите "timestamp").

Так ведь хостер может реагировать на жалобы не только РКН, а кого угодно. Например, на жалобы правообладателя размещенного вами контента.

Гуглите по фразе "абузоустойчивый хостинг" (от слова abuse).

Статический IP - является ПД.
Динамический - нет.

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

Phaser

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

Ещё на заре развития Интернета было время, когда умельцы делали сайты со всякими свистелками, выезжающими меню и т.д. Вскоре стало ясно, что это нужно лишь создателям таких сайтов для повышения ЧСВ, а к пользе и удобству для посетителей отношения не имеет.

Хотя есть немногочисленные сайты, которые делают ставку на вау-эффект и необычную подачу информации. Однако подача - это не игра, а способ оформления. То есть там нет механик.

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

Как определить блокировщик, легко гуглится. Хотя даже без гугла не вижу проблемы - можно легко догадаться проверить наличие/видимость баннера, например. А если баннеров нет, то происследовать результат работы блокировщика, он же на виду.

Это невозможно.

Разве что сделать переадресацию непосредственно в голове пользователя. То есть нужно заранее объявить всем, что у сайта есть зеркало по такому-то адресу. Частоблокируемые сайты именно так и поступают. Плюс они имеют какую-нибудь группу в ВК, или вики, или блог, или твиттер, где пишут новости о том, доступен ли сайт, какие сейчас проблемы, и как скоро починят.

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

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

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

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

Вопрос в том, какой уровень у программиста Васи. Как это определить? Плохой он программист или хороший? И плохой для кого? Лично Васе - норм, денег хватает на еду, яхту и на загородный особняк. Можно ли вообще по коду понять его "уровень"? Это же не игра какая-нибудь, где можно качать свой левел, который отображается в углу в виде цифры.

Вот вам вилка для примера:

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

Веб-сайт в данном случае тоже сервер, и для понимания введем понятия:

• Игровой сервер (или просто сервер)
  
• Веб-сервер (бекенд)
  
• Браузер пользователя или клиент или фронтенд
  

Далее задачу можно разделить на два (три) этапа:

Этап первый

Вам нужно, чтобы ваш сервер отсылал на веб-сервер информацию о начале и конце. Это делается по протоколу HTTP или HTTPS, что-то типа java.net.HttpUrlConnection, но я точно не знаю, что вам лучше подойдет для этой цели.

Соответственно, на веб-сервере у вас должен быть свой скрипт на любом языке, обычно это PHP. Этот скрипт сохраняет информацию в базу (обычно MySQL).

Чтобы хранить таймер, который всё время меняется, нужно хранить неизменные его части. А именно - начало и конец, или начало и продолжительность, или просто время окончания (timestamp) с точностью до секунды.

Этап второй
Это общение веб-сервера и браузера (клиента). И тут есть свои тонкости.

Во-первых, сразу вилка на функционал - либо у вас таймер появляется по нажатию по F5 (обновить страницу). То есть вы обновляете страницу, браузер запрашивает новые данные с веб-сервера, и после этого показывает таймер. Либо у вас страница веб-сайта открыта, и там в реальном времени вдруг появляется таймер. Сам! Это можно сделать по-разному, но самый банальный способ - чтобы веб-страница (то есть браузер) делала запрос каждые 10 секунд в фоне (ajax), и если вдруг появляются новые данные, то страница преображается.

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

В остальном всё просто. Информация из базу тупо посылается на клиент, то есть время окончания, и дальше на клиенете скрипт работает локально. Он показывает отсчет времени до старта игры. Собственно, написание этого мини скрипта на JavaScript можно считать третьим этапом.

Backend здесь будет тупо базой данных с минимальной логикой.
Вся красота ложится на frontend, и здесь уже используется такая технология, как JavaScript. Если точнее, то WebGL, хотя можно и старый добрый Canvas. В любом случае, это всё JavaScript. И других вариантов, в общем-то, нет.

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

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

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

Так что вам нужно смотреть, в первую очередь, дизайн (в смысле, проектирование), маркетинг, контроль качества. Либо просто выбрать исполнителя за вменяемые деньги, который все тонкости возьмет на себя.